MySQL 慢查询日报 2026-10-19（staging）
统计口径：2026-10-19 00:00:00 ~ 23:59:59（Asia/Shanghai，ES @timestamp UTC 换算 [2026-10-18T16:00:00Z, 2026-10-19T16:00:00Z)）。
数据来源：MCP es_slow_logs / es_search（staging ES，索引 mysql_slow-*）；表结构与执行计划来自 MCP describe_schema / explain（全程只读）。
一、统计概览
| 指标 | 数值 |
|---|
| 慢查询总条数 | 2051（es_slow_logs total=2051，es_search 全量拉取 2051 条，1 页取齐） |
| 累计慢查询耗时 | 约 5.86h |
| 单条最大耗时 | 26.5m（backup 全表导出 t_item_modi_histories） |
| backup(mysqldump) 条数 / 累计耗时 | 414 条 / 约 3.65h（占累计 62%） |
| 去重 SQL 指纹数 | 625 |
| 涉及服务器 | LAN_addcn_27, LAN_addcn_27_3307, LAN_addcn_37, LAN_addcn_40_3308, LAN_addcn_44, LAN_addcn_46, LAN_addcn_51, LAN_addcn_81, LAN_addcn_84 |
结论速览：Top10 基本被 backup 全表导出占据（staging 例行备份，单列呈现、不做深度分析）；业务侧最值得关注的是 tw8591:t8_game 游戏库宽行大结果集（3 个模式累计 >50 分钟）、a8591.gameList JOIN 缺复合索引（278 次）、hk8591 财务余额全历史扫描（avg 38s/条）、h8_telescope_entries 清理 DELETE 缺 created_at 索引（单条最长 257s）。
二、Top10 慢查询明细（按单条耗时）
| # | 耗时 | 库.表 | 用户 | 实例 | rows_sent | 慢因类型 |
|---|
| 1 | 26.5m | t8891.t_item_modi_histories | backup | staging/8891 | 5693964 | 大结果集传输（mysqldump 全表导出，SQL_NO_CACHE） |
| 2 | 20.4m | t8891.t_sele_item_infos | backup | staging/8891 | 3290762 | 大结果集传输（mysqldump 全表导出，SQL_NO_CACHE） |
| 3 | 8.1m | t8891.yahoo_car_details | backup | staging/8891 | 16681 | 大结果集传输（mysqldump 全表导出，SQL_NO_CACHE） |
| 4 | 6.6m | t8891.t_subscription_push | backup | staging/8891 | 39105741 | 大结果集传输（mysqldump 全表导出，SQL_NO_CACHE） |
| 5 | 6.0m | t591.t1_daily_report | backup | staging/100-slave | 30250821 | 大结果集传输（mysqldump 全表导出，SQL_NO_CACHE） |
| 6 | 5.2m | t8891.t_sele_item_photos | backup | staging/8891 | 22929970 | 大结果集传输（mysqldump 全表导出，SQL_NO_CACHE） |
| 7 | 4.8m | anylink.access_audit | backup | staging/TD-slave | 61783621 | 大结果集传输（mysqldump 全表导出，SQL_NO_CACHE） |
| 8 | 4.8m | — | sonic | staging/8891 | 0 | 其他：commit 落盘等待（大事务/redo flush） |
| 9 | 4.6m | hk8591.h8_orders | backup | staging/tw8591 | 2664360 | 大结果集传输（mysqldump 全表导出，SQL_NO_CACHE） |
| 10 | 4.4m | hk8591.h8_telescope_entries | backup | staging/tw8591 | 211158 | 大结果集传输（mysqldump 全表导出，SQL_NO_CACHE） |
Top10 深度核查（describe_schema + explain，只读）：
- #1：
t_item_modi_histories 约 502 万行、数据量 ~14G（explain data_read_per_join=14G），主键+4 个二级索引，ALL 全扫属导出必然行为。
- #2：
t_sele_item_infos 约 301 万行、~20G 宽表（39 列），同上。
- #3：
yahoo_car_details 仅 6270 行但含 raw_html/raw_spec_html 等大文本，~18M/次全表读，单行极宽导致 486s。
- #4：
t_subscription_push 3953 万行、33G，仅 4 列（id/token/push_date/record_time），纯容量问题。
- #5：
t1_daily_report（100-slave）2885 万行、7G。
- #6：
t_sele_item_photos 2180 万行、~80G，单表最大。
- #7：
anylink.access_audit（TD-slave）5793 万行、72G，只有主键无任何二级索引，表持续膨胀。
- #8：commit 语句无表可 explain；sonic@8891，285.9s 的 commit 落盘等待，指向大事务/redo 刷盘，见高频模式分析。
- #9：
h8_orders（hk8591，tw8591 实例上无此表，已改连 staging/hk8591 核查）249 万行、1G，索引齐全。
- #10：
h8_telescope_entries（hk8591）12.3 万行、167M；AUTO_INCREMENT 已达 12.25 亿，写入/清理频繁，见 DELETE 模式分析。
backup 模式说明：staging 例行 mysqldump 全表导出（user=backup，/*!40001 SQL_NO_CACHE */），条数与常规持平、无环比异常，按口径单独标注、不触发索引类深度分析。建议将备份切换到从库或使用 XtraBackup/快照避免冲击主库 buffer pool。
三、高频慢查询模式（指纹归一化：字符串/数字/IN 列表 → ?）
3.1 按条数 Top5（非 backup）
| # | 条数 | 平均耗时 | 最大耗时 | 累计耗时 | 用户@服务器 | 指纹 |
|---|
| 1 | 278 | 1.05s | 2.7s | 4.9m | a8591@LAN_addcn_27 | SELECT a.id, a.name, a.color, a.setInfo +? AS setInfo, a.setGameType,a.setWareType, b.monthTotal FROM gameList a LEFT JOIN hitCount_month b ON a.id = |
| 2 | 129 | 5.04s | 4.8m | 10.8m | eagle,log,sonic@LAN_addcn_37,LAN_addcn_84 | commit |
| 3 | 126 | 4.48s | 21.1s | 9.4m | a8591@LAN_addcn_27 | SELECT * FROM 't8_game'.'t8_platform_game_embeddings' WHERE 't8_platform_game_embeddings'.'platform_game_id' IN (?) |
| 4 | 103 | 1.55s | 2.8s | 2.7m | jmysql@LAN_addcn_27,LAN_addcn_40_3308,LAN_addcn_46 | SHOW ENGINE INNODB STATUS |
| 5 | 101 | 2.39s | 18.6s | 4.0m | a8591@LAN_addcn_27 | SELECT * FROM 't8_game'.'t8_platform_game_desc' WHERE 't8_platform_game_desc'.'platform_game_id' IN (?) |
3.2 按累计耗时 Top5（非 backup）
| # | 条数 | 平均耗时 | 最大耗时 | 累计耗时 | 用户@服务器 | 指纹 |
|---|
| 1 | 92 | 25.32s | 2.1m | 38.8m | a8591@LAN_addcn_27 | SELECT * FROM 't8_game'.'t8_platform_game_nintendo_regions' WHERE platform_game_id IN (?) AND is_available = ? ORDER BY id ASC |
| 2 | 19 | 38.14s | 2.4m | 12.1m | 8591@LAN_addcn_27_3307 | SELECT sum(after_amount - before_amount) as balance FROM 'h8_finance_account_logs' where user_id = ? and sub_account = ? |
| 3 | 129 | 5.04s | 4.8m | 10.8m | eagle,log,sonic@LAN_addcn_37,LAN_addcn_84 | commit |
| 4 | 126 | 4.48s | 21.1s | 9.4m | a8591@LAN_addcn_27 | SELECT * FROM 't8_game'.'t8_platform_game_embeddings' WHERE 't8_platform_game_embeddings'.'platform_game_id' IN (?) |
| 5 | 18 | 17.56s | 4.3m | 5.3m | 8591@LAN_addcn_27_3307 | delete from 'h8_telescope_entries' where 'created_at' < ? limit ? |
判定规则命中（非 backup 且 条数>100 或 累计>30min）的模式：gameList JOIN（278 次）、commit（129 次）、t8_platform_game_embeddings（126 次）、SHOW ENGINE INNODB STATUS（103 次）、t8_platform_game_desc（101 次）、t8_platform_game_nintendo_regions（累计 38.8min）。backup 模式（mysqldump 全表导出）条数正常、未触发。
3.3 触发深度分析的模式详情
P1. a8591.gameList LEFT JOIN hitCount_month（278 次，累计 4.9min）
SELECT a.id, a.name, a.color, a.setInfo +0 AS setInfo, a.setGameType,a.setWareType, 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,23659,800,14203,1666,16641,13703,1406,23589,3774,21550,13343,14368,5759,2217,5065,6475,18761,9049,15358,7714,4701,3278,1242,160,15965,3405,5932,1877,16769,26649,23501,32875,33999,32473,32892,17497,26956,19328,26068,22042,33792,23640,27935,14331,31865,31750,17762,31747,33613,14457,28980,14378,23736,27651,25499,18813,30111,28752,20688,18804,3440,24362,24298,21550,18761)
- 执行计划（staging/tw8591 实测）：驱动表
a（gameList，5.4 万行）ALL 全扫；被驱动表 b（hitCount_month）走 commendId(hitId) 单列索引 ref，hitType='deal' AND themonth='202610' 作为附加条件在回表后过滤；整体 using_temporary_table + using_filesort，排序成本占大头。
- 表结构关键点：
hitCount_month 是 MyISAM 表（表锁风险），对 (hitId, hitType, themonth) 没有复合索引，只有 hitId/hitType/themonth 各自的单列索引。
- 慢因：缺复合索引 → 每个游戏回表 6 行再过滤；JOIN+ORDER BY 产生临时表文件排序；278 次/天重复执行无缓存。
- 建议：①
hitCount_month 加复合索引 ALTER TABLE hitCount_month ADD INDEX idx_hit_themonth (hitId, hitType, themonth, monthTotal)（末列 monthTotal 可让 monthTotal 直接从索引取，免回表）；② 该表建议迁 InnoDB（MyISAM 表锁 + 不支持崩溃恢复）；③ 278 次/天、结果按月变化，建议应用层加 5~10 分钟缓存。
P2. commit（129 次，累计 10.9min，max 285.9s；用户 eagle/sonic/log @ 8891 与 TD）
- commit 语句无 SQL 可优化，慢在 事务提交时 redo/binlog 刷盘等待，通常由大事务或 IO 抖动引起；max 285.9s 与 Top10 #8（sonic 的 285.9s commit）同源。
- 建议：排查 2026-10-19 当日 8891/TD 的批量写入任务（sonic/log 为采集类账号），确认是否有单事务批量插入/大量 binlog；如为间歇性则关注磁盘 IO 利用率（PMM）。此为「其他」类慢因，不做索引变更。
P3. t8_game.t8_platform_game_embeddings WHERE platform_game_id IN (...)（126 次，累计 9.4min，max 21.1s）
- 表结构：
UNIQUE KEY idx_platform_game_id (platform_game_id) 已存在，explain（IN 8 个值）为 range 访问、rows=8，索引无缺失。
- 慢因：大结果集传输——
SELECT * 携带 vector/name_vector 向量列（宽行），实际 IN 列表常为数百~上千个 id（AUTO_INCREMENT 已 1385 万，表现存约 4.7 万行说明大量历史数据反复写入），单次返回数据量大。
- 建议：应用侧只 SELECT 需要的列（避免无条件
*）；IN 列表分批（每批 ≤200）；向量检索考虑移入专用向量库，MySQL 仅存元数据。
P4. SHOW ENGINE INNODB STATUS（103 次，jmysql 监控账号）
- 监控采集语句，等待mutex/内部锁导致耗时，非业务 SQL，不做优化；条数 103 与常规监控频率一致。
P5. t8_game.t8_platform_game_desc WHERE platform_game_id IN (...)（101 次，累计 4.0min）
- 表结构：
KEY idx_paid (platform_game_id) 已存在，explain range 访问正常。列 description/content 为大文本（explain 估算全表 data_read 7M/184596 行 → 单行 ~40KB）。
- 慢因：与 P3 同类——宽行大结果集传输。建议同 P3：列裁剪 + 分批。
P6. t8_game.t8_platform_game_nintendo_regions WHERE platform_game_id IN (...) AND is_available=? ORDER BY id（92 次，累计 38.8min，max 126.4s，avg 25.3s）
SELECT * FROM `t8_game`.`t8_platform_game_nintendo_regions` WHERE platform_game_id IN (314502,314503,314504,314505,314506,314507,314508,314509,314510,314511,314512,314513,314514,314515,314516,314517,314518,314519,314520,314521,314522,314523,314524,314525,314526,314527,314528,314529,314530,314531,314532,314533,314534,314535,314536,314537,314538,314539,314540,314541,314542,314543,314544,314545,314546,314547,314548,314549,314550,314551,314552,314553,314554,314555,314556,314557,314558,314559,314560,314561,314562,314563,314564,314565,314566,314567,314568,314569,314570,314571,314572,314573,314574,31
- 表结构：索引非常齐全（
uniq_pg_region(platform_game_id, region_code) 等 11 个），explain 小 IN 列表为 range + filesort（ORDER BY id 无法用索引消除，代价可忽略）。
- 慢因：大结果集传输为主——单表估算 data_read_per_join 640M（6.6 万行），
list_payload/detail_payload JSON 大列 + 巨大 IN 列表；max 126s 说明偶发叠加了 buffer pool 冷读/IO 争用（与当日 backup 导出同机 8891 不同实例，tw8591 上另有批量任务）。
- 建议：① 列表页不取
detail_payload（列裁剪/拆表，payload 移到按需查询的附表或对象存储）；② IN 列表分批；③ is_available=0 的下架区域占多数时可考虑逻辑归档历史行。
3.4 累计耗时靠前的其他值得注意模式（未达阈值，列出备查）
- hk8591 财务余额 SUM（19 次，累计 12.1min，avg 38.1s，max 217.9s 精确卡在备份锁阈值附近）：
SELECT sum(after_amount-before_amount) FROM h8_finance_account_logs WHERE user_id=? AND sub_account=?。表 1359 万行/16G；实测 explain 命中 idx_user_sub_account_id(user_id, sub_account, id DESC) 但 used_key_parts 仅 user_id（ref=const，单用户回表扫描 ~2.1 万行后再过滤 sub_account，ICP），再对全部历史行做 SUM。建议：加覆盖索引 (user_id, sub_account, before_amount, after_amount)（免回表免过滤），更根本的是为账户维护余额快照/汇总表，避免每次全历史重算。
- h8_telescope_entries 清理 DELETE（18 次，累计 5.3min，max 256.9s）：
DELETE ... WHERE created_at < ? LIMIT 1000。表 DDL 没有 created_at 索引，每次删除都要全表扫 12 万行找出可删的 1000 行，且与 backup 全表导出（#10）同表叠加。建议：ALTER TABLE h8_telescope_entries ADD INDEX idx_created_at (created_at)；清理任务避开备份窗口。
- 8591 h8_orders 买家订单查询（51 次，累计 2.1min）：
bica(buyer_id, created_at) 索引已在，宽行 ORDER BY created_at，量级可接受，暂不处理。
四、逐条优化建议（按优先级）
| 优先级 | 对象 | 动作 | 预期收益 |
|---|
| P0 | hk8591.h8_telescope_entries | ADD INDEX idx_created_at (created_at)；清理任务避开 22:00 后备份窗口 | DELETE 从全表扫变索引定位，max 257s → 秒级 |
| P0 | hk8591.h8_finance_account_logs | 覆盖索引 (user_id, sub_account, before_amount, after_amount)；中期做余额快照表 | avg 38s → 亚秒；消除高频全历史 SUM |
| P1 | a8591.hitCount_month | 复合索引 (hitId, hitType, themonth, monthTotal)；迁 InnoDB | 278 次/天的 JOIN 消除回表过滤与 filesort 大头 |
| P1 | tw8591 t8_game 三表（embeddings/desc/nintendo_regions） | SELECT 列裁剪（去掉 vector/payload 大列按需取）；IN 分批 ≤200；payload 拆表或外移 | 累计 >50min 的传输型慢查询大幅下降 |
| P2 | 8891/TD 大事务 | 排查 sonic/log 当日批量写入；确认 innodb_flush_log_at_trx_commit 与 IO | commit 类 10.9min 消除 |
| P2 | 备份策略 | backup 导出切到从库或 XtraBackup；anylink.access_audit（5793 万行、仅主键）做归档/分区 | 主库 buffer pool 不被 80G/72G 全表读冲刷 |
| P3 | t591.t1_daily_report、t8891.t_subscription_push | 历史数据归档（3558 万/3953 万行） | 备份窗口缩短 |
注：所有 DDL 建议先在 staging 从库验证、用 pt-online-schema-change 或低峰执行；本报告全程只读，未做任何变更。
五、数据来源与生成时间
- 慢日志：MCP
es_slow_logs（top=10, env=staging）与 es_search（index=mysql_slow-*, size=5000, 1 页取齐 2051 条）
- 时间范围：2026-10-19T00:00:00+08:00 ~ 2026-10-20T00:00:00+08:00（@timestamp UTC：2026-10-18T16:00:00Z ~ 2026-10-19T16:00:00Z）
- 结构/执行计划：MCP
describe_schema / explain（实例：staging/tw8591、staging/hk8591、staging/8891、staging/100-slave、staging/TD-slave），只读
- 生成时间：2026-10-20 10:0x（Asia/Shanghai），自动化脚本 .agents/scripts/slow_report_20261019_*.py