一条SQL语句执行得很慢的原因大致可以分成两种情况来分析。1、大多数情况是正常的，只是偶尔会出现很慢的情况。
2、在数据量不变的情况下，这条SQL语句一直以来都执行的很慢。
针对大多数情况正常，偶尔很慢的情况1、当内存中的数据页相对磁盘的数据页发生变化时，我们称该内存页为脏页，反之则为干净页。从持久性上考虑，脏页是必须要刷回磁盘，这个过程我们称之为刷脏页，而这个过程中就有可能导致平时执行很快的SQL突然变慢了。那么什么情况会触发MySQL的刷脏页操作呢？一般来说有以下4种情况：
当redo log写满时，必须停止其它操作将redo log写入磁盘
因为脏页是存在于内存中，因此当内存不够用时，需要淘汰一部分数据页，如果淘汰的是脏页，就需要先将脏页同步到磁盘
MySQL认为系统比较空闲的时候
MySQL正常关闭的时候
而在这4种情况中，对我们影响最大的就是redo log写满的场景，因为一旦出现这种情况，整个系统将不再接受更新，这种场景需要尽量避免。另外如果内存不够用，需要淘汰的脏页太多，也会明显影响性能。2、拿不到锁我能怎么办
这个就是我们正在执行的SQL语句，可能刚好涉及到的某些表或者是行被加锁了，导致必须等待。
如果我们要判断是否被上锁，我们可以使用show processlist命令查看当前语句的状态。
在数据量不变的情况下，这条SQL语句一直以来都执行的很慢没用索引首先，绝大部分人都能想到的一点就是SQL语句没有走索引。
字段没有索引--你的 c 字段上没有索引，那么只能进行全表扫描了。所以导致这条查询语句很慢。
select * from t where 100
select * from t where c - 1 = 1000;
正确的查询应该如下
select * from t where c = 1000 + 1;函数操作失误导致没有用上索引--如果我们在查询的时候，对字段进行了函数操作，也是会导致没有用上索引的
select * from t where pow(c,2) = 1000;数据库选错索引了
我们在进行查询操作的时候，例如
select * from t where 100 < c and c < 100000;我们如果走 c 这个字段的索引的话，最后会查询到对应主键的值，然后，再根据主键的值走主键索引，查询到整行数据返回。
意思就是：就算你在 c 字段上有索引，系统也并不一定会走 c 这个字段上的索引，而是有可能会直接扫描扫描全表，找出所有符合 100 < c and c < 100000 的数据。
系统在执行这条语句的时候，会进行预测：究竟是走 c 索引扫描的行数少，还是直接扫描全表扫描的行数少呢？当然，扫描行数越少当然越好了，因为扫描行数越少，意味着I/O操作的次数越少。
系统是通过索引的区分度来判断的，一个索引上不同的值越多，意味着出现相同数值的索引越少，意味着索引的区分度越高。我们也把区分度称之为基数，即区分度越高，基数越大。所以呢，基数越大。
所以呢，一个索引的基数越大，意味着走索引查询越有优势
索引系统是通过遍历部分数据，也就是通过采样的方式，来预测索引的基数的。c 这个索引的基数实际上是很大的，但是采样的时候，却把这个索引的基数预测成很小。然后系统就不走 c 索引了，直接走全部扫描了。
由于统计的失误，导致系统没有走索引，而是走了全表扫描
不过我们有时候也可以通过强制走索引的方式来查询，例如：
select * from t force index(a) where c < 100 and c < 100000;
我们也可以通过查询索引的基数和实际是否符合，
show index from t;
如果和实际很不符合的话，我们可以重新来统计索引的基数来重新统计分析。
analyze table t;
既然会预测错索引的基数，这也意味着，当我们的查询语句有多个索引的时候，系统有可能也会选错索引哦，这也可能是 SQL 执行的很慢的一个原因。
总结
一个 SQL 执行的很慢，我们要分两种情况讨论：1、大多数情况下很正常，偶尔很慢，则有如下原因
(1)、数据库在刷新脏页，例如 redo log 写满了需要同步到磁盘。
(2)、执行的时候，遇到锁，如表锁、行锁。
2、这条 SQL 语句一直执行的很慢，则有如下原因。
(1)、没有用上索引：例如该字段没有索引；由于对字段进行运算、函数操作导致无法用索引。
(2)、数据库选错了索引。
