我们期望某些计分项在各个不同的阶段对分数的影响是不一样的，故首先假设计分模型和权重如下：
整体的评分模型如下：
慢查询风险指数 = sum(func(慢查询评分项) * 权重)
ps:风险指数总分数上限为100
五、测试
测试一
权重分配
计算结果数据分布
样本SQL分析
不符合的原因：扫描行数越多对系统的影响越大，所需要的 IO 和 CPU 资源也就越多，系统处于无响应状态的几率越大，其影响比例应该要远高于其他评分项。我们期望扫描行数越多，分值越高，越需要关注，故需要调整各个评分项权重和计分模型。
测试二
权重分配
重新分片权重并修改计分模型之后，整体模型如下：
计算结果数据分布
样本sql分析
六、结论
评分模型
采用权重分配二，需要重点关注所有分数为50以上的慢查询。
七、展望
更合理的评分模型
percona sever/mariadb 版本的mysql可以有更丰富的统计项
percona server/mariadb的慢查询示例
# Time: 210818 9:54:57 # User@Host: fangyuan.qian[fangyuan.qian] @ [127.0.0.1] Id: 316541341 # Schema: Last_errno: 0 Killed: 0 # Query_time: 2.777965 Lock_time: 0.000289 Rows_sent: 284 Rows_examined: 1341 Rows_affected: 0 # Bytes_sent: 35600 Tmp_tables: 1 Tmp_disk_tables: 0 Tmp_table_sizes: 1044920 # InnoDB_trx_id: 52AFB919 # QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: Yes Tmp_table_on_disk: No # Filesort: Yes Filesort_on_disk: No Merge_passes: 0 # InnoDB_IO_r_ops: 0 InnoDB_IO_r_bytes: 0 InnoDB_IO_r_wait: 0.000000 # InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000107 # InnoDB_pages_distinct: 1862 SET timestamp=1629251697; SELECT a.ts_min AS slowlog_time, a.checksum, SUM(a.ts_cnt) AS d_ts_cnt, ROUND(SUM(a.Query_time_sum), 2) AS d_query_time, ROUND(SUM(a.Query_time_sum) / SUM(a.ts_cnt), 2) AS d_query_time_avg, a.host_max AS host_ip, a.db_max AS db_name, a.user_max AS user_name, b.first_seen AS first_seen_time FROM mysql_slowlog_192_168_0_84_3306.query_history a force index(idx_ts_min), mysql_slowlog_192_168_0_84_3306.query_review b WHERE a.checksum = b.checksum AND length(a.checksum)>=15 AND ts_min >= '2021-06-04' AND ts_min < '2021-06-21' GROUP BY a.checksum;
未来可以将更多的指标纳入评分模型，评分维度会更多，模型也会更精确，慢查询风险指数也会更合理。
与业务相结合
针对不同的业务，需要关注的慢查询风险指数也应该是不一样的，核心业务的慢查询风险指数应该比较低。不同的业务之间慢查询风险指数相同的其表示的影响程度也不一定相同。故引入一个「业务等级权重」，目的是将所有业务的慢查询风险指数量化为同一个标准。高优先级的业务其「业务等级权重」也会越高，低优先级的业务其「业务等级权重」也会越低。按照appCode维度，将每个appCode的慢查询TopN发送给业务方，指数越高业务应该越优先处理。同时需要设置慢查询平台的「慢查询风险安全指数」水位线，超过这个水位线的所有慢查询都需要关注。
最终慢查询风险指数 = 慢查询风险指数 * 业务等级权重
八、总结
- 通过我们的慢查询分级模型，可以很好的把一个慢查询抽象化为一个具体的数字，将其数字化，给我们的运维带来了非常大的便捷性，这个数字，我们可以称之为“慢查询业务风险指数”。
- 有了数字化慢查询，我们就可以很好地去界定一个慢查询是不是真的有风险，或者风险有多大，这样就可以以上帝视角的方式，来管理所有的慢查询， 这样自上而下地去解决问题，相比让DBA整天盯着一个个具体的慢查询去解决的话，效率会非常高。
- 根据我们抽象化出来的风险指数(慢查询业务风险指数)，我们可以按照一定的周期，将风险大的慢查询，推送给对应的具体的负责人，然后不断地解决，不断地迭代，最终实现解决慢查询从“被动”到“主动”的完美转换。
- 我们最终的目标是，让所有慢查询的风险指数的中位数，或者90%、70%分位数，不断地下降，最终处于一个良性的状态
本文转自去哪儿技术沙龙
