存储优化(2)-排序引发的慢查询优化

摘要

排序引发的慢查询，一般不是那么容易发现,常常和数据分布有关系。每每在业务刚开始时并无什么问题，可是随着业务的发展，数据分布呈现一种特定的规律，致使了慢查询，或者并非什么慢查询，可是随着并发请求数增长，数据库的IOPS使用率变高，进一步致使cpu/内存使用率飙高。形成线上故障。

问题

由于排序引发的问题遇到不少次

例1：某日收到线上cpu告警

而后查看慢sql日志 大量的慢查询指向了这个查询

SELECT
        id,
        prize_id,
        user_id,
        name,
		biz_id
        FROM play 
        WHERE biz_id = xx
        AND status = 1
        AND prize_type = '大奖'
        ORDER BY id DESC
        LIMIT 0, 10
复制代码

play是抽奖记录表，sql是查抽中奖品的前10个大奖中奖者，来吸引其余用户参与抽奖，biz_id建了索引

例2 某日上线一个新功能，在第五次压测时，数据库cpu告警

查看数据库慢日志，没有一条慢sql（耗时>100ms）。最后经过查阅代码，sql调用统计。发现有大量下面的SQL调用

SELECT
        id,
        commit_id
        FROM commit_record
        WHERE biz_id = 'xxx' 
        AND id >=  #{fromId}
       AND id <= #{toId}
复制代码

biz_id有索引

例3 某日线上服务报API响应时间超过X秒

经过查看应用日志，发现大量com.mongodb.MongoSocketReadTimeoutException:mongo的错误。通过多重定位，发现从库的IOPS使用率快接近100%了，同时发现有些慢查询

"query":{"find":"historyRecord","filter":{"bizId":1234567,"version":23},"sort":{"_id":-1},"limit":1}}
复制代码

索引是bizId,version的联合索引

问题分析

这几个查询形成的线上问题的形式虽然各有不一样，但本质上都是同样，没法利用索引排序，须要用到数据库排序，当内存够大或没超过排序上限时，就会在内存中排序，这样单个查询相对比较快，可是并发量高了，内存容量不够了，须要进行磁盘排序时，就会变得很慢。

而后通过仔细观察，发现容易写出这种语句，忽视了排序形成的风险。经常是根据主键排序。开发者容易想固然的觉得主键是有索引的，因此排序会走索引，因此不会有什么大问题。但其实像例子中那些案例，都是没法利用索引排序的。 曾经在mongo索引篇介绍联合索引如何建立时也提到过。

总结一下，形成数据库服务问题主要根由是

1. 查询没有利用到索引排序
2. 索引过滤后下面数据仍然有不少，须要扫描排序的数据不少
3. 请求的并发量很高，数据库IOPS使用率高，内存占用高。

问题解决

首先，平常开发时避免写出这种SQL，尤为针对数据量比较大的表。或者索引下数据分布可能不均匀的状况。

线上解决 收到线上警告，发现是此类问题。

1. 判断业务侧可否降级，即减小此类查询。确保不要影响其余业务。
2. 数据库升级配置（须要作到对业务无影响）

线上问题的临时解决方案只能解一时燃煤之急，真正的解决问题仍是须要从查询着手。

查询优化

1. 业务侧避免此类查询 从业务侧分析，是否是须要此类查询。好比例3，bizId,version_id是否是自己能够做为有序的，版本号version_id能够设计成有序的，这样就不须要根据主键_id来保持有序
2. 减小并发 是否是全部的这类查询都是必须的，能不能接受缓存。
3. 引入其余存储方案 好比例1，业务须要查询按照时间顺序的中大奖的前N我的。这个业务侧能够将数据保存到在redis中，listz中存topN的数据。而后发现有中大奖的人，扔到redis队列便可。
4. 增长一个联合索引 好比例3能够增长一个bizId,version,_id联合索引

   "query":{"find":"historyRecord","filter":{"bizId":1234567,"version":23},"sort":{"_id":-1},"limit":1}}
   复制代码