📋 目录一、Top10 慢查询明细二、高频慢查询模式(指纹归一化后聚合,共 645三、触发深度分析的模式详情四、附加观察(未达强制阈值但值得跟进)五、逐条优化建议汇总六、数据来源与说明

MySQL 慢查询日报 2026-10-21

一、Top10 慢查询明细

#耗时(s)用户来源 IP / 实例SQL(截断)慢因判定
11611.32backup192.168.8.84 → staging/8891SELECT /*!40001 SQL_NO_CACHE */ * FROM t8891.t_item_modi_histories备份全表导出:EXPLAIN type=ALL,扫描 502 万行,data_read 14G
21143.19backup192.168.8.84 → staging/8891SELECT ... * FROM t8891.t_sele_item_infos备份全表导出:type=ALL,300 万行,20G
3525.71backup192.168.8.84 → staging/8891SELECT ... * FROM t8891.yahoo_car_details备份全表导出:仅 6,270 行但行超宽(raw_html/longtext),18M+
4398.91backup192.168.8.84 → staging/8891SELECT ... * FROM t8891.t_subscription_push备份全表导出:3,953 万行,33G(表仅 4 列但行数巨大)
5356.18backup192.168.8.46 → staging/100-slaveSELECT ... * FROM t591.t1_daily_report备份全表导出:2,885 万行,7G
6318.39backup192.168.8.84 → staging/8891SELECT ... * FROM t8891.t_sele_item_photos备份全表导出:2,180 万行,80G(图片路径宽表)
7288.18backup192.168.8.27 → staging/tw8591SELECT ... * FROM hk8591.h8_orders备份全表导出(表在 staging/hk8591@3307,tw8591 无此表)
8283.70sonic172.18.0.6(容器) → staging/8891commit;非备份:大事务提交,fsync/binlog 刷盘慢(见模式分析 P2)
9283.51backup192.168.8.51 → staging/TD-slaveSELECT ... * FROM anylink.access_audit备份全表导出:5,803 万行审计日志,72G
10270.75backup192.168.8.27 → staging/tw8591SELECT ... * FROM hk8591.h8_telescope_entries备份全表导出(表在 staging/hk8591@3307)

Top10 结论:10 条中 9 条为 mysqldump 备份导出(user=backup,SQL_NO_CACHE 全表扫描),属于备份窗口正常行为,不建议加索引"优化";唯一业务条目是 #8 commit;(sonic,容器 172.18.0.6),指向大事务/刷盘问题。备份 dump 单条 270~1611s,建议错峰(当前集中在备份窗口)并评估 --single-transaction + 限流(见建议 6)。

二、高频慢查询模式(指纹归一化后聚合,共 645 个模式)

按条数 Top5

#条数平均(s)最大(s)累计(s)用户服务器模式(SQL 骨架,截断)标注
P12421.051.78254.1a8591LAN_addcn_27select a.id,... 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⚠️ 触发深度分析
P22024.22283.70852.3bee/chenruijia/eagle/sonic/t8891LAN_addcn_27/37/84commit;⚠️ 触发深度分析(非 SQL 可优化)
P31791.552.73276.6jmysqlLAN_addcn_40_3308/46show engine innodb status;监控采集,非业务
P41021.372.31140.18591/jmysqlLAN_addcn_27/46# administrator command: ping;连接池心跳,症状非根因
P5761.21—92.3a591LAN_addcn_46select i.*, coalesce(...) from house_repost 相关联查未达阈值,附简评

按累计耗时 Top5

#条数平均(s)最大(s)累计用户服务器模式(截断)标注
T111611.321611.3226.9minbackupLAN_addcn_84select /*!40001 sql_no_cache */ * from t8891.t_item_modi_histories🔶 backup 模式
T211143.191143.1919.1minbackupLAN_addcn_84select ... * from t8891.t_sele_item_infos🔶 backup 模式
T32024.22283.70852.3s多用户多服务器commit;⚠️ 深度分析
T41736.50—620.5s8591LAN_addcn_27_3307select sum(after_amount-before_amount) from h8_finance_account_logs where user_id=? and sub_account=?未达 30min 阈值,但单条 36.5s 异常,附分析
T51525.71525.718.8minbackupLAN_addcn_84select ... * from t8891.yahoo_car_details🔶 backup 模式
backup 模式(mysqldump 全表导出)单独标注,不触发深度分析;本日 backup 相关模式条数与历史常规持平,无明显环比翻倍迹象。

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

P1:gameList LEFT JOIN hitCount_month(242 条/天,每 6 分钟一次,累计 254s)

代表性 SQL:

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,...共约 70 个 id) AND a.parent_id='0' AND a.type='game'
  AND FIND_IN_SET('denyShow',setInfo) <> 2
