MySQL 慢查询日报 2026-11-02
统计范围:2026-11-02 00:00:00 ~ 23:59:59(Asia/Shanghai),环境 staging
数据来源:MCP addcn es_slow_logs / es_search(ES 索引 mysql_slow-*)
生成时间:2026-11-03 10:00 (Asia/Shanghai);全程只读,未执行任何写库 / kill / 配置变更
一、统计概览
| 指标 | 数值 |
|---|
| 慢日志总条数 | 1,982 |
| SQL 指纹数 | 627 |
| 全天累计慢查询耗时 | ≈ 319.0 分钟 |
| 其中 backup(mysqldump 全表导出) | 436 条,累计 ≈ 230.6 分钟(占 72.3%) |
| 业务慢查询(非 backup) | ≈ 1,546 条,累计 ≈ 88.4 分钟 |
| 单条最慢 | 1,984.3s(backup 导出 t8891.t_item_modi_histories,569 万行) |
| 触发深度分析的模式 | 6 个(见第四节) |
整体结论:昨日慢查询主因是 backup 全表导出(Top10 中 8 条)拖高实例 IO,进而引发 8891 / hk8591 实例上大量 commit/COMMIT/rollback/Ping 被动变慢;真正的业务 SELECT 慢模式集中在 h8_finance_account_logs、h8_orders(hk8591)与 t1_design_img 复杂 JOIN(100-slave/t591)、aiworkflow.qa_hub_*(8891)。
二、Top10 慢查询明细(按单条耗时)
| # | 耗时(s) | 用户 | 实例 | 库.表 | 行扫/行回 | 慢因类型 |
|---|
| 1 | 1984.32 | backup | staging/8891 | t8891.t_item_modi_histories | 5,693,964 / 5,693,964 | 大结果集传输(mysqldump 全表导出) |
| 2 | 1326.66 | backup | staging/8891 | t8891.t_sele_item_infos | 3,290,762 / 3,290,762 | 大结果集传输(备份导出) |
| 3 | 608.46 | backup | staging/8891 | t8891.yahoo_car_details | 16,681 / 16,681 | 大结果集传输(行均 36KB,超宽行) |
| 4 | 385.87 | backup | staging/8891 | t8891.t_subscription_push | 39,105,741 / 39,105,741 | 大结果集传输(3,910 万行) |
| 5 | 385.62 | backup | staging/8891 | t8891.t_sele_item_photos | 22,929,970 / 22,929,970 | 大结果集传输(2,293 万行) |
| 6 | 372.22 | backup | staging/8891 | t8891.save_car_details | 9,328 / 9,328 | 大结果集传输(行均 40KB 超宽行) |
| 7 | 296.58 | sonic | staging/8891 | —(commit) | 0 / 0 | 其他:事务提交/IO 阻塞(受备份期间 IO 饱和影响) |
| 8 | 290.23 | backup | staging/100-slave | t591.t1_daily_report | 30,525,823 / 30,525,823 | 大结果集传输(备份导出) |
| 9 | 290.16 | backup | staging/TD-slave | anylink.access_audit | 63,333,973 / 63,333,973 | 大结果集传输(6,333 万行审计表) |
| 10 | 286.83 | addcn8891_test | staging/8891 | —(COMMIT) | 0 / 0 | 其他:事务提交阻塞(binlog/IO 或锁链) |
Top10 无缺索引型全表扫描、无锁等待型(Lock_time 均 < 0.001s);#7/#10 为事务提交被动变慢。
三、高频慢查询模式(频次维度)
3.1 按条数 Top5
| # | 条数 | 平均(s) | 最大(s) | 累计(min) | 用户 | 涉及 server | 指纹(截断) |
|---|
| 1 | 208 | 4.29 | 296.58 | 14.9 | sonic | LAN_addcn_84 | commit; |
| 2 | 171 | 1.59 | 2.79 | 4.5 | jmysql | 27_3307/37/40_3308/46 | SHOW ENGINE INNODB STATUS;(监控探活) |
| 3 | 159 | 1.57 | 2.78 | 4.2 | 8591,jmysql | LAN_addcn_27/46 | # administrator command: Ping;(连接池心跳) |
| 4 | 106 | 5.56 | 286.83 | 9.8 | addcn8891_test 等 | 27/37/84 | COMMIT; |
| 5 | 91 | 1.62 | 3.20 | 2.5 | 8591 | LAN_addcn_27 | rollback; |
3.2 按累计耗时 Top5
| # | 条数 | 平均(s) | 最大(s) | 累计(min) | 用户 | 涉及 server | 指纹(截断) |
|---|
| 1 | 1 | 1984.32 | 1984.32 | 33.1 | backup | LAN_addcn_84 | SELECT /*!? SQL_NO_CACHE */ * FROM t8891.t_item_modi_histories |
| 2 | 1 | 1326.66 | 1326.66 | 22.1 | backup | LAN_addcn_84 | SELECT ... * FROM t8891.t_sele_item_infos |
| 3 | 208 | 4.29 | 296.58 | 14.9 | sonic | LAN_addcn_84 | commit; |
| 4 | 1 | 608.47 | 608.47 | 10.1 | backup | LAN_addcn_84 | SELECT ... * FROM t8891.yahoo_car_details |
| 5 | 106 | 5.56 | 286.83 | 9.8 | addcn8891_test 等 | 27/37/84 | COMMIT; |
说明:commit/COMMIT/rollback/Ping/SHOW ENGINE INNODB STATUS 属被动变慢信号(备份期 IO 饱和、长事务或 binlog 刷盘阻塞),本身无 SQL 可优化。backup 模式已单独标注,条数(436 条)属常规量级,未触发深度分析。
四、触发深度分析的模式(条数>100 或 累计>30min)
4.1 commit;(sonic @ LAN_addcn_84 / staging-8891)— 208 条,累计 14.9 min
- 现象:单条最大 296.58s,与 backup 大导出(#1 ~33 min、#2 ~22 min)时间窗重叠。
- 根因:8891 实例在 mysqldump 顺序读 500 万+ 行宽表期间 IO 带宽被占满,sonic 服务长事务的 commit(binlog fsync)被拖慢;属IO 争用型被动慢,非 SQL 本身问题。
- 建议:① 备份错峰/限速:
mysqldump ... --single-transaction 配合 pv -L 或改用 XtraBackup 增量;② sonic 侧缩短事务(小批量提交),避免长事务与备份窗口重叠;③ 确认 innodb_flush_log_at_trx_commit/sync_binlog 的 staging 取值无需为测试环境付出每次 fsync 代价(此为配置评估项,未做任何变更)。
4.2 SELECT sum(after_amount-before_amount) FROM h8_finance_account_logs WHERE user_id=? AND sub_account=?(hk8591)— 17 条,平均 24.2s,累计 6.9 min
- DDL(
hk8591.h8_finance_account_logs,主键 id):现有索引 asacca(user_id, ...)、idx_user_sub_account_id。
- EXPLAIN:access_type=ref,key=
asacca,仅用到 user_id 前缀(rows≈1/scan,ICP 下推 sub_account),filtered 10%。
- 根因:索引未覆盖
(user_id, sub_account) 联合前缀 + 聚合需回表逐行累加;白天快、慢集中在备份/高峰时段,叠加 IO 争用放大到 24s。
- 建议:
ALTER TABLE h8_finance_account_logs ADD INDEX idx_user_sub(user_id, sub_account)(或扩展 asacca 为 (user_id, sub_account, after_amount, before_amount) 覆盖索引,聚合可走 index-only);业务侧若余额高频查询,建议冗余余额字段避免全量 SUM。
4.3 select * from h8_finance_account_logs where user_id=? and sub_account=? order by id desc limit ?(hk8591)— 17 条,平均 14.5s,累计 4.1 min
- EXPLAIN:同上走
asacca(user_id) + Using filesort(ORDER BY id DESC)。
- 根因:缺
(user_id, sub_account, id) 顺序索引,回表后按 id 重新排序;SELECT * 宽行(含 memo/receipt_no)放大传输。
- 建议:与 4.2 合并解决——建
(user_id, sub_account, id) 索引后排序可由索引序直接满足,消除 filesort;同时避免 SELECT *,只取展示所需列。
4.4 select id,buyer_id,completed_at from h8_orders where buyer_id IN (...) and state=? order by created_at asc(hk8591)— 47 条,平均 2.4s,最大 17.9s
- DDL:
h8_orders 已有索引 bica(buyer_id 前缀)、sieca。
- EXPLAIN:access_type=range,key=
bica(buyer_id),state 为 attached_condition(filtered 1.67%),Using filesort。
- 根因:IN(buyer_id) 命中 bica 后仍需回表过滤 state 并按 created_at filesort;大买家订单多时扫描量放大。
- 建议:建联合索引
(buyer_id, state, created_at)(把 state 与排序列纳入索引),可消 filesort 并把 filtered 从 1.67% 提到接近 100%;created_at 如与 id 同序也可 order by id 改写走主键序。
4.5 SELECT ... FROM qa_hub_designartifact WHERE mission_id=? AND kind=? ORDER BY id DESC LIMIT 1(aiworkflow @ 8891)— 23 条,平均 5.2s
- DDL:
qa_hub_designartifact 现有 PK(id)、UNIQUE(task_id,kind)、KEY(mission_id)。
- EXPLAIN:key=
qa_hub_designartifac_mission_id_...(mission_id),rows≈23,filtered 10%,kind 为 attached_condition。
- 根因:表本身仅 138 行,EXPLAIN 成本 17——当前执行计划不慢;日志中 5.2s 主要发生在备份窗口的 IO 饱和期,叠加
FOR UPDATE 行锁等待(qa_hub 系列另有 11 条 FOR UPDATE 快照查询、31 条 GET_LOCK)。属"小表 + 资源争用/锁"型。
- 建议:① 建覆盖索引
(mission_id, kind, id) 让 LIMIT 1 直接取索引尾部,免除回表;② 排查 aiworkflow 应用事务持锁时长(GET_LOCK 31 次入慢日志,检查是否有未及时 RELEASE_LOCK);③ 避开备份高峰跑 QA 工作流任务。
4.6 select i.*, COALESCE(...) from t1_design_img i left join t1_design_work w ... left join (t1_visits 按天聚合) v ... left join (t1_user_collect 聚合) uc ... left join (t1_vip_benefit_calendar 聚合) vip ...(t591 @ 100-slave)— 68 条,平均 1.2s,累计 1.3 min
- EXPLAIN(代表性简化):外层
t1_design_img 走 views 索引 rows≈130,739(data_read≈428M),派生表 v 对 t1_visits 按 source_type='img' AND date>=? 全量 GROUP BY(query_cost≈487,129,为全查询主要成本)。
- DDL:
t1_visits 有 t1_visits_source_type_source_id_date_index(source_type,source_id,date) 与 idx_source_type_date(source_type,date);t1_user_collect 有 created_at、user_id、uuid 索引。
- 根因:三个派生表每次查询都对 30 天明细(
t1_visits/t1_user_collect)整段 GROUP BY 物化(每次全量扫约 11.5 万行 visits + collect 明细),再与 13 万行 img 做 JOIN;每页请求重复计算同样的聚合。
- 建议:① 把 30 天 views/collections 聚合改为离线日汇总表(按 source_id 一行一汇总,定时任务维护),查询直接 JOIN 汇总表,可去掉全部三个派生表;② 或至少加缓存(同一列表页 68 次/天、结果高度重合);③
t1_user_collect 建议补 (type, work_id, created_at) 索引,现仅有单列 created_at。
未达阈值但值得关注:SELECT GET_LOCK(?,?) 31 条(平均 1.4s,aiworkflow 串行锁等待);h8_orders IN+state 模式若买家 ID 列表继续增大,扫描量会进一步放大。
五、逐条优化建议(按优先级)
- 备份错峰限速(收益最大):backup 占全天慢查询耗时的 72%。mysqldump 大表(t_item_modi_histories 569 万行、t_subscription_push 3,910 万行、access_audit 6,333 万行)顺序读挤占 IO,直接造成 8891/27/37 等实例 commit/COMMIT/rollback/Ping 批量变慢(合计 564 条、约 31.4 分钟)。建议改用 XtraBackup 或对 mysqldump 限速并避开业务高峰。
- hk8591 加索引(一条 DDL 解决 4.2/4.3/4.4 三个模式,共 81 条):
h8_finance_account_logs:新增 (user_id, sub_account, id)(消除 filesort + 覆盖聚合);h8_orders:新增 (buyer_id, state, created_at)。
- t591 设计图列表:派生表聚合改日汇总表/缓存(4.6),消除每次全量 GROUP BY。
- aiworkflow:
(mission_id, kind, id) 覆盖索引;审计 GET_LOCK/FOR UPDATE 事务时长;QA 重任务避开备份窗口。
- sonic 长事务:小批量提交,避免与备份窗口重叠。
六、数据来源与生成方式
- 慢日志:MCP
es_slow_logs(top=10, env=staging)+ es_search(索引 mysql_slow-*,size=5000 单页取全 1,982 条,@timestamp ∈ [2026-11-02T00:00:00+08:00, 2026-11-03T00:00:00+08:00))
- 指纹归一化:字符串/数字/IN 列表 →
?,按指纹聚合条数/均值/最大值/累计耗时/server
- 深度分析:MCP
connect → search_schema → describe_schema → explain → disconnect(实例 staging/hk8591、staging/8891、staging/100-slave,全程只读)
- 生成时间:2026-11-03 10:00 Asia/Shanghai