MySQL 慢查询日报 2026-10-29（staging）

统计口径：2026-10-29 00:00:00 ~ 23:59:59（Asia/Shanghai），ES 索引 mysql_slow-* 按 @timestamp（UTC）过滤
数据来源：MCP addcn（es_slow_logs Top10 + es_search 全量拉数 2448 条 / 1 页 / 指纹 594 个）；表结构与执行计划均通过 MCP describe_schema / explain 只读获取
生成时间：2026-10-30 10:0x +08:00（自动生成，全程只读，未执行任何写库 / kill / 配置变更）

一、统计概览

指标	值
慢日志条数（昨日全天）	2,448
SQL 指纹数	594
Top10 中 mysqldump 全表导出（user=backup）	8 / 10 条
最慢单条	1,526.9s（backup 导出 `t8891.t_item_modi_histories`，569 万行 / ~14G）
最突出业务模式	`qa_hub_dashboardsnapshot` 查询：645 次 × 平均 2.4s ≈ 25.8 分钟

总判断：昨日 staging 慢查询几乎全部由 mysqldump 全量备份造成的实例级 IO 饱和 引发——192.168.8.84（staging/8891）白天连续导出千万行级大表（14G/20G/33G/80G 级 data_read），同实例的正常小查询（如 11 行的 snapshot 表、commit、SHOW ENGINE INNODB STATUS）被动变慢。

二、Top10 慢查询明细

#	耗时(s)	用户	实例(alias)	库.表	行数 sent=examined	EXPLAIN 要点	慢因类型
1	1526.9	backup	staging/8891	t8891.t_item_modi_histories	5,693,964	type=ALL，query_cost 217.9万，data_read 14G	【备份】大结果集传输
2	1178.8	backup	staging/8891	t8891.t_sele_item_infos	3,290,762	type=ALL，data_read 20G	【备份】大结果集传输
3	474.0	backup	staging/8891	t8891.yahoo_car_details	16,681	type=ALL，data_read 18M（大 JSON 列）	【备份】大结果集传输
4	396.0	backup	staging/8891	t8891.t_subscription_push	39,105,741	type=ALL，3,953 万行，data_read 33G	【备份】大结果集传输
5	321.7	backup	staging/100-slave	t591.t1_daily_report	30,447,251	type=ALL，2,885 万行，data_read 7G	【备份】大结果集传输
6	306.3	backup	staging/8891	t8891.t_sele_item_photos	22,929,970	type=ALL，data_read 80G	【备份】大结果集传输
7	298.1	backup	staging/TD-slave	anylink.access_audit	62,689,911	type=ALL，5,800 万行，data_read 72G	【备份】大结果集传输
8	293.2	sonic	staging/8891	—（`commit;`）	0	事务提交（无法 EXPLAIN）	IO 饱和导致 commit/刷盘排队（同实例备份期间）
9	248.2	backup	staging/TD-slave	anylink_corp.access_audit	56,953,981	type=ALL，5,212 万行，data_read 65G	【备份】大结果集传输
10	237.6	backup	staging/tw8591	hk8591.h8_finance_account_logs	13,603,892	type=ALL，1,359 万行	【备份】大结果集传输（经 192.168.8.27:3307）

Top10 中 9 条为 mysqldump 导出，1 条为受害的 commit。均无锁等待（Lock_time ≤ 0.03s）。

三、高频慢查询模式（指纹聚合，2448 条 / 594 指纹）

3.1 按条数 Top5

#	条数	平均(s)	最大(s)	累计	用户	server	模式（脱参）
1	645	2.40	7.23	1547.6s ≈ 25.8min	addcn8891_test	LAN_addcn_84	`SELECT ... FROM qa_hub_dashboardsnapshot WHERE user_id=? ORDER BY updated_at DESC LIMIT 100` ⚠️
2	253	4.07	293.18	1029.8s	多用户	LAN_addcn_27/37/84	`commit;` ⚠️（非业务 SQL）
3	251	1.55	2.78	388.8s	jmysql	LAN_addcn_37/40/46	`SHOW ENGINE INNODB STATUS;` ⚠️（监控命令）
4	125	1.61	3.01	200.8s	8591/jmysql	LAN_addcn_27/46	`# administrator command: Ping;` ⚠️（连接层）
5	68	1.05	1.41	71.1s	a8591	LAN_addcn_27	`gameList LEFT JOIN hitCount_month ...`

3.2 按累计耗时 Top5

#	累计	条数	平均(s)	模式	备注
1	1547.6s	645	2.40	qa_hub_dashboardsnapshot 查询	见 3.3 深度分析 ①
2	1526.9s	1	1526.9	`SELECT * FROM t8891.t_item_modi_histories`	【备份 mysqldump】
3	1178.8s	1	1178.8	`SELECT * FROM t8891.t_sele_item_infos`	【备份 mysqldump】
4	1029.8s	253	4.07	`commit;`	见 3.3 ②
5	520.8s	17	30.64	`SELECT sum(after_amount-before_amount) FROM h8_finance_account_logs WHERE user_id=? AND sub_account=?`	未触发阈值（17 条），但均耗 30s+，主动附分析 ③

3.3 触发深度分析的模式（条数>100 或累计>30min）

