MySQL 慢查询日报 2026-10-20

统计口径：2026-10-20 00:00:00 ~ 23:59:59（Asia/Shanghai），ES @timestamp 过滤（UTC 区间 [2026-10-20T00:00:00+08:00, 2026-10-21T00:00:00+08:00)）。

数据来源：MCP es_slow_logs / es_search（staging，索引 mysql_slow-*）；表结构与执行计划经 MCP connect → describe_schema → explain（全程只读）。

生成时间：2026-10-21 10:10 (UTC+8)。

一、统计概览

指标	数值
慢查询总条数	1,721
累计耗时	16,693 s（≈ 4.64 h）
其中备份导出（user=backup）	429 条 / 12,793 s（占耗时 76.6%）
非备份慢查询	1,292 条 / 3,900 s
慢查询用户 Top5	backup(429)、a8591(334)、8591(317)、jmysql(243)、sonic(170)
来源主机 Top5	LAN_addcn_27(525)、LAN_addcn_84(374)、LAN_addcn_46(268)、LAN_addcn_27_3307(242)、LAN_addcn_40_3308(189)
去重指纹数	604

二、Top10 慢查询明细

#	耗时(s)	用户	库.表	rows_examined/sent	类型判定
1	1620.13	backup	t8891.t_item_modi_histories	5,693,964 / 5,693,964	备份全表导出（大结果集传输）
2	1181.74	backup	t8891.t_sele_item_infos	3,290,762 / 3,290,762	备份全表导出
3	522.67	backup	t8891.yahoo_car_details	16,681 / 16,681	备份全表导出（行均耗时高，宽行）
4	384.20	backup	t8891.t_subscription_push	39,105,741 / 39,105,741	备份全表导出（3910 万行大表）
5	339.20	backup	t591.t1_daily_report	30,270,464 / 30,270,464	备份全表导出（3027 万行大表）
6	304.01	sonic	(事务提交) `commit;`	0 / 0	其他：大事务/IO 提交延迟，非查询扫描
7	296.15	backup	t8891.t_sele_item_photos	22,929,970 / 22,929,970	备份全表导出
8	282.58	backup	anylink.access_audit	61,767,990 / 61,767,990	备份全表导出（6177 万行，当日最大扫描量表）
9	274.54	backup	hk8591.h8_orders	2,664,384 / 2,664,384	备份全表导出
10	265.35	backup	hk8591.h8_finance_account_logs	13,603,054 / 13,603,054	备份全表导出

Top10 中 9 条为 mysqldump 全表导出（user=backup），Lock_time 均 <1ms，属于纯大结果集顺序读传输，无索引问题，不做深度分析。唯一非备份条目是 sonic 用户的 commit;（304s），属大事务提交/IO 刷新延迟，与查询计划无关（详见 3.2）。

三、高频慢查询模式（指纹聚合，1721 条 / 604 个指纹）

指纹归一化规则：字符串/数字字面量、IN 列表 → ?，保留库表名与 SQL 骨架。

3.1 按条数 Top5

#	条数	平均(s)	最大(s)	累计(s)	用户	主机	指纹（截断）
1	270	1.05	1.57	282.2	a8591	LAN_addcn_27	SELECT ... FROM gameList a LEFT JOIN hitCount_month b ON a.id=b.hitId AND b.hitType=? AND b.themonth=? WHERE a.id not in(?) ... ORDER BY b.monthTotal DESC ⚠️
2	171	1.62	2.84	276.8	jmysql	LAN_addcn_37/40_3308	SHOW ENGINE INNODB STATUS; ⚠️
3	170	4.71	304.01	800.7	sonic	LAN_addcn_84	commit; ⚠️
4	75	1.21	1.48	90.4	a591	LAN_addcn_46	select i.*, COALESCE(...) from `t1_design_i...`
5	70	1.32	2.45	92.1	8591/jmysql	LAN_addcn_27/46	# administrator command: Ping;

3.2 按累计耗时 Top5

#	累计(s)	条数	平均(s)	最大(s)	用户	主机	指纹（截断）
1	1620.1	1	1620.13	1620.13	backup 🗄️	LAN_addcn_84	SELECT /!? SQL_NO_CACHE / * FROM `t8891`.`t_item_modi_histories`
2	1181.7	1	1181.74	1181.74	backup 🗄️	LAN_addcn_84	SELECT ... FROM `t8891`.`t_sele_item_infos`
3	800.7	170	4.71	304.01	sonic	LAN_addcn_84	commit; ⚠️
4	522.7	1	522.67	522.67	backup 🗄️	LAN_addcn_84	SELECT ... FROM `t8891`.`yahoo_car_details`
5	497.8	16	31.11	74.34	8591	LAN_addcn_27_3307	SELECT sum(after_amount-before_amount) ... FROM `h8_finance_account_logs` where user_id=? and sub_account=?

🗄️ = 备份模式（mysqldump 全表导出），单独标注、不触发深度分析；昨日备份条数 429，未见明显倍增异常。
⚠️ = 触发深度分析（非备份且条数>;100 或累计>30min）。
注：第 5 名 h8_finance_account_logs 求和（16 条 / 497.8s，均值 31.1s）未达触发阈值（条数≤100 且累计≤1800s），但从均值看值得后续关注（user_id+sub_account 无联合索引时单次会全表扫，建议补 (user_id, sub_account) 联合索引并复查）。

