性能剖析记录

记录人：刘洋

日期：0000-00-00

对象：请假列表接口

结论：已定位，预发索引已验证

一、现象

9月16日 11:08 起，行政协同平台「我的请假」列表变慢。接口 P99 从平时的 140 毫秒升到 1.6 秒，持续 22 分钟。错误率保持在 0.02%，页面表现为转圈后仍能打开。陈静在 11:11 收到延迟告警后叫刘洋介入。11:36 周敏清理触发账号的测试数据后，P99 回到 190 毫秒。

二、剖析方法

刘洋对两台应用各采集 30 秒 CPU 样本，并导出这 22 分钟内耗时超过 500 毫秒的 SQL，共 28 条。CPU 样本里 64% 花在结果集映射。28 条 SQL 中有 24 条是同一条语句：按员工查询请假并按创建时间倒序，平均扫描约 2,400 行。数据库当时 CPU 为 46%，连接数正常，没有出现全库锁等待。

三、证据

该语句的过滤条件是员工工号，排序字段是创建时间。请假表现有索引只有员工工号，排序在数据库内完成。变慢请求集中在 2 个测试工号，每个工号下有 2,100 条以上请假，是 8 月接口联调时批量写入后没有清掉的数据。正常员工最多 14 条请假，同样语句的耗时在 40 毫秒以内。因此这次升高来自残留数据碰上缺少排序索引，发布记录显示 11:08 前两小时没有版本变更。

四、结论

根因是测试工号的历史请假过多，而列表查询缺少「工号 + 创建时间」联合索引。11:34 周敏在从库删除这两个工号的测试请假共 4,380 条，11:36 接口恢复。生产业务请假单没有删除。陈静复测自己的列表，3 条记录在 160 毫秒内返回。

五、修复与预防

1. 李莉于 9月18日在预发加上联合索引 idx_emp_created。用 2,000 条请假的账号复测，列表 P99 为 130 毫秒。生产执行放在 9月26日 21:40 的低峰窗口。
2. 王芳在联调脚本末尾增加清理步骤，9月19日已合入。脚本结束时按批次号删除测试单据，并打印删除行数。
3. 刘洋增加一条每周一的巡检：单个员工请假超过 200 条就告警。9月16日当周如果已有这条巡检，可以在上班前发现残留数据。

张伟确认生产索引放在 9月26日 21:40 的低峰窗口，由李莉执行，执行前先做主库备份。剖析记录保留采样时间和清理行数，方便下次对照。9月18日预发复测使用工号 T-1486，该工号下有 2,000 条请假，列表 P99 为 130 毫秒，页面 1 秒内可翻到第 2 页。