这个和你数据库中数据量大小，读取方式（datareader通常比dataset快一点），以及SQL语句等条件都有关系，（sql语句写好了可以提高效率），另外，如果是远程数据库，网络因素也要考虑，其实C＃读取数据库并不慢，只要你注意影响速度的因素，然后逐一去优化，其实也是很快的．还有，适当用缓存，也可以提高速度．
Ⅱ 如何解决SQL查询速度太慢
1. 执行计划中明明有使用到索引，为什么执行还是这么慢？
2. 执行计划中显示扫描行数为 644，为什么 slow log 中显示 100 多万行？
a. 我们先看执行计划，选择的索引 “INDX_BIOM_ELOCK_TASK3(TASK_ID)”。结合 sql 来看，因为有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能会更差，优化器选择这个索引避免了排序。
那为什么不选 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很简单，TASK_DATE 字段区分度太低了，走这个索引需要扫描的行数很大，而且还要进行额外的排序，优化器综合判断代价更大，所以就不选这个索引了。不过如果我们强制选择这个索引（用 force index 语法），会看到 SQL 执行速度更快少于 10s，那是因为优化器基于代价的原则并不等价于执行速度的快慢；
b. 再看执行计划中的 type:index，"index" 代表 “全索引扫描”，其实和全表扫描差不多，只是扫描的时候是按照索引次序进行而不是行，主要优点就是避免了排序，但是开销仍然非常大。
Extra:Using where 也意味着扫描完索引后还需要回表进行筛选。一般来说，得保证 type 至少达到 range 级别，最好能达到 ref。
在第 2 点中提到的“慢日志记录Rows_examined: 1161559，看起来是全表扫描”，这里更正为“全索引扫描”，扫描行数确实等于表的行数；
c. 关于执行计划中：“rows：644”，其实这个只是估算值，并不准确，我们分析慢 SQL 时判断准确的扫描行数应该以 slow log 中的 Rows_examined 为准。
4. 优化建议：添加组合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
优化过程：
TASK_DATE 字段存在索引，但是选择度很低，优化器不会走这个索引，建议后续可以删除这个索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在这个 sql 中 REL_DEVID 字段从命名上看选择度较高，通过下面 sql 来检验确实如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由于有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 组合选择度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在测试环境添加 REL_DEVID，TASK_ID 组合索引，测试 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引后执行计划：
这里还要注意一点“隐式转换”：REL_DEVID 字段数据类型为 varchar，需要在 sql 中加引号：AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'
执行时间从 10s+ 降到 毫秒级别：
1 row in set (0.00 sec)
结论
一个典型的 order by 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。
Ⅲ 如何提高SQL查询速度
索引对数据库检索优化时很重要的一个概念聚集索引在SQL中是唯一的也就是说聚集索引时一个很宝贵的资源但是SQL SERVER在自动分配索引的时候默认总是将ID主键分配为聚集索引其实是很浪费的通常情况下你可以通过语句创建聚集索引到你使用率最高的条件字段上面去，当然你必须先分配聚集索引然后再去分配主键，否则主键创建时就会自动占用聚集索引然后非聚集索引不能设置过滥，设置过滥会导致目录增多最后反而导致查询缓慢优化不是纯粹理论上的东西，理论教会你怎么去使用尝试才能获取经验
Ⅳ 怎么能提高外网读取SQL SERVER访问速度。
不可能吧，除非你的操作数据库都在本地，然后某个时间段同步，这样的问题是两地数据库不同步，总之应该没办法。。只能提高对端上传带宽来解决。
Ⅳ sql server读取写入速度具体多少m/s
sql server 不同版本与CPU挂钩。
一般标准版就一个1cpu左右，有钱，可以只运行2个CPU。
比如企业版，买支持1个CPU的版本不限连接数，需要20几万。何况买2个CPU.
若用盗版，估计你也就一个CPU了。查你，就挂了。
所以说你还需要考虑SQL SERVER和读取速度吗？
最快的速度能达到你复制一个文件的速度。
最慢的速度可以为0。
还有你的网络带宽，一般公司的普通网络带宽也就100Mb比特,也就是是最快速度为100/8=12.5M
Ⅵ 如何提高组态王的SQL读取速度
是本机数据库还是网络的？
话说sql的读取速度就是慢啊，关系型数据库数据格式不压缩，数据量一大，不通过组态王也是慢，如果字段再多就更完了。
通过odbc源的都差不多。
提高速度的话，看看组态王能不能给做个控件在后台做点工作。
Ⅶ sql语句查询速度是1分钟慢吗
这样的时间程序是有问题了，你这条sql执行需要一分钟，前台就得等一分钟，没有用户会愿意等，现在查询时间都是毫秒级别的，如果查询时间实在减不下来，可以做缓存，或者索引
Ⅷ SQL常见优化Sql查询性能的方法有哪些
SQL常见优化Sql查询性能的方法有哪些
可以通过如下方法来优化查询 1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要. 2、纵向、横向分割表，减少表的尺寸(sp_spaceuse) 3、升级硬件 4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段