① qa_hub_dashboardsnapshot（645 次 / 25.8 分钟，aiworkflow 库 @ staging/8891）— 已做 describe_schema + explain

DDL：UNIQUE KEY qah_snapshot_user_day (user_id, scope_hash, day)，表仅 11 行，AUTO_INCREMENT=12
EXPLAIN：ref 访问，命中 qah_snapshot_user_day(user_id)，rows_examined=11，query_cost=4.2，仅 using_filesort（ORDER BY updated_at 无法用该索引排序）
根因：不是缺索引。11 行、cost 4.2 的查询平均耗 2.4s，慢因是 实例 192.168.8.84 同时段被 mysqldump 大表导出（Top1/2/3/4/6 均在此实例）打满 IO，该查询以高频轮询（645 次/天 ≈ 每 2 分钟一次）被动受害。
建议：

备份错峰/限流：把 staging/8891 的 mysqldump 移到业务低峰（夜间），并加 --single-transaction --max-allowed-packet + IO 限速（如 pv/cgroup），或改从 8891-slave（192.168.8.59）导出，根治这类"全实例变慢"。
应用侧降低轮询频率或加 60s 缓存（同一 user_id=3 的快照数据一天被拉 645 次）。
可选微优化：把 ORDER BY updated_at DESC LIMIT 100 的排序键并入索引（新索引 (user_id, updated_at)）消除 filesort——对 11 行表收益极小，优先级低。

② commit;（253 次 / 1030s，max 293s）

非业务 SQL，无法 EXPLAIN。分布在与备份重叠的实例（LAN_addcn_84=8891、27/37 等）。根因同①：备份期间 redo/刷盘排队导致 commit 变慢（max 293s 出现在 8891）。建议同①的备份错峰；若排除备份时段后仍慢，再查 innodb_flush_log_at_trx_commit 与磁盘延迟。

③ 附：h8_finance_account_logs 余额汇总（17 次 × 平均 30.6s，@ staging/hk8591 192.168.8.27:3307）— 主动深度分析

表 1,359 万行；现有索引：asacca(user_id,sub_account,course,created_at)、idx_user_sub_account_id(user_id,sub_account,id DESC)、index(receipt_no)
EXPLAIN：命中 idx_user_sub_account_id，但 used_key_parts 仅 [user_id]（sub_account 走 ICP 下推），rows_examined_per_scan=21126、filtered 10%
根因：索引不覆盖——每次回表读 2 万+ 行的 before_amount/after_amount；且该实例同端口也在跑 mysqldump（Top10 #10 同源），缓冲池被冲刷，单次放大到 30s+。
建议：新增覆盖索引 (user_id, sub_account, before_amount, after_amount)，SUM 可纯索引扫描完成，预计降到毫秒级；中期更优做法是账户表维护实时余额字段，避免全生命周期流水 SUM。

④ SHOW ENGINE INNODB STATUS（251 次）/ Ping（125 次）：监控类命令变慢，同样是实例 IO 饱和的症状而非原因，无需单独优化，备份错峰后预计自动恢复。

3.4 备份模式标注（user=backup，不触发深度分析）

昨日 backup 模式（mysqldump 全表导出）单条进入"累计耗时 Top"的有：t_item_modi_histories 1526.9s、t_sele_item_infos 1178.8s、yahoo_car_details 474.0s、t_subscription_push 396.0s 等（详见 Top10 表）。条数与既往常规备份量级一致（每表 1 条），无明显环比翻倍异常，按规则不做深度分析；但它们是本日其他慢查询的主要外因，治理建议见 3.3-①。

四、逐条优化建议（可执行）

【高优】备份错峰 + 限速 + 改走从库：staging/8891（192.168.8.84）的 mysqldump 移到夜间低峰、加 IO 限速，或改在 8891-slave（192.168.8.59）导出。可同时消除 Top10 中 9 条与高频模式①②④的根因。
【高优】hk8591.h8_finance_account_logs 加覆盖索引：ALTER TABLE hk8591.h8_finance_account_logs ADD INDEX idx_user_sub_amt (user_id, sub_account, before_amount, after_amount);（线上执行请用 pt-osc/gh-ost，1,359 万行）。预期 SUM 查询从 30s 降至毫秒级。
【中】aiworkflow.qa_hub_dashboardsnapshot：应用侧对快照查询加 60s 缓存或降频；可选 ADD INDEX idx_user_updated (user_id, updated_at) 消 filesort（收益小）。
【低】h8_orders buyer_id IN(...) 查询：EXPLAIN 命中 bica(buyer_id,created_at) range，仅扫 38 行，SQL 本身健康，慢为实例负载（27_3307 与备份共址）所致，无需改索引。
【低】gameList / t1_design_img 等 1s 级查询：条数与耗时均未触发阈值，EXPLAIN 优先级排后，随备份错峰观察。

五、数据来源与生成时间

ES：staging ES mysql_slow-2026.10.29（经 MCP addcn es_slow_logs / es_search，env=staging）
MySQL：MCP connect → describe_schema → explain → disconnect（只读），实例：staging/8891、staging/hk8591、staging/100-slave、staging/TD-slave 等
高频模式拉数：size=5000 × 1 页，实际 2,448 条，无翻页
生成时间：2026-10-30 10:00+08:00；脚本：.agents/scripts/slow_report_20261029_run.py