大意了，一次MySQL分页导致的线上事故...

今天给大家分享个生产事故，一个由于MySQL分页导致的线上事故，事情是这样的～

背景

一天晚上10点半，下班后愉快的坐在在回家的地铁上，心里想着周末的生活怎么安排。

突然电话响了起来，一看是我们的一个运维同学，顿时紧张了起来，本周的版本已经发布过了，这时候打电话一般来说是线上出问题了。

果然，沟通的情况是线上的一个查询数据的接口被疯狂的失去理智般的调用，这个操作直接导致线上的MySql集群被拖慢了。

好吧，这问题算是严重了，匆匆赶到家后打开电脑，跟同事把Pinpoint上的慢查询日志捞出来。看到一个很奇怪的查询，如下

1 POST  domain/v1.0/module/method?order=condition&orderType=desc&offset=1800000&limit=500

domain、module 和 method 都是化名，代表接口的域、模块和实例方法名，后面的offset和limit代表分页操作的偏移量和每页的数量，也就是说该同学是在 翻第（1800000/500+1=3601）页。初步捞了一下日志，发现 有8000多次这样调用。

这太神奇了，而且我们页面上的分页单页数量也不是500，而是 25条每页，这个绝对不是人为的在功能页面上进行一页一页的翻页操作，而是数据被刷了（说明下，我们生产环境数据有1亿+）。详细对比日志发现，很多分页的时间是重叠的，对方应该是多线程调用。

通过对鉴权的Token的分析，基本定位了请求是来自一个叫做ApiAutotest的客户端程序在做这个操作，也定位了生成鉴权Token的账号来自一个QA的同学。立马打电话给同学，进行了沟通和处理。