MySQL 慢查询日报 2026-11-04（staging）
一、统计概览
| 指标 | 值 |
|---|
| 统计区间 | 2026-11-04 00:00:00 ~ 23:59:59（Asia/Shanghai，ES @timestamp UTC 换算） |
| 数据源 | ES 索引 mysql_slow-*（MCP addcn es_slow_logs / es_search，env=staging） |
| 慢日志总条数 | 4,041 条（单页拉全，未达 2 万条上限） |
| SQL 指纹数 | 624 个 |
| Top10 单条耗时 | 1855.8s ~ 275.8s，其中 9 条为 backup 全表导出，1 条为 COMMIT |
| 最大单条 | SELECT * FROM t8891.t_item_modi_histories（backup，1855.8s，569 万行） |
| 高频非备份之最 | qa_hub_designartifact 轮询查询：1,742 条 / 平均 6.4s / 累计 3.1 小时 |
备份窗口：backup 用户在 01 时与 04 时（+8）集中导出，共 438 条 dump 类慢日志。
二、Top10 慢查询明细
| # | 耗时(s) | 用户 | 实例 | SQL 摘要 | rows_sent | rows_examined | 慢因分类 |
|---|
| 1 | 1855.80 | backup | LAN_addcn_84 | SELECT * FROM t8891.t_item_modi_histories | 5,693,964 | 5,693,964 | 备份全表导出（大结果集） |
| 2 | 1413.42 | backup | LAN_addcn_84 | SELECT * FROM t8891.t_sele_item_infos | 3,290,762 | 3,290,762 | 备份全表导出 |
| 3 | 577.46 | backup | LAN_addcn_84 | SELECT * FROM t8891.yahoo_car_details | 16,681 | 16,681 | 备份全表导出 |
| 4 | 349.10 | backup | LAN_addcn_84 | SELECT * FROM t8891.t_subscription_push | 39,105,741 | 39,105,741 | 备份全表导出（3,910 万行） |
| 5 | 340.77 | backup | LAN_addcn_84 | SELECT * FROM t8891.t_sele_item_photos | 22,929,970 | 22,929,970 | 备份全表导出 |
| 6 | 325.02 | backup | LAN_addcn_84 | SELECT * FROM t8891.save_car_details | 9,328 | 9,328 | 备份全表导出（宽行 LONGTEXT） |
| 7 | 316.04 | backup | LAN_addcn_46 | SELECT * FROM t591.t1_daily_report | 30,565,109 | 30,565,109 | 备份全表导出（3,057 万行） |
| 8 | 296.45 | backup | LAN_addcn_51 | SELECT * FROM anylink.access_audit | 63,202,649 | 63,202,649 | 备份全表导出（6,320 万行） |
| 9 | 279.26 | backup | LAN_addcn_84 | SELECT * FROM t8891.telescope_entries | 868,841 | 868,841 | 备份全表导出（Laravel telescope 调试表） |
| 10 | 275.77 | sonic | LAN_addcn_84 | COMMIT; | 0 | 0 | 事务提交慢（组提交/redo 刷盘等待） |
Top10 中 9 条为 mysqldump 全表导出，属预期备份行为；第 10 条 COMMIT 单次 275.77s 属异常（见 4.3）。
三、高频慢查询模式（频次维度）
拉取方式：es_search 翻页（size=5000 × 最多 4 页），实际 1 页取全 4,041 条；指纹归一化（字符串/数字/IN 列表 → ?）后聚合。
3.1 按条数 Top5
| # | 条数 | 平均(s) | 最大(s) | 累计(s) | 用户 | 实例 | SQL 指纹 |
|---|
| 1 | 1,742 | 6.39 | 111.5 | 11,134.6 | addcn8891_test | LAN_addcn_84 | SELECT ... FROM qa_hub_designartifact WHERE mission_id=? AND kind=? AND round=? ORDER BY id DESC LIMIT 1 |
| 2 | 382 | 2.72 | ~300 | 1,038.6 | addcn8891_test | LAN_addcn_84 | SELECT GET_LOCK('tapd-api:?', 300) |
| 3 | 274 | 4.80 | ~276 | 1,313.9 | 多用户(8个) | LAN_addcn_27/37/81/84 | COMMIT; |
| 4 | 172 | 1.61 | — | 277.3 | jmysql | LAN_addcn_27/40_3308 | SHOW ENGINE INNODB STATUS; |
| 5 | 131 | 1.52 | — | 198.5 | 8591/jmysql | LAN_addcn_27/46 | # administrator command: Ping; |
3.2 按累计耗时 Top5
| # | 累计(s) | 条数 | 平均(s) | 用户 | SQL 指纹 | 备注 |
|---|
| 1 | 11,134.6 | 1,742 | 6.39 | addcn8891_test | qa_hub_designartifact mission_id=? AND kind=? AND round=? … LIMIT 1 | ⚠️ 全天最大耗时源 |
| 2 | 2,015.1 | 46 | 43.81 | addcn8891_test | qa_hub_designartifact mission_id=? AND NOT(…) 变体 | 同表另一模式，平均更差 |
| 3 | 1,855.8 | 1 | 1855.80 | backup | SELECT * FROM t8891.t_item_modi_histories | 备份模式（单独标注，不深挖） |
| 4 | 1,413.4 | 1 | 1413.42 | backup | SELECT * FROM t8891.t_sele_item_infos | 备份模式 |
| 5 | 1,313.9 | 274 | 4.80 | 多用户 | COMMIT; | 事务提交慢 |
四、触发深度分析的模式（条数>100 或 累计>30min）
4.1 qa_hub_designartifact 轮询查询（1,742 条 / 3.1h，另有变体 46 条 / 33.6min）⚠️ 主要问题
- 代表性 SQL（库
aiworkflow，实例 staging/8891，user=addcn8891_test）：
SELECT id, mission_id, task_id, round, kind, payload, digest, created_at
FROM qa_hub_designartifact
WHERE mission_id='b83cb...' AND kind='delivery_receipt' AND round=10
ORDER BY id DESC LIMIT 1;
- DDL（
describe_schema 实查）：表仅 约 252 行；PRIMARY KEY(id)，UNIQUE(task_id, kind)，KEY mission_id(mission_id)，含 payload JSON + content LONGTEXT 宽行。
- EXPLAIN（等价查询实查）：
access_type=ref，命中 mission_id 索引，rows_examined_per_scan≈109，using_index=true，query_cost≈24.6 —— 执行计划健康，不缺索引。
- 时间分布：全天工作时段持续，17~19 时峰值（316/368/183 条）；与 01/04 时备份窗口不相关。
- 根因判定：表仅 252 行且走索引仍平均 6.4s、最大 111s、
Lock_time 仅 0.0001s——瓶颈不在扫描而在排队：同一应用（QA 任务框架）以 GET_LOCK('tapd-api:…', 300)（382 次，即串行化锁）+ 高频轮询该表，疑似实例在高峰时段被该轮询风暴 + 长事务/组提交阻塞拖慢（同实例 COMMIT 亦出现 275s 极值）。
- 建议：
- 降低轮询频率 / 改为事件通知（任务完成后回调），1,742 次/天 → 可削减 90%+；
- 复合索引优化（虽非当前瓶颈，可消排序）：
ALTER TABLE aiworkflow.qa_hub_designartifact ADD INDEX idx_mission_kind_round_id (mission_id, kind, round, id)，使 ORDER BY id DESC LIMIT 1 免 filesort；
- 排查 17~19 时段
addcn8891_test 长事务（information_schema.innodb_trx），确认是否有事务持有行锁/MDL 导致读排队；
GET_LOCK 300s 超时过长，建议降到 30s 并加监控。
4.2 SELECT GET_LOCK('tapd-api:…', 300)（382 条 / 17.3min）
- 无表访问，EXPLAIN 显示
No tables used。慢因即锁等待本身：同一把命名锁被串行争抢，等待计入 Query_time。属应用层串行化设计，与 4.1 同源，随轮询治理一并缓解。
4.3 COMMIT;（274 条 / 21.9min，最大 275.77s，user=sonic 等 8 个）
- EXPLAIN 不适用（非 DML）。
Lock_time=0 而耗时高，指向 redo 刷盘/组提交排队或大事务落盘：sonic 单次 COMMIT 275.77s 说明该事务累计了大量变更（或被 binlog/IO 队列阻塞）。
- 建议：排查 sonic 账号在 11-04 的大事务（binlog
mysqlbinlog --start-datetime 抽查）；确认实例 innodb_flush_log_at_trx_commit 与磁盘 IO 水位；应用侧批量写入分批提交。
4.4 SHOW ENGINE INNODB STATUS（172 条）与 # Ping（131 条）
- 均为管理命令，EXPLAIN 不适用。条数多本身说明有监控在频繁采集（jmysql/8591），且采集时实例响应慢（>1s 才进慢日志）。属"症状而非病因"：侧面印证 tw8591/LAN_addcn_27 实例白天存在资源压力。建议核查监控采集频率（建议 ≥30s 一次即可）。
五、逐条优化建议汇总
- aiworkflow.qa_hub_designartifact 轮询风暴（最高优先级）：改事件驱动/降频；可加复合索引
(mission_id, kind, round, id)；排查 17~19 时长事务。预期消除全天 3.1h 慢日志。
- COMMIT 275s（sonic）：定位大事务与 IO 瓶颈，分批提交。
- 备份导出：9/10 的 Top10 来自 mysqldump。行数超 3,000 万的
t_subscription_push、t1_daily_report、access_audit 建议改 mydumper 并行/分库分表导出或增量备份，避开业务时段（当前 01/04 时影响小，可维持）。
- telescope_entries：Laravel 调试表入备份慢日志，staging 建议关闭 telescope 或缩短保留期。
- 监控采集：
SHOW ENGINE INNODB STATUS 172 次/天偏频，降频至 30s+。
六、数据来源与生成时间
- 数据来源：MCP addcn（http://192.168.8.75:8200/mcp）
es_slow_logs(top=10, env=staging)、es_search(mysql_slow-*)、connect/describe_schema/explain/count_estimate/disconnect（全程只读，无写操作、无 KILL、无配置变更）。
- 慢日志时间字段
@timestamp（UTC），区间 [2026-11-04T00:00:00+08:00, 2026-11-05T00:00:00+08:00)。
- 生成时间：2026-11-05 10:0x (Asia/Shanghai)；生成脚本：
.agents/scripts/slow_report_20261104_run.py，中间数据 outputs/analysis_20261104.json。