覆盖索引

MySQL 可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机 io 操作。减少 io 操作，特别是随机 io 其实是 DBA 主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。
今年3月份时候，线上发生一次大事故。公司主要后端服务器发生宕机，所有接口超时。宕机半小时后，又自动恢复正常。
通过接口日志，发现MySQL数据库无法响应服务器。在阿里云的技术支持的帮助下，发现了MySQL数据库中存在大量慢查询，导致CPU负载过高。最后，根据慢查询日志，定位到了出问题的SQL和业务接口。业务接口是一个分页接口，莫名被刷到7000多页，偏移量（offset）高达20w多。每当这条SQL执行时，数据库CPU直接打满。查询时间超过1分钟才有响应。由于慢查询导致数据库CPU使用率爆满，其他业务的数据库请求无法得到及时响应，接口超时。最后，拖垮主服务器。limit分页查询性能问题MySQL Limit 语法格式：SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset分页查询时，我们会在 LIMIT 后面传两个参数，一个是偏移量（offset），一个是获取的条数（limit）。当偏移量很小时，查询速度很快，但是当 offset 很大时，查询速度就会变慢。下面我们以一个实例，讲解一下分页性能问题。假设有一张 300w 条数据的表，对其进行分页查询。select * from tbl_works limit 1, 10 // 32.8msselect * from tbl_works limit 10, 10 // 34.2msselect * from tbl_works limit 100, 10 // 35.4msselect * from tbl_works limit 1000, 10 // 39.6msselect * from tbl_works limit 10000, 10 // 5660msselect * from tbl_works limit 100000, 10 // 61.4 秒select * from tbl_works limit 1000000, 10 // 273 秒可以看到，随着偏移量（offset）的增加，查询时间变得越长。对于普通的业务而言，超过1秒的查询是绝对不可以忍受的。上例中，当偏移的起始位置超过10万时，分页查询的时间超过61秒。当偏移量超过100万时，查询时间竟然长达273秒。从上例中，我们可以总结出：LIMIT分页查询的时间与偏移量值成正比。当偏移量越大时，查询时间越长。这种情况，会随着业务的增加，数据的增多，会越发的明显。那么，如何优化这种情况呢？答案是，覆盖索引。优化方法对于LIMIT分页查询的性能优化，主要思路是利用覆盖索引字段定位数据，然后再取出内容。不使用覆盖索引，查询耗时情况：SELECT * FROM tbl_worksWHERE status=1 LIMIT 100000, 10 // 78.3 秒1）子查询分页方式SELECT * FROM tbl_worksWHERE id >= (SELECT id FROM tbl_works limit 100000, 1)LIMIT 20 // 54ms子查询分页方式，首先通过子查询和覆盖索引定位到起始位置ID，然后再取所需条数的数据。缺点是，不适用于结果集不以ID连续自增的分页场景。在复杂分页场景，往往需要通过过滤条件，筛选到符合条件的ID，此时的ID是离散且不连续的。如果使用上述的方式，并不能筛选出目标数据。当然，我们也可以对此方法做一些改进，首先利用子查询获取目标分页的 ids，然后再根据 ids 获取内容。根据直觉将SQL改造如下：SELECT * FROM tbl_worksWHERE id IN (SELECT id FROM tbl_works limit 100000, 10)// 错误信息：// This version of MySQL doesn’t yet support 'LIMIT & IN/ALL/ANY/SOME subquery’然而，并不尽人意。我们得到一个错误提示。错误信息的含义是，子查询不能有 limit操作。于是，我们对SQL进行了改造，对子查询包了一层：SELECT t1.* FROM tbl_works t1WHERE t1.id in (SELECT t2.id from (SELECT id FROM tbl_works limit 100000, 10) as t2) // 53.9ms执行成功，且查询效率很高。但是，这种写法非常繁琐。我们可以使用下面的 join 分页方式，达到相同的优化效果。实际上，两者的原理是相同的。2）join 分页方式SELECT * FROM tbl_works t1 JOIN (SELECT id from tbl_works WHERE status=1 limit 100000, 10) t2ON t1.id = t2.id // 53.6 ms这条SQL的含义是，通过自连接与join定位到目标 ids，然后再将数据取出。在定位目标 ids时，由于 SELECT的元素只有主键 ID，且status 存在索引，因此MySQL只需在索引中，就能定位到目标 ids，不用在数据文件上进行查找。因而，查询效率非常高。覆盖索引（Cover Index）如果索引包含所有满足查询需要的数据的索引成为覆盖索引(Covering Index)，也就是平时所说的不需要回表操作。简单的说，覆盖索引覆盖所有需要查询的字段（即，大于或等于所查询的字段）。MySQL可以通过索引获取查询数据，因而不需要读取数据行。覆盖索引的好处：索引大小远小于数据行大小。因而，如果只读取索引，则能极大减少对数据访问量。索引按顺序储存。对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少。避免对主键索引的二次查询。二级索引的叶子节点包含了主键的值，如果二级索引包含所要查询的值，则能避免二次查询主键索引（聚簇索引，聚簇索引既存储了索引，也储存了值）。总结通过利用覆盖索引，能极大的优化了Limit分页查询的效率。在真正的实践中，除了使用覆盖索引，优化查询速度外，我们还可以使用 Redis 缓存，将热点数据进行缓存储存。背景描述的事故，我们考虑了时间成本和业务复杂度后，最后采取的是限制分页和增加缓存。所谓的限制分页，即在不影响阅读体验的前提下，只允许用户可以查看前几千条的数据。经测验，偏移量较小时的查询效率较令人满意，查询效率接近使用覆盖索引查询的速度。

转载------------////////-----------//