MySQL 慢查询日报 2026-10-27

统计范围：2026-10-27 00:00:00 ~ 23:59:59（Asia/Shanghai）· 环境：staging

数据来源：MCP es_slow_logs / es_search（ES 索引 mysql_slow-*，按 @timestamp UTC 过滤）

一、统计概览

按用户耗时分布（Top）：

二、Top10 慢查询明细

Top10 结论：10 条中 9 条为 backup 账号的 mysqldump 全表导出，全部为 type=ALL 全表扫描、Lock_time 均 <0.001s（无锁等待），属「备份大结果集传输 + 全表扫描」，为常规备份开销，非业务劣化信号；第 8 条 commit; 见深度分析。

三、高频慢查询模式（频次维度）

对全日 1,581 条慢日志做 SQL 指纹归一化（字符串/数字/IN 列表 → ?）后聚合，共 585 个模式。

3.1 按条数 Top5

3.2 按累计耗时 Top5

【备份模式】= user=backup（mysqldump 全表导出），按口径不触发深度分析。backup 用户全日共 413 条、累计 11,813s（含 databasus_backup 另 12 条/325s），条数与日常备份规模持平，未见明显环比异常。

⚠️ = 触发深度分析条件（非备份且条数 >;100 或累计 >30min）。

🔴 = 未达触发阈值，但单条均值显著偏高（28.9s），已补充 explain 分析。

四、深度分析（触发阈值模式 + 高风险补充）

4.1 commit;（191 条 / 累计 804s / 最大 275s）⚠️

• 分布：sonic(166 条为主)、jumper、bee、addcn8891_test、jumper_dev，集中在 LAN_addcn_84（8891 环境）、LAN_addcn_27/37；Lock_time=0，无锁等待。
• 分析路径：非 SELECT 语句，EXPLAIN 不适用；结合同实例现象判断根因。
• 根因：commit 慢 = 事务提交时 redo 刷盘/组提交排队等待，而非 SQL 本身。LAN_addcn_84（staging/8891）昨日凌晨正执行大规模 mysqldump 备份（Top10 中 5 条 229~3910 万行级全表导出都在该实例），大量 SELECT SQL_NO_CACHE 扫描挤压 IO、拖长 fsync。应用侧 sonic 存在长事务/批量提交模式，遇到 IO 高峰时单次 commit 最长等 275s。
• 建议：

1. 应用侧（sonic 对应服务）排查长事务：将大事务拆小、避免单事务内堆积大量行变更后统一 commit；
2. 备份错峰：将 mysqldump 与业务批量任务时段错开（当前备份与 sonic 批处理重叠）；
3. 若持续出现，检查 staging/8891 实例磁盘 IO 利用率与 innodb_flush_log_at_trx_commit 配置（staging 可评估设为 2）。

4.2 SHOW ENGINE INNODB STATUS（172 条 / 累计 253s）⚠️

• 用户 jmysql（监控采集账号），跨 4 台服务器，平均 1.47s、最大 2.76s。
• 根因：监控采集本身开销：该命令需要拿 LOCK_wait 相关 mutex 并生成完整 engine 状态文本，在并发繁忙实例上 1~3s 属常见；条数多（每分钟多实例采集）使其进入高频榜。
• 建议：属监控固有成本，不建议消除；如需降噪，可将采集频率从分钟级降到 5 分钟级，或在慢日志采集侧对 jmysql 账号的 SHOW 语句设置 long_query_time 豁免（如 pt-query-digest 采集时过滤 user=jmysql 的 SHOW 语句）。

4.3 补充：h8_finance_account_logs 余额汇总（19 条 / 平均 28.9s / 累计 550s）🔴

SELECT sum(after_amount - before_amount) AS balance
FROM `hk8591`.`h8_finance_account_logs`
WHERE user_id = ? AND sub_account = 11;

• 表规模：约 1,359 万行（count_estimate: 13,589,398）。
• EXPLAIN（staging/hk8591 主库实测）：
• access_type=ref，possible_keys=[asacca, idx_user_sub_account_id]，key=asacca，used_key_parts=[user_id]（只用了第一列！），rows_examined_per_scan=33,434，filtered=10%，sub_account = 11 仅作为 index_condition（ICP 过滤）。
• 现有索引：asacca (user_id, sub_account, course, created_at)、idx_user_sub_account_id (user_id, sub_account, id DESC)、PK(id)。
• 根因：sub_account 是 char(2)，SQL 写 sub_account = 11（数字字面量）触发隐式类型转换，MySQL 无法把该条件作为索引 key part，只能用 user_id 前缀扫描后再过滤，单用户流水多的账号要回表/过滤数万行，平均 28.9s。
• 建议（可执行）：

1. 改 SQL：sub_account = '11'（加引号，匹配 char 类型），即可完整命中 asacca(user_id, sub_account) 两列前缀，扫描量预计从 ~3.3 万行降到精确范围；
2. 该查询为余额汇总，若调用频繁可考虑用余额快照表/缓存替代实时 SUM；
3. 排查 hk8591 代码中所有对 sub_account 的数字字面量写法（grep sub_account = 11 / sub_account in (11,...)），统一改为字符串。

4.4 补充：h8_orders buyer_id 批量查询（52 条 / 平均 2.28s / 最大 15.5s）

SELECT id, buyer_id, completed_at FROM h8_orders WHERE buyer_id IN (1010170, ...);

• EXPLAIN（实测）：access_type=range，key=bica (buyer_id)，rows_examined≈20/每值，cost 25.8 —— 索引本身健康。
• 根因：执行计划良好，慢主要来自 IN 列表过大（批量任务一次查几十上百个 buyer_id）+ 回表 + 与备份时段重叠的 IO 争抢（服务器 LAN_addcn_27_3307 同时段在跑 h8_finance_account_logs 全表导出备份）。
• 建议：单条 1~4s 可接受；如需优化，将超大 IN 列表分批（每批 ≤50），并确保只取必要列（当前已是窄列查询，无需改索引）。

五、逐条优化建议汇总

六、数据来源与生成时间

• 慢日志：MCP es_slow_logs（top=10, env=staging, start=2026-10-27T00:00:00+08:00）；高频模式：MCP es_search（索引 mysql_slow-*，search_after 分页，全日 1,581 条 / 1 页拉取完成）。
• 结构与执行计划：MCP connect / describe_schema / explain / count_estimate / find_instance，全程只读，分析后已 disconnect。
• 报告生成时间：2026-10-28 10:0x（Asia/Shanghai），由 DSH 会话自动生成。
• 说明：Top10 与高频模式均基于昨日（2026-10-27）数据，未触发前日回退；指纹聚合与深度分析链路均执行成功，无失败项。