一条SQL语句在什么情况下会执行得很慢？

一条SQL语句执行得很慢，可以有很多原因。但我们可以粗略地划分为两种情况：偶尔很慢和一直很慢。

先上结论

• 数据库在刷新脏页
• 内存不够用
• 查询的字段没有建立索引
• 查询的字段建立了索引，但是没有用到
• 数据库自己选错了索引
• 主机硬件配置不给力

第一种情况：这条语句执行大部分时间正常，只是偶尔很慢

这里涉及到脏页的概念，我稍微解释一下

脏页：在数据库中，更新的数据是先存在于内存中，然后再同步持久化到磁盘里去。在未持久化之前，内存和磁盘中的数据是不一致的，我们称该内存页为“脏页”。持久化之后，该内存页又被叫做"干净页"。因此，不论是“脏页”还是“干净页”，都是内存页。

• 数据库在刷新脏页
  • redo log 写满了：我们已经知道数据更新不会马上写入磁盘，而是将更新后的值记录到redo log 等到系统空闲或者日志写满了，再写入磁盘。该日志文件的容量有限，所以当它被写满了之后，就需要停下其他的操作，类似于Java中的GC时需要暂停其他线程。而这就会导致SQL语句突然执行得很慢。
• 内存不够用：这就跟我们平时开太多软件，系统会被卡是一个道理。操作系统在读取大量数据时，会一部分一部分地读取到内存页，当需要的数据不在内存中时，再去读入内存。当内存少的时候，进程分配的内存不够用，内存页也就不够多，读取数据时就经常要淘汰旧内存页，用来读入新数据，这个操作是比较费时的。
• 执行SQL语句的事务拿不到锁：在有多个事务操作数据库的时候，通过锁机制，可以避免发生并发问题（“丢失修改”、”读脏"、”幻读“）。拿不到锁的事务只能等待，而此时表现出来的就是SQL执行突然变慢。这是没办法改变的。

第二种情况：该语句一直执行得很慢

• 查询的字段没有建立索引：这会导致数据库在检索条件时采用全表扫描，如果表的数据量很大，就会很慢。
• 查询的字段建立了索引，但是没有用到：这个可能跟SQL语句的书写者的疏忽有关，因为有些情况下是会导致数据库不走索引，而去全局扫描的。这里有篇文章，是我自己的，列出了不走索引的几种情况：传送门
• 数据库自己选错了索引：
  • 索引分为主键索引和非主键索引，主键索引的叶子结点存储的是整行记录，而非主键索引的叶子结点存放的是主键字段的值。这意味着，**如果使用非主键索引，那么我们需要走两次索引才能拿到记录。**第一次走非主键索引，拿到主键值，然后走主键索引取得记录。
  • 索引的区分度：在一个索引上，如果相同的值越少，那么该索引的区分度越高。区分度也叫索引的基数。在相同的区间内，基数越大，区间内重复的值就越少。这意味着系统只需要扫描更少的行就可以得到结果。公式：count(distinct col)/count(*)
  • 重点：数据库在确认索引的区分度的时候，采用的是采样的方式，即便利部分数据。然后计算出基数，如果采样的那部分数据的基数刚好很小，那么系统就会放弃走索引，选择全表扫描。
  • 也就是说，由于系统自己统计失误，导致了系统没有走索引，而是全表扫描。

# 通过强制走索引的方式查询
select * from table_a force index(a) where 10 < id and id < 10000;

• 主机硬件配置不给力：硬件问题。