1. 如何解决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 查询的优化，添加更合适的索引可以避免性能问题：执行计划使用索引并不意味着就能执行快。
2. 一条查询极为缓慢的sql语句，如何去优化呢
1、将查询条件字段简历index;
2、将尽可能筛选掉最大数据量的条件放到where条件最后面，因为sql执行时，where条件是由右往左执行。
3、尽可能少用like、in等函数
3. 一条复杂的SQL语句，为什么第一次查询很慢，而第二次查询却明显快了
sql语句如果联合了多张表或频繁使用多个函数进行查询，确实会影响效率。需要优化的话，建议给查询条件设置索引，索引能提高查询速度；但是如果你的sql语句需要复合查询而且有很多运算的话，建议还是把一条sql语句拆开成三四条来写，虽然拆分来写有点麻烦但是查询响应速度明显快好几倍，不信你试试！
4. SQL查询太慢，或者根本就查不到数据有超时了
那是因为你没有建索引的关系，需要在danhao上建立索引，如果danhao是唯一值，需要建唯一索引。
5. c#中 sql查询为什么每次第一次查询会慢。第二次以后都会快
真正的慢不是慢在查询上，而是慢在数据库连接上。
而当你第二次查询的时候，创建的数据库连接是从连接池里分配给你的，不需要你重新创建，所以感觉会快很多。
6. 最近我的数据库(sql)查询速度很慢，这是什么原因
查询慢是和表结构，语句，系统等相关的建索引等方法都可以改善表结构，另外如果返回数据量很大，当然会慢，所以你尽量查询相对有用的数据再就是查询语句了比如用in查询没有jion查询快，还有
between
改成
>
<会快再还有，用子查询也会慢很多，如果是一些很复杂的查询，可以改用存储过程会好点，有时用临时表会慢但，从海量数据中查询取数进行子查询又不如用临时表快，不同的问题用不同的解决方法，看你要哪种了，单看你的问题无法直接判断。不过，优化查询句是关键的了。
7. sql语句查询很慢,如何解决
日期列 有索引吗？
储值卡明细 表 的列： 住院号
住院_安排医生 的 列： 住院号
都有索引吗？
没有的话，加上
8. SQL缓存问题，第一次查慢，第二次查快
查询时，数据库引擎会判断，如果数据在内存中，则会从内存读取数据，如果数据不在内存在，则先从硬盘读到内存，然后再供查询。
所以第一次查的时候，根据你的语句，数据库引擎会把一些数据从硬盘读到内存，第二次再查的时候，就从内存读数据，就快了很多了。
oracle有一个功能是让表常驻内存。
9. Sql参数查询慢
Declare @t datetime
set @t='2013-08-29'
exec (' select * from table1 where time> ''' + @t + ''' ')
这样执行 和原来不用参数一样快
10. sql数据查询反映很慢
这个问题我也遇见过，慢的话也正常，因为数据比较多
解决办法啊，首先从表考虑，可以针对这个表建索引，
然后的话说优化查询语句，可以的话添加 with (nolock);即select * from A with (nolock) 这样
然后就是where条件了，尽量不要使用like,in这些。尽量添加where条件。
这样应该可以了，还不行的话，上网查查怎么优化DB。