四、触发深度分析的模式详情

4.1 ⚠️ gameList LEFT JOIN hitCount_month（270 次，均 1.05s，累计 282s）

代表 SQL（原始，节选）：

SELECT a.id,...,b.monthTotal FROM gameList a LEFT JOIN hitCount_month b ON a.id=b.hitId AND b.hitType='deal' AND b.themonth='202610' WHERE a.id not in(3440,...,18761) AND a.parent_id='0' AND a.type='game' AND FIND_IN_SET('denyShow',setInfo)<>2 ORDER BY b.monthTotal DESC;

实例：staging/tw8591（192.168.8.27:3306，MySQL 5.7.44，库 a8591）
表结构（describe_schema）：
gameList：PRIMARY(id)，KEY displayOrder / parent_id / type / idx_sale_count —— 无 (type, parent_id) 联合索引。
hitCount_month（MyISAM）：KEY themonth / month / hitType / commendId(hitId) —— 无 (hitId, themonth, hitType) 联合索引。
EXPLAIN 结论：
a 表 access_type=ALL 全表扫描，rows≈53,820，filtered=2%（possible_keys 有 parent_id/type 但优化器放弃，回表代价比全扫更高）；
b 表走 commendId（仅 hitId 前缀），每行再回表过滤 hitType/themonth（attached_condition），rows_examined_per_scan=6；
ORDER BY b.monthTotal → using_temporary_table + using_filesort，query_cost≈25,325。
慢因类型：缺索引（驱动表全表扫描 + 被驱动表回表过滤 + 临时表排序）。
建议：

hitCount_month 加联合索引 ALTER TABLE hitCount_month ADD INDEX idx_hitId_themonth_hitType (hitId, themonth, hitType); 消除被驱动表回表过滤（收益最直接）；
gameList 加联合索引 ADD INDEX idx_type_parent (type, parent_id)，使驱动表由 ALL 变 ref；
NOT IN (64 个字面量) 建议改为临时排除表或固化清单表；FIND_IN_SET('denyShow',setInfo)<>2 无法走索引（SET 列函数），如高频可加冗余 is_denyShow 标记列；
该查询结果日内高度重复（270 次/天、同月维度），建议加 60s~300s 应用层缓存，可立刻消除 ~282s/天。

4.2 ⚠️ SHOW ENGINE INNODB STATUS（171 次，均 1.62s，累计 277s）

用户 jmysql（监控/巡检账号），来自 LAN_addcn_37、LAN_addcn_40_3308。
无表结构/执行计划可查（管理命令）。慢因类型：其他（监控采样频率 × 实例繁忙）——本身轻量，但该命令需拿 innodb 状态锁，实例负载高时排队到 >1s。
建议：降低采样频率或错峰；若为 PMM/mysqldump-exporter 类采集器，可对非核心实例放宽间隔；累计 277s/天属可接受，无需索引类优化。

4.3 ⚠️ sonic 用户 commit;（170 次，均 4.71s，最大 304s，累计 801s）

来自 LAN_addcn_84（staging/8891 实例），user=sonic（Sonic 告警/部署平台的 DB）。rows_examined=0、Lock_time=0。
慢因类型：其他（大事务提交/IO 刷新延迟）——慢在 commit 阶段而非 SQL 扫描；binlog 刷新 + 大事务 undo/redo 使 fsync 拉长，304s 的极端值疑似一次超大批量事务。
建议：排查 sonic 平台对 t8891 的批量写入任务，改分批提交（每批 ≤1 万行）；确认 8891 实例 innodb_flush_log_at_trx_commit / sync_binlog 与盘 IO 水位；非查询问题，加索引无益。

五、逐条优化建议汇总

【索引】a8591.hitCount_month：新增 (hitId, themonth, hitType) 联合索引（对应 4.1，270 次/天）。
【索引】a8591.gameList：新增 (type, parent_id) 联合索引（对应 4.1）。
【缓存】gameList 月榜查询加 60~300s 应用缓存（对应 4.1）。
【SQL 改写】NOT IN (64 个字面量) 改排除表；FIND_IN_SET 改冗余标记列（对应 4.1）。
【事务】sonic 平台批量写改分批提交，控制单事务大小（对应 4.3）。
【观察】h8_finance_account_logs (user_id, sub_account) 求和均值 31s，建议补联合索引后复查（3.2 注）。
【备份】Top10 中 9 条为 mysqldump 全表导出，无优化动作必要；如需降低对 staging 影响，可将 anylink.access_audit（6177 万行）、t_subscription_push（3910 万行）改为限流导出或增量备份窗口。
【监控】SHOW ENGINE INNODB STATUS 采样 171 次/天，可适当降频（对应 4.2）。

六、数据来源与生成时间

慢日志：MCP es_slow_logs（top=10, env=staging）+ es_search（索引 mysql_slow-*，size=5000×search_after，实际 1 页 1,721 条）。
结构/计划：MCP connect（staging/tw8591）→ describe_schema → explain → disconnect，全程只读。
采集脚本：.agents/scripts/slow_report_20261020_gather.py、slow_report_20261020_deep.py；原始数据：outputs/slow_data_20261020.json、slow_fp_20261020.json、slow_deep_20261020.json。
生成时间：2026-10-21 10:10 (UTC+8)。