| 指标 | 数值 |
|---|---|
| 统计范围 | 2026-11-03 00:00:00 ~ 23:59:59（Asia/Shanghai，staging 环境） |
| 慢日志总条数 | 2,907 条 |
| 累计耗时 | 23,466.5s ≈ 6.52 小时 |
| 备份（user=backup / mysqldump） | 411 条，累计 13,206.2s ≈ 3.67 小时（占比 56%） |
| 非备份慢查询 | 2,496 条，累计 10,260.3s ≈ 2.85 小时 |
| 涉及实例（server_name） | LAN_addcn_84 (1467)、LAN_addcn_27 (579)、LAN_addcn_46 (265)、LAN_addcn_27_3307 (234)、LAN_addcn_40_3308 (177)、LAN_addcn_37 (103) 等 9 台 |
数据来源：MCPes_slow_logs（Top10）+es_search索引mysql_slow-*全量拉取（2,907 条，1 页，指纹归一化后 616 个模式）。
| # | Query_time | 库.表 | SQL 摘要 | 行数(sent/examined) | user | 慢因分类 |
|---|---|---|---|---|---|---|
| 1 | 1742.8s | t8891.t_item_modi_histories | SELECT SQL_NO_CACHE * FROM t8891.t_item_modi_histories | 5,693,964 / 5,693,964 | backup | 备份全表导出（569万行，宽历史表） |
| 2 | 1207.7s | t8891.t_sele_item_infos | SELECT SQL_NO_CACHE * FROM t8891.t_sele_item_infos | 3,290,762 / 3,290,762 | backup | 备份全表导出 |
| 3 | 545.4s | t8891.yahoo_car_details | SELECT SQL_NO_CACHE * FROM yahoo_car_details | 16,681 / 16,681 | backup | 备份导出（单行极宽，LOB 列） |
| 4 | 347.1s | t8891.t_subscription_push | SELECT SQL_NO_CACHE * FROM t_subscription_push | 39,105,741 / 39,105,741 | backup | 备份全表导出（3910万行） |
| 5 | 343.8s | t8891.t_sele_item_photos | SELECT SQL_NO_CACHE * FROM t_sele_item_photos | 22,929,970 / 22,929,970 | backup | 备份全表导出 |
| 6 | 333.7s | t8891.save_car_details | SELECT SQL_NO_CACHE * FROM save_car_details | 9,328 / 9,328 | backup | 备份导出（单行极宽） |
| 7 | 314.1s | t591.t1_daily_report | SELECT SQL_NO_CACHE * FROM t591.t1_daily_report | 30,545,466 / 30,545,466 | backup | 备份全表导出（3054万行） |
| 8 | 300.1s | —（staging/8891） | commit; | 0 / 0 | sonic | 其他（事务提交/刷盘等待，见 §4.2） |
| 9 | 291.3s | anylink.access_audit | SELECT SQL_NO_CACHE * FROM anylink.access_audit | 63,506,851 / 63,506,851 | backup | 备份全表导出（6350万行，Top1 行数） |
| 10 | 291.0s | —（staging/8891） | COMMIT; | 0 / 0 | addcn8891_test | 其他（大事务/组提交刷盘） |
小结：Top10 中 7 条为 mysqldump 备份全表导出，属于预期负载；其余 2 条为 COMMIT 慢（redo fsync / 大事务提交），1 条同上。非备份侧真正需要关注的是 §3 的高频模式。
指纹归一化规则：字符串/数字字面量、IN 列表 → ?；共 2,907 条文档、616 个指纹。
| # | 条数 | 平均耗时 | 最大耗时 | 累计耗时 | 涉及 server | 模式（SQL 骨架） | 备注 |
|---|---|---|---|---|---|---|---|
| 1 | 845 | 5.55s | 60.1s | 78.2 min | LAN_addcn_84 | SELECT id,mission_id,task_id,round,kind,payload,(content),digest,created_at FROM qa_hub_designartifact WHERE mission_id=? AND kind=?/NOT kind=? ORDER BY id DESC | ⚠️ 触发深度分析（§4.1） |
| 2 | 286 | 5.04s | 300.1s | 24.0 min | LAN_addcn_27/37/84 | COMMIT;（user: sonic/addcn8891_test 等） | 提交/刷盘等待，非可优化 SQL（§4.2） |
| 3 | 176 | 1.48s | 3.0s | 4.3 min | LAN_addcn_27/46 | # administrator command: Ping; | 采集端把慢 Ping 记入日志，非 SQL 问题 |
| 4 | 170 | 1.58s | 2.7s | 4.5 min | 5 台 | SHOW ENGINE INNODB STATUS; | 监控探针，本身耗时受服务器繁忙影响 |
| 5 | 125 | 1.47s | 2.7s | 3.1 min | LAN_addcn_27 | rollback; | 回滚等待，间接反映存在慢事务 |
| # | 条数 | 平均耗时 | 最大耗时 | 累计耗时 | 涉及 server | 模式（SQL 骨架） | 备注 |
|---|---|---|---|---|---|---|---|
| 1 | 845 | 5.55s | 60.1s | 78.2 min | LAN_addcn_84 | SELECT … FROM qa_hub_designartifact WHERE mission_id=? … ORDER BY id DESC | ⚠️ 深度分析见 §4.1 |
| 2 | 1 | 1742.8s | 1742.8s | 29.0 min | LAN_addcn_84 | SELECT SQL_NO_CACHE * FROM t8891.t_item_modi_histories | 🗄️ 备份导出（单独标注，不深度分析） |
| 3 | 286 | 5.04s | 300.1s | 24.0 min | 3 台 | COMMIT; | 见 §4.2 |
| 4 | 1 | 1207.7s | 1207.7s | 20.1 min | LAN_addcn_84 | SELECT SQL_NO_CACHE * FROM t8891.t_sele_item_infos | 🗄️ 备份导出 |
| 5 | 1 | 545.4s | 545.4s | 9.1 min | LAN_addcn_84 | SELECT SQL_NO_CACHE * FROM t8891.yahoo_car_details | 🗄️ 备份导出 |
另值得注意（未进 Top5 但有意义）：SELECT sum(after_amount-before_amount) FROM h8_finance_account_logs WHERE user_id=? AND sub_account=?，17 条、平均 31.1s、累计 8.8 min（LAN_addcn_27_3307）。未达深度分析阈值（<100 条且 <30min），但平均 31s 的聚合值得后续观察该表索引（后续可补 EXPLAIN 确认 (user_id, sub_account) 复合索引是否存在）。
备份模式说明：user=backup 的 mysqldump 全表导出共 411 条 / 3.67 小时，条数与近期常规量级一致（未见翻倍异常），按口径不触发深度分析。
aiworkflow.qa_hub_designartifact 查询（845 条 / 累计 78.2 分钟，最大单条 60.1s）代表性原始 SQL（Django ORM 生成，user=addcn8891_test，LAN_addcn_84 → staging/8891）：
SELECT `id`,`mission_id`,`task_id`,`round`,`kind`,`payload`,`digest`,`created_at`
FROM `qa_hub_designartifact`
WHERE (`mission_id` = ? AND NOT (`kind` = 'assets'))
ORDER BY `id` DESC;链路证据（connect → describe_schema → explain，全只读）：
aiworkflow.qa_hub_designartifact：仅 286 行；索引有 PRIMARY(id)、UNIQUE(task_id, kind)、KEY(mission_id)。含 payload json + content longtext 宽列。mission_id，rows_examined_per_scan=23，query_cost=27.60 —— 执行计划本身没有问题，不是缺索引。根因判定：大结果集传输 + 宽行（超大 JSON payload）。查询命中索引、扫描行数极少，慢在每行 2MB 级的 JSON payload 网络传输与序列化，且应用层对同一数据无缓存、重复拉取。845 次 × 平均 5.5s = 全天 78 分钟纯传输时间。
可执行建议：
payload/content 的全列；Django ORM 上用 only()/defer('payload','content') 按需取。payload/content 大 JSON 拆到对象存储（OSS/S3）或独立大字段表，主表只存 digest + 引用键；或对 payload 做 zlib 压缩存储（JSON 压缩比通常 5~10×）。(mission_id, kind, id)（消除 kind 过滤的回表过滤），但对本案例收益远小于 1~3。COMMIT; 慢（286 条 / 24.0 min，最大 300.1s）样本（user=sonic / addcn8891_test，staging/8891 与 591 等）：Query_time 3.0~300s、Lock_time=0。COMMIT 耗时来自 redo 刷盘（fsync）与 binlog 组提交等待，通常被并发的备份导出大事务（§2 中千万行级 mysqldump）拉长。建议：把 staging 的 mysqldump 备份窗口错峰到业务低峰，并考虑 --single-transaction --where 分批或改用 XtraBackup 物理备份，减少大事务对组提交的挤压；非 SQL 改写类问题。
| 优先级 | 对象 | 建议 |
|---|---|---|
| P0 | aiworkflow.qa_hub_designartifact 845 次/日 | ORM defer 大列 + 结果缓存（§4.1-1/2）；中期大 JSON 出库到对象存储 |
| P1 | staging/8891 备份窗口 | mysqldump 错峰、分批，缓解 COMMIT 慢（§4.2） |
| P2 | h8_finance_account_logs 聚合（平均 31s） | 确认/补 (user_id, sub_account) 复合索引，下期复核 |
| 观察项 | Ping / SHOW ENGINE INNODB STATUS / rollback 模式 | 监控与采集噪声，随服务器负载下降自然缓解 |
es_slow_logs（Top10，env=staging）、es_search（索引 mysql_slow-*，2,907 条全量）、connect/describe_schema/explain/disconnect（结构化深查，全程只读，未执行任何写操作/kill/配置变更）。outputs/analysis_20261103*.json。