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

统计口径：2026-10-26 00:00:00 ~ 23:59:59（Asia/Shanghai，UTC+8），ES 慢日志按 @timestamp 过滤（UTC 区间 [2026-10-25T16:00:00Z, 2026-10-26T16:00:00Z)）
数据来源：MCP addcn es_slow_logs（env=staging, top=10）+ es_search（索引 mysql_slow-*，全量翻页拉取）
慢日志条数：1,695 条（含 SQL 字段），去重指纹 597 个
生成时间：2026-10-27 10:00 (UTC+8)
访问方式：全程只读（SELECT / SHOW / EXPLAIN），无写库、无 kill、无配置变更

一、统计概览

指标	数值
昨日慢日志总条数	1,695
SQL 指纹数	597
Top1 慢查询	1553.3s（backup 全表导出 `t8891.t_item_modi_histories`）
Top10 中 backup 导出占比	9/10
高频模式 Top1（非备份）	`commit;` 217 条 / 累计 875.6s
触发深度分析的模式	`commit;`（条数>100）、`SELECT sum(...) h8_finance_account_logs`（单条均 34s）

Top10 几乎全部为 mysqldump 备份全表导出（user=backup），属预期行为；真正值得关注的是 commit; 平均 4s、全天 217 次（事务提交/IO 压力）与 h8_finance_account_logs 余额汇总查询单条 34s。

二、Top10 慢查询明细

#	Query_time(s)	Lock_time(s)	Rows_sent	Rows_examined	用户	实例	SQL（截断）	慢因
1	1553.28	0.0006	5,693,964	5,693,964	backup	staging/8891	SELECT /!40001 SQL_NO_CACHE / * FROM `t8891`.`t_item_modi_histories`	备份全表导出（EXPLAIN: ALL 全扫，data_read ≈14G/次）
2	1141.24	0.0003	3,290,762	3,290,762	backup	staging/8891	SELECT /!40001 SQL_NO_CACHE / * FROM `t8891`.`t_sele_item_infos`	备份全表导出（ALL，≈20G/次）
3	477.00	0.0002	16,681	16,681	backup	staging/8891	SELECT /!40001 SQL_NO_CACHE / * FROM `t8891`.`yahoo_car_details`	备份全表导出（宽行 text 列，ALL）
4	339.94	0.0003	39,105,741	39,105,741	backup	staging/8891	SELECT /!40001 SQL_NO_CACHE / * FROM `t8891`.`t_subscription_push`	备份全表导出（3900 万行）
5	313.65	0.0001	22,929,970	22,929,970	backup	staging/8891	SELECT /!40001 SQL_NO_CACHE / * FROM `t8891`.`t_sele_item_photos`	备份全表导出
6	302.17	0.0000	30,388,322	30,388,322	backup	staging/100-slave	SELECT /!40001 SQL_NO_CACHE / * FROM `t591`.`t1_daily_report`	备份全表导出（≈7G/次）
7	293.46	0.0000	0	0	sonic	staging/8891	commit;	大事务提交：redo/undo 刷盘耗时（受同机 backup 导出 IO 挤压），非锁等待
8	286.19	0.0000	62,342,613	62,342,613	backup	staging/TD-slave	SELECT /!40001 SQL_NO_CACHE / * FROM `anylink`.`access_audit`	备份全表导出（6234 万行审计大表）
9	252.17	0.0000	56,913,331	56,913,331	backup	staging/TD-slave	SELECT /!40001 SQL_NO_CACHE / * FROM `anylink_corp`.`access_audit`	备份全表导出
10	224.56	0.0002	13,603,616	13,603,616	backup	staging/tw8591	SELECT /!40001 SQL_NO_CACHE / * FROM `hk8591`.`h8_finance_account_logs`	备份全表导出

慢因判定说明（每条均已走 describe_schema + EXPLAIN）：

备份导出：rows_sent == rows_examined 且 EXPLAIN access_type=ALL，无索引可用性问题，属 mysqldump 正常行为；占用 IO 是其主要影响。
#7 commit;：Lock_time≈0、rows=0，为事务提交阶段 redo 刷盘/ purge 耗时，归类「其他（IO/大事务）」。

三、高频慢查询模式（指纹聚合，1,695 条 / 597 指纹）

按条数 Top5

#	条数	均耗时(s)	最大(s)	累计(s)	用户	服务器	模式（归一化）	备注
1	217	4.04	293.46	875.6	a8591/bee/sonic 等 7 个	LAN_addcn_27/37/84	`commit;`	⚠️ 触发深度分析
2	156	1.50	-	233.3	8591/jmysql	LAN_addcn_27/46	`# administrator command: Ping;`	连接空闲/网络抖动，非 SQL 慢
3	121	1.38	-	167.0	jmysql	多台	`SHOW ENGINE INNODB STATUS;`	监控采集争抢锁，非业务
4	71	1.40	-	99.3	8591	LAN_addcn_27	`rollback;`	事务回滚，多为显式事务失败
5	66	2.61	-	172.0	8591	LAN_addcn_27_3307	select id,buyer_id,completed_at from h8_orders where buyer_id in (?…)	buyer_id 走索引，量级正常

