MySQL 慢查询日报 2026-10-28

统计概览

指标	数值
统计范围	2026-10-28 00:00:00 ~ 23:59:59（Asia/Shanghai，即 UTC 2026-10-27T16:00 ~ 2026-10-28T16:00）
环境	staging（ES 索引 mysql_slow-*）
慢日志总条数	1,870 条
SQL 指纹数	602 个
Top10 耗时合计	≈ 5,299 s（其中 9 条为 backup 全量导出，占 ≈ 94%）
昨日数据	有（未回退前日）

总体结论：昨日 staging 慢日志以 mysqldump 备份全表导出（user=backup） 为主，条数正常（每表各 1 条，无环比翻倍迹象），不触发深度分析；非备份侧最突出的是 staging/8891（LAN_addcn_84）上 sonic 用户的 148 次 commit 慢提交 与 hk8591.h8_finance_account_logs 余额汇总/明细查询。

Top10 明细表

#	Query_time(s)	用户	主机(实例)	库.表	rows_examined/sent	SQL 摘要	慢因类型
1	1575.99	backup	LAN_addcn_84 (staging/8891)	t8891.t_item_modi_histories	5,693,964 / 5,693,964	mysqldump SELECT * 全表导出	大结果集传输（备份）
2	1150.70	backup	LAN_addcn_84 (staging/8891)	t8891.t_sele_item_infos	3,290,762 / 3,290,762	mysqldump SELECT *	大结果集传输（备份）
3	509.13	backup	LAN_addcn_84 (staging/8891)	t8891.yahoo_car_details	16,681 / 16,681	mysqldump SELECT *（宽表/大字段）	大结果集传输（备份）
4	364.30	backup	LAN_addcn_84 (staging/8891)	t8891.t_subscription_push	39,105,741 / 39,105,741	mysqldump SELECT *	大结果集传输（备份）
5	326.95	backup	LAN_addcn_84 (staging/8891)	t8891.t_sele_item_photos	22,929,970 / 22,929,970	mysqldump SELECT *	大结果集传输（备份）
6	310.58	backup	LAN_addcn_46 (staging/100-slave)	t591.t1_daily_report	30,427,608 / 30,427,608	mysqldump SELECT *	大结果集传输（备份，跑在从库）
7	291.46	backup	LAN_addcn_51 (staging/TD-slave)	anylink.access_audit	62,562,923 / 62,562,923	mysqldump SELECT *	大结果集传输（备份，6200万行审计表）
8	286.56	sonic	LAN_addcn_84 (staging/8891)	—	0 / 0	`commit;`	其他：事务提交慢（大事务/binlog fsync，与同机备份导出叠加 IO 争用高度相关）
9	239.88	backup	LAN_addcn_51 (staging/TD-slave)	anylink_corp.access_audit	56,945,251 / 56,945,251	mysqldump SELECT *	大结果集传输（备份）
10	228.07	backup	LAN_addcn_27_3307 (staging/tw8591)	hk8591.h8_finance_account_logs	13,603,800 / 13,603,800	mysqldump SELECT *	大结果集传输（备份）

EXPLAIN 验证（Top 均已完成 describe_schema + explain，MCP 只读）：#1~#7、#9 全部 access_type=ALL（全表扫描），rows_examined ≈ rows_sent，属"预期内的全量读取"，非缺索引问题；#8 commit 与 #10 库不在所连实例（hk8591 实际在 staging/hk8591 = 192.168.8.27:3307），已在高频模式一节补齐分析。

高频慢查询模式（指纹归一化聚合，全量 1,870 条）

按条数 Top5

#	条数	均耗时(s)	累计耗时	用户	涉及 server	指纹
1	323	1.61	519s	jmysql	LAN_addcn_27_3307、LAN_addcn_40_3308	`SHOW ENGINE INNODB STATUS;`（监控采集）
2	148	4.91	727s	sonic	LAN_addcn_84	`commit;` ⚠️触发深度分析
3	114	1.42	162s	8591/jmysql	LAN_addcn_27、LAN_addcn_46	`# administrator command: Ping;`（连接保活）
4	75	1.42	107s	8591	LAN_addcn_27	`rollback;`
5	68	1.17	80s	a591	LAN_addcn_46	房源列表联查（COALESCE views_30d/vip_level…）

按累计耗时 Top5

#	累计耗时	条数	均耗时(s)	用户	指纹
1	1576s	1	1576.0	backup	SELECT * FROM `t8891`.`t_item_modi_histories`（备份导出，单条，条数正常）
2	1151s	1	1150.7	backup	SELECT * FROM `t8891`.`t_sele_item_infos`（备份导出）
3	727s	148	4.9	sonic	`commit;` ⚠️触发深度分析（条数>;100）
4	519s	323	1.6	jmysql	`SHOW ENGINE INNODB STATUS;` ⚠️触发深度分析（条数>;100）
5	509s	1	509.1	backup	SELECT * FROM `t8891`.`yahoo_car_details`（备份导出）

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

① commit; — 148 条，均 4.91s，最大 286.6s，累计 727s（sonic @ LAN_addcn_84 / staging-8891）

说明：commit 本身无 SQL 执行计划（EXPLAIN 不适用），其耗时代表事务提交阶段的 binlog/redo 刷盘与 IO 等待。
根因：8891 实例（192.168.8.84）昨日同时段在跑 mysqldump 大表导出（见 Top10 #1~#5、#8 单次 286s 的 commit 与 1576s 的导出同机叠加），顺序读全表把 IO 打满，commit 的 fsync 被拉长；属 IO 争用 + 大事务提交，而非缺索引。
建议：

