慢查询记录

记录人：刘洋

日期：0000-00-00

语句：按员工查询请假并按创建时间倒序

结论：预发索引后 P99 回到 130 毫秒

一、现象

9月16日 11:08 起，行政协同平台「我的请假」响应升高。接口 P99 从 140 毫秒升到 1.6 秒，持续 22 分钟。错误率 0.02%，页面等待后仍能打开。陈静于 11:11 收到延迟告警，通知刘洋查阅慢日志。11:36 清理两个测试工号的历史数据后，P99 回到 190 毫秒。生产请假表当时约 6,000 行，正常员工最多 14 条请假。

二、证据

这 22 分钟内耗时超过 500 毫秒的 SQL 有 28 条，其中 24 条是同一句：按工号过滤，再按创建时间倒序。现有索引只有工号，排序在数据库里完成，平均扫描约 2,400 行。变慢请求集中在 2 个测试工号，每个名下有 2,100 条以上联调残留。数据库 CPU 46%，没有全库锁等待。11:08 前两小时没有发版。

三、语句与索引

联合索引的列是工号和创建时间。李莉在预发用 2,000 条请假的账号复测，列表 1 秒内能翻到第 2 页。生产行数少，加索引预估约 1 秒，窗口定在 9月26日 21:40。

四、结论与后续

原因是残留测试数据，以及列表查询缺少排序索引。11:08 前两小时没有版本发布。周敏已在从库删除那 4,380 条测试请假，业务请假单保持原样。王芳在联调脚本末尾增加按批次号清理。刘洋增加每周一巡检：单个员工请假超过 200 条就告警。张伟确认生产索引由李莉在低峰执行，执行前先做主库备份。清理发生在 11:34 至 11:36，范围限于两个测试工号。陈静复测自己的列表，3 条记录在 160 毫秒内返回，页面可以翻页。生产业务请假单的条数在清理前后没有变化。慢日志保留 7 天，刘洋把那 24 条语句的样例另存了一份，供 9月26日加索引后对照扫描行。