按累计耗时 Top5

#	条数	均耗时(s)	累计(s)	用户	服务器	模式（归一化）	备注
1	1	1553.28	1553.3	backup	LAN_addcn_84	SELECT * FROM `t8891`.`t_item_modi_histories`	【备份】不深度分析
2	1	1141.24	1141.2	backup	LAN_addcn_84	SELECT * FROM `t8891`.`t_sele_item_infos`	【备份】
3	217	4.04	875.6	多用户	3 台	`commit;`	⚠️ 触发深度分析
4	17	34.15	580.6	多用户	LAN_addcn_27_3307	SELECT sum(after_amount-before_amount) FROM `h8_finance_account_logs` WHERE user_id=? AND sub_account=?	⚠️ 深度分析（见下）
5	1	477.00	477.0	backup	LAN_addcn_84	SELECT * FROM `t8891`.`yahoo_car_details`	【备份】

*backup 模式（mysqldump 全表导出）条数与常规日持平，无环比翻倍迹象，不触发深度分析。

四、深度分析详情

4.1 `commit;` —— 217 条 / 平均 4.04s / 累计 875.6s（触发条件：条数 > 100）

现象：分布用户广（a8591、bee、chenruijia、eagle、jumper、jumper_dev、sonic），跨 3 台服务器（LAN_addcn_27/37/84），另有单条 293s 的 sonic commit;（Top10 #7）。
EXPLAIN/DDL 链路：commit 无执行计划可查（EXPLAIN 返回空）；已核对 staging/8891 连接状态，非 MDL/行锁阻塞（Lock_time≈0）。
根因：事务提交阶段 redo flush 耗时。昨日 staging/8891、TD-slave、100-slave 同时跑 mysqldump 全量导出（Top10 中 9 条，单条最长 25 分钟、IO 吞吐 14~20G/表），磁盘 IO 被备份占用，导致业务事务 commit 平均拉长到 4s。
建议：

备份错峰：将 mysqldump 调整到业务低峰（如 02:00-05:00），并按表分批限速（--single-transaction + pipeviewer/ ionice 降 IO 优先级）。
排查应用侧长事务：sonic 的 293s commit 提示可能存在大事务（批量写入未分片），建议单事务控制在 1,000~5,000 行。

4.2 `SELECT sum(after_amount - before_amount) ... FROM h8_finance_account_logs WHERE user_id=? AND sub_account=?` —— 17 条 / 平均 34.15s / 累计 580.6s

链路：connect staging/hk8591 → describe_schema → EXPLAIN（实测，非推测）。
现有索引（hk8591.h8_finance_account_logs，约 1,360 万行）：
PRIMARY (id)
KEY asacca (user_id,sub_account,course,created_at)
KEY receipt_no (receipt_no)
KEY idx_user_sub_account_id (user_id,sub_account,id DESC)
EXPLAIN 结果：access_type=ref，命中 idx_user_sub_account_id，但 used_key_parts=["user_id"]（仅用首列），sub_account=11 靠 ICP 过滤（filtered 10%），rows_examined_per_scan≈21,126，data_read_per_join≈2M——每条查询回表 2 万+ 行读取整行数据，仅为求 4 个列的和。
慢因类型：缺覆盖索引（回表放大），叠加该表白天同时被 mysqldump 全量导出抢占 IO。
建议（可执行）：

  ALTER TABLE h8_finance_account_logs
    ADD INDEX idx_user_sub_acc_amounts (user_id, sub_account, before_amount, after_amount);

使 SUM 查询成为 index-only scan（消除 2 万次/次的回表）；若该查询来自余额展示接口，另建议在应用层做余额快照表或缓存（账户余额 = 末条 after_amount，无需全量 SUM）。

五、逐条优化建议汇总

backup 导出（Top10 9 条）：错峰 + 限速；大表（t_subscription_push 3,900 万行、access_audit 6,200 万行）建议改用 xtrabackup/物理备份或分库分批导出，避免白天长时间占 IO。
commit; 高频变慢（217 条）：见 4.1，备份错峰 + 应用侧控制事务大小。
h8_finance_account_logs SUM 查询：见 4.2，加覆盖索引 (user_id, sub_account, before_amount, after_amount)。
SHOW ENGINE INNODB STATUS 121 条：监控（jmysql）在慢日志窗口内采集自身被拖慢，属备份 IO 挤压的次生现象，备份错峰后自然恢复。
h8_orders buyer_id IN 查询（66 条/均 2.6s）：buyer_id 已走索引、未达深度分析阈值（<100 条且 <30 分钟），维持观察。

六、数据来源与生成时间

MCP 服务：http://192.168.8.75:8200/mcp（工具：es_slow_logs / es_search / connect / describe_schema / explain / disconnect / find_instance / list_available_connections）
拉数脚本：.agents/scripts/slow_report_20261026_run.py；原始数据：outputs/analysis_20261026.json（Top10+指纹聚合+深度分析）、outputs/analysis_20261026_h8fin.json（h8_finance 深挖）
生成时间：2026-10-27 10:00+08:00 · 全程只读