背景:
公司内部的一个系统实现的时候用了分表, 方案是开源的 ShardingSphere https://shardingsphere.apache.org/ 分表算法使用了 100 取模, 100 张表嗯嗯数据量太大, 对于历史数据还使用了定时任务迁移. 这些架构设计会在另一篇文章详谈.
故障:
某日, 数据库告警, cup 报警, 发现多条慢查询日志 (部分查询高达 8 分钟...), 进而导致业务受到影响
以下是阿里云洞察详情
从日志中看到多条慢日志的 offset 超级大, 导致很多无用查询, 这里还导致返回记录特别多,
but, 怎么导致这个结果的??
原因:
没有手动执行过这种 sql, 也没有接口提供这种入口.
从查询的时间点筛选请求日志发现请求是通过一个分页触发的, 比如下面这个分页, 现在点击最后一页 3332,(页面是按照时间正序排列的, 看最后一页可以看最新的数据)
当筛选条件中添加指定多个应用时, 我们会在多个表里查找... 然后... 分页, 记得之前看文档说 shardingsphere 分页的时候会, 见下图
So, 这时候选择多个表, 并选择尾页查询, shardding 就会把每张表里符合条件的数据査出来, 合并排序拿到最终数据. 这就算 MySQL 受得了, 服务器也受不了啊
解决方案:
了解原因后解决方案也出来了, 如果想看最后的页, 那就倒过来看开始的页就可以了: 添加排序按钮, 并让前端只显示前几页来隐藏入口, 接口也禁止使用太大的页数查询
页面实现效果:
至此, 使用分库分表插件 shardingsphere 分页查询尾页最后几页导致的 MySQL 数据库服务器报警的问题解决了.
来源: http://www.bubuko.com/infodetail-3518997.html