MySQL慢查询风险指数模型设计( 四 ) _MySQL

文章插图

不符合的原因：扫描行数越多对系统的影响越大，所需要的 IO 和 CPU 资源也就越多，系统处于无响应状态的几率越大，其影响比例应该要远高于其他评分项。我们期望扫描行数越多，分值越高，越需要关注，故需要调整各个评分项权重和计分模型。

2、测试二

1）权重分配

重新分片权重并修改计分模型之后，整体模型如下：

文章插图

2）计算结果数据分布

文章插图

3）样本sql分析

文章插图

六、结论

评分模型

文章插图

采用权重分配二，需要重点关注所有分数为50以上的慢查询。

七、展望

1、更合理的评分模型

percona sever/mariadb 版本的mysql可以有更丰富的统计项

percona server/mariadb的慢查询示例

# Time: 2108189:54:57# User@Host: fangyuan.qian[fangyuan.qian] @[127.0.0.1]Id: 316541341# Schema:Last_errno: 0Killed: 0# Query_time: 2.777965Lock_time: 0.000289Rows_sent: 284Rows_examined: 1341Rows_affected: 0# Bytes_sent: 35600Tmp_tables: 1Tmp_disk_tables: 0Tmp_table_sizes: 1044920# InnoDB_trx_id: 52AFB919# QC_Hit: NoFull_scan: YesFull_join: NoTmp_table: YesTmp_table_on_disk: No# Filesort: YesFilesort_on_disk: NoMerge_passes: 0#InnoDB_IO_r_ops: 0InnoDB_IO_r_bytes: 0InnoDB_IO_r_wait: 0.000000#InnoDB_rec_lock_wait: 0.000000InnoDB_queue_wait: 0.000107#InnoDB_pages_distinct: 1862SET timestamp=1629251697;SELECTa.ts_minAS 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_maxAS host_ip,a.db_maxAS db_name,a.user_maxAS user_name,b.first_seenAS first_seen_timeFROM mysql_slowlog_192_168_0_84_3306.query_history a force index(idx_ts_min),mysql_slowlog_192_168_0_84_3306.query_review bWHERE a.checksum = b.checksumAND length(a.checksum)>=15AND ts_min >= '2021-06-04'AND ts_min < '2021-06-21'GROUP BY a.checksum;

未来可以将更多的指标纳入评分模型，评分维度会更多，模型也会更精确，慢查询风险指数也会更合理。

2、与业务相结合

针对不同的业务，需要关注的慢查询风险指数也应该是不一样的，核心业务的慢查询风险指数应该比较低。不同的业务之间慢查询风险指数相同的其表示的影响程度也不一定相同。

故引入一个「业务等级权重」，目的是将所有业务的慢查询风险指数量化为同一个标准。高优先级的业务其「业务等级权重」也会越高，低优先级的业务其「业务等级权重」也会越低。按照AppCode维度，将每个appCode的慢查询TopN发送给业务方，指数越高业务应该越优先处理。同时需要设置慢查询平台的「慢查询风险安全指数」水位线，超过这个水位线的所有慢查询都需要关注。

最终慢查询风险指数 = 慢查询风险指数 * 业务等级权重
八、总结

通过我们的慢查询分级模型，可以很好的把一个慢查询抽象化为一个具体的数字，将其数字化，给我们的运维带来了非常大的便捷性，这个数字，我们可以称之为“慢查询业务风险指数” 。

有了数字化慢查询，我们就可以很好地去界定一个慢查询是不是真的有风险，或者风险有多大，这样就可以以上帝视角的方式，来管理所有的慢查询，这样自上而下地去解决问题，相比让DBA整天盯着一个个具体的慢查询去解决的话，效率会非常高。

根据我们抽象化出来的风险指数(慢查询业务风险指数) ，我们可以按照一定的周期，将风险大的慢查询，推送给对应的具体的负责人，然后不断地解决，不断地迭代，最终实现解决慢查询从“被动”到“主动”的完美转换。