备份错峰：将 mysqldump 调整到业务低峰（如 02:00-05:00），或改用 XtraBackup / --single-transaction + 分库分表分批导出，避免单条 SELECT * 连续读数十分钟。
确认 8891 的 innodb_flush_log_at_trx_commit / sync_binlog 配置；staging 若可容忍，可评估 innodb_flush_log_at_trx_commit=2。
sonic 应用侧排查是否存在超大事务（一次提交过多行），改为分批提交。

② SHOW ENGINE INNODB STATUS; — 323 条，均 1.61s，累计 519s（jmysql 监控 @ 27_3307 / 40_3308）

说明：非业务 SQL，无执行计划可言；是监控 agent 周期性采集 InnoDB 状态。均耗时 1.6s 说明实例当时有锁等待/长 IO（SHOW ENGINE INNODB STATUS 需拿锁查看活跃事务）。
根因：监控频率 × 实例繁忙。323 条/天 ≈ 每 4.5 分钟一次，本身正常；慢在实例侧响应慢，与 hk8591 上 25s 级的余额汇总查询（见③）叠加有关。
建议：保持监控但降低对慢日志的采样噪音——在慢日志采集端将 SHOW ENGINE INNODB STATUS、# administrator command: Ping（114 条）类语句加入白名单过滤，让日报聚焦业务 SQL；同时优先解决③的业务慢查询。

**③ 附加深度分析（未达条数阈值，但均 25.9s 必须关注）：SELECT sum(after_amount-before_amount) … FROM hk8591.h8_finance_account_logs WHERE user_id=? AND sub_account=? — 16 条，均 25.90s，最大 83.1s；同表 SELECT * … ORDER BY id DESC LIMIT ? — 17 条，均 10.36s（8591 @ LAN_addcn_27_3307 = staging/hk8591）**

已完成只读链路：connect(staging/hk8591) → describe_schema → explain → disconnect。
表结构：约 1,362 万行；现有索引 PRIMARY(id)、asacca(user_id, sub_account, course, created_at)、index(receipt_no)、idx_user_sub_account_id(user_id, sub_account, id DESC)。
EXPLAIN（代表性条件）：access_type=ref，命中 asacca 的 (user_id, sub_account) 前缀，优化器估算 rows=1——索引存在且被使用，不是缺索引。
根因：大账户命中行数极大（重度的会员/平台子账户有几十万条流水），SUM 需逐行回表取 before_amount/after_amount（不在 asacca 内），冷数据不在 buffer pool 时产生大量随机 IO → 25~83s；同时监控（②）在该实例上也被拖慢。列表查询 ORDER BY id DESC 优化器选了 asacca 而非 idx_user_sub_account_id，带 filesort。
建议（可执行）：

覆盖索引消除回表：ALTER TABLE hk8591.h8_finance_account_logs ADD KEY idx_user_sub_amt (user_id, sub_account, after_amount, before_amount);（在线 DDL，先在 staging 验证；SUM 查询将变为纯索引扫描）。注意写入放大，此表写入频繁，需评估。
更优方案：余额是典型"可物化"指标——为账户维表/汇总表维护 balance 字段（流水写入时同事务更新），SUM 查询降为 O(1)，根治随机 IO。
列表查询加 FORCE INDEX (idx_user_sub_account_id) 或删掉冗余的 asacca 前缀重叠（asacca 以 (user_id,sub_account) 开头与 idx_user_sub_account_id 前两列重复，可评估保留一个），消除 filesort。

④ 其他值得注意（未触发阈值）

DELETE FROM access_audit WHERE created_at < ? — 1 条 144.8s（anylink @ LAN_addcn_37）：审计表 5,000 万+ 行的大范围删除，建议改分批 DELETE（每批 1~5 万行 + sleep）并确认 created_at 有索引。
house_repost 续刊扫描（a591 @ LAN_addcn_44，2 条 1.1~1.2s）：EXPLAIN 已验证 access_type=ALL 全表扫描 19.6 万行 + filesort，仅有 KEY type(type, post_id)；建议 ADD KEY idx_pay_status_rectime (ispay, status, rectime)（MyISAM 表，锁表风险低但建议低峰执行）。
h8_orders buyer_id IN(...) + state + order by created_at — 44 条均 2.35s：确认 h8_orders(buyer_id, state, created_at) 组合索引是否存在。

逐条优化建议汇总

备份窗口错峰（Top10 #1~#7/#9/#10、commit 慢）：mysqldump 移到低峰，或换物理备份/分批导出；backup 模式条数正常，无需其他处理。
h8_finance_account_logs：加覆盖索引 idx_user_sub_amt 或改余额汇总表（见③，优先方案 2）。
house_repost：加 (ispay, status, rectime) 索引。
access_audit / access_audit（anylink_corp）：6,200 万/5,700 万行审计表，备份 + DELETE 都慢；建议按月分区或定期归档，DELETE 改分批。
慢日志采集降噪：过滤 SHOW ENGINE INNODB STATUS、Ping、commit/rollback 等非业务语句，提升日报信噪比。

数据来源与生成时间

数据来源：MCP addcn（http://192.168.8.75:8200/mcp）——es_slow_logs（Top10，env=staging）、es_search（mysql_slow-* 全量 1,870 条，@timestamp UTC+8 昨日全天）、describe_schema / explain（staging/8891、staging/100-slave、staging/TD-slave、staging/tw8591、staging/hk8591、staging/100，全程只读，分析后均已 disconnect）。
指纹归一化：字符串/数字/IN 列表替换为 ?，保留库表与 SQL 骨架；聚合统计条数/均值/最大值/累计耗时。
生成时间：2026-10-29 10:0x（Asia/Shanghai）。