ORDER BY b.monthTotal DESC;

describe_schema(a8591.gameList):PK(id),KEY displayOrder、parent_id、type、idx_sale_count。

describe_schema(a8591.hitCount_month):PK(id),KEY year、month、themonth、hitType、commendId(含 hitId 前缀)。

EXPLAIN(staging/tw8591,全库表限定):

根因:① 驱动表缺 (type, parent_id) 复合索引,导致每 6 分钟全表扫 + 临时表排序;② FIND_IN_SET('denyShow', setInfo) 与 70+ 元素 NOT IN 常量列表迫使全行过滤;③ 该查询结果(游戏列表+月度热度)变化低频,却以 242 次/天重复计算。

可执行建议:

  1. 加复合索引:ALTER TABLE a8591.gameList ADD KEY idx_type_parent (type, parent_id); 可将驱动表扫描从 5.3 万行收敛到千级。
  2. 为 hitCount_month 加覆盖索引 (hitId, hitType, themonth, monthTotal),消除 b 侧回表过滤。
  3. 应用层缓存 5~10 分钟(该接口本就 ~6 分钟一刷,缓存命中率≈100%);长期可将 denyShow 从 SET 列拆为独立 tinyint 标志列以走索引。

P2:commit;(202 条,平均 4.22s,最大 283.70s,累计 852s)

P3:SHOW ENGINE INNODB STATUS;(179 条,平均 1.55s,jmysql)

P4:# administrator command: Ping;(102 条,平均 1.37s)

四、附加观察(未达强制阈值但值得跟进)

  1. h8_finance_account_logs 余额汇总(T4,17 条 × 36.5s):EXPLAIN 走 idx_user_sub_account_id 但只用到 user_id 前缀,扫描 21,126 行后用 ICP 过滤 sub_account——原因是 sub_account 列为 char(2),SQL 传的是数字 11,隐式类型转换使第二列无法参与索引定位。改写成 sub_account = '11' 即可用满 (user_id, sub_account),扫描量预计降一个数量级以上。
  2. h8_telescope_entries 定期清理 delete(32 条 × 10.7s):EXPLAIN(等价 SELECT)type=ALL 全扫 123,865 行才删 1000 行——created_at 无索引。建议 ALTER TABLE hk8591.h8_telescope_entries ADD KEY idx_created_at (created_at);(Laravel Telescope 官方亦建议清理列建索引)。
  3. h8_orders buyer_id IN(...) 批查(46 条 × 2.34s):若 buyer_id+completed_at 无复合索引,建议 ADD KEY idx_buyer_completed (buyer_id, completed_at)。
  4. house_repost(P5,76 条):ispay='0' AND status='0' AND type!='5' ORDER BY rectime ASC,建议复合索引 (ispay, status, rectime)。

五、逐条优化建议汇总

优先级对象动作
高a8591.gameListADD KEY idx_type_parent (type, parent_id);应用加 5~10min 缓存
高sonic@172.18.0.6 批量写拆小事务批次(1~5 万行/批),消除 283s 级 commit
高h8_finance_account_logs 查询sub_account = 11 → sub_account = '11'(消除隐式转换)
中hk8591.h8_telescope_entriesADD KEY idx_created_at (created_at)
中hk8591.h8_ordersADD KEY idx_buyer_completed (buyer_id, completed_at)
中a591.house_repostADD KEY idx_ispay_status_rectime (ispay, status, rectime)
低staging 实例参数评估 innodb_flush_log_at_trx_commit=2 / sync_binlog=0(仅测试环境)
低备份任务dump 错峰 + --single-transaction --limit-query-time 类限流;backup 模式本日无异常增长
低jmysql 监控SHOW ENGINE INNODB STATUS 降频至 30~60s

六、数据来源与说明