MySQL 慢查询日报 2026-11-05

统计概览

Top10 慢查询明细

前 8 条为同一 SQL 指纹（Django ORM 生成的列表页聚合查询），全天共出现 21 次、累计 23,475s；单条扫描行数仅 1~6.6 万，Lock_time 微小但 rows_sent=0——不是索引问题，详见深度分析 A。

高频慢查询模式（指纹归一化，共 684 个模式）

按条数 Top5

按累计耗时 Top5

🗄️ 备份模式说明：user=backup 的 mysqldump 全表导出全天约 30 张表、累计 14,084s，集中在 01:00~02:15（如 t_item_modi_histories 1900s/569万行、t_sele_item_infos 1394s/329万行、yahoo_car_details 582s）。条数与单表耗时与日常备份量级一致，无明显环比异常，按口径不触发深度分析。

深度分析（describe_schema + EXPLAIN 均已执行）

A. qa_hub_executionrun 三表 JOIN 聚合（21 条 / 累计 6.5 小时，Top1-8 全部是它）

• 实例：staging/8891（192.168.8.84），客户端 192.168.2.143，user=addcn8891_test。
• 表结构（已查 DDL）：
• qa_hub_executionrun：PK(id)，UNIQUE(user_id,request_id)，KEY(requirement_id)，KEY(state)；29 列中含 source_snapshot/result 等 longtext 大字段。
• qa_hub_executionevidence：PK(id)，UNIQUE(run_id,key)。
• qa_hub_executionevent：PK(id)，UNIQUE(run_id,event_id)，UNIQUE(run_id,sequence)。
• core_testrequirement：PK(id)，KEY(user_id)。
• EXPLAIN（完整原 SQL）：驱动表 qa_hub_executionrun 走 qa_execution_request_unique(user_id)（ref，扫描 ~2 行），core_testrequirement eq_ref PK，两个 LEFT JOIN 子表均走 run_id 前缀索引；GROUP BY 出现 using_temporary_table: true, using_filesort: true，总 cost 仅 301。
• 慢因判定：❌ 不是缺索引（扫描行数仅 1~6.6 万）；✔ 判定为大字段 + GROUP BY 临时表 + 实例资源/锁等待：查询携带 29 列 longtext（source_snapshot/result）进入 JOIN 与 GROUP BY，临时表落盘；rows_sent=0 说明结果未取回即超时/被杀；同时段该实例 GET_LOCK 平均等待 5.9s、COMMIT/SHOW ENGINE INNODB STATUS 集体变慢，指向实例级 IO 压力/长事务串行。
• 建议：

1. 列表页查询去掉 longtext 大列（source_snapshot、result 等），详情再按 id 回表取；或把大字段拆到独立附表。
2. COUNT(DISTINCT evidence.id)/COUNT(DISTINCT event.id) 改为对两张子表各一条 GROUP BY run_id 的预聚合子查询，避免 JOIN 产生笛卡尔放大与临时表。
3. LIMIT 60 的列表页先用覆盖索引取 id 列表再回表；requirement_id IN (子查询) 可改为先查 id 列表再 IN 常量列表。
4. 排查当天 10:11 起该实例的长事务/锁等待（information_schema.innodb_trx），确认是否有 30 分钟级事务阻塞该查询的元数据锁。

B. core_userprofile DISTINCT + JSON LIKE（1,500 条 / 累计 1.53 小时）

• EXPLAIN：access_type: ALL 全表扫描，但该表仅 ~22 行（AUTO_INCREMENT=26），cost 5.4，attached_condition 含 role_types LIKE '%"executive"%'（JSON 列 like）。
• 慢因判定：❌ 不是缺索引（表极小、全扫也只 22 行）；✔ 判定为实例资源压力下的高频轮询：单条逻辑开销微不足道，但 3.67s 的均值远超执行本身所需，与同实例 GET_LOCK 等待、COMMIT 变慢同现，说明慢在实例 IO/并发排队，而非该 SQL 本身。
• 建议：这是 aiworkflow 批量任务每轮循环都执行的「取执行人」查询——改为进程内缓存（角色列表变化频率极低，TTL 5~10 分钟即可），可每天消掉约 1.5 小时慢日志；根治需给该实例降压（见 A-4、F）。

C. qa_hub_designinput 三表 JOIN（1,079 条 / 累计 1.09 小时）

• EXPLAIN：qa_hub_designmission 走 requirement_id 索引（using_index），qa_hub_designnode 走 mission_id 索引，qa_hub_designinput 走 design_input_content_unique(mission_id) 前缀；ORDER BY id ASC 触发 using_temporary_table + using_filesort，cost 561。
• 慢因判定：✔ 大结果集传输 + 临时表/文件排序：SELECT 携带 content(longtext)、original(longblob) 大列；WHERE 为 OR 条件（designnode.flow_id=? OR designinput.mission_id=?）导致无法走单索引精确定位，逐 mission 展开；实测样本 rows_examined=30 但耗时 2.4s，瓶颈在 longtext/longblob 的 IO 读取。
• 建议：

1. 列表查询去掉 content/original 大列（按 id 需要时再取）。
2. OR 条件拆成 UNION 两支各自走索引（designnode(flow_id) 需有索引：当前 designnode 只有 mission_id 键，建议加 KEY idx_flow_id(flow_id)；designinput 走现有 unique(mission_id,kind,digest) 前缀）。
3. 轮询侧加退避：1,079 次/天大多来自批量任务循环，可与 B 一起加节流。

D. qa_hub_designartifact 按 mission 查（182 条 + 106 条变体 / 累计 1 小时）

• EXPLAIN：命中 qa_hub_designartifac_mission_id_62c9b43e_fk(mission_id)（ref，每次扫描 ~114 行），ORDER BY id 借助索引无 filesort；106 条变体（mission_id+kind+round LIMIT 1）同样只扫 114 行。
• 慢因判定：❌ 不是缺索引；✔ 大字段读取：SELECT 携带 payload 大列，114 行/次 × 288 次/天的 longtext 读取造成 IO 放大，叠加实例压力（该模式 max 108s 明显是排队所致）。
• 建议：与 A/C 同源——aiworkflow 批量任务把 payload、source_snapshot、content 等大列全部拖进每轮查询。统一做「列表瘦查询 + 详情按 id 回表」改造收益最大。

E. GET_LOCK('tapd-api:…', 74)（152 条 / 累计 15 分钟，平均 5.9s、最大 42.8s）

• EXPLAIN 无意义（advisory lock 函数）。✔ 判定为应用层串行锁等待：tapd-api 通道锁被长任务持有，等待直接计入 Query_time。属应用侧节流设计生效中的副作用，建议缩短持锁临界区或改队列。

F. 实例级信号：commit;/COMMIT;（422 条 / 累计 ~29 分钟）、SHOW ENGINE INNODB STATUS（213 条）

• 分布在 staging/8891、staging/TD、staging/tw8591 等多实例，commit 最大单次 296s。✔ 这是 IO 刷盘/长事务压力的典型信号，与 A/B/D 的「计划很便宜却跑数秒」互相印证。建议检查 staging/8891（192.168.8.84）主机 IO 与 innodb_flush_log_at_trx_commit 场景压力，并排查是否有未及时提交的长连接事务。

优化建议汇总（按优先级）

1. 【高】aiworkflow 批量任务查询瘦身（A/B/C/D 同根因）：去掉 SELECT 中的 source_snapshot、result、content、original、payload 等大字段，改为按 id 回表取详情；预计可消除全天约 5.5 小时慢日志（占非备份总量 43%）。
2. 【高】executionrun 聚合查询改写（A-2/A-3）：COUNT(DISTINCT …) 改子表预聚合，先取 id 列表再回表，消掉临时表；并排查当天 10 点后的长事务/MDL 等待。
3. 【中】core_userprofile 角色查询加缓存（B）：TTL 缓存即可，消 1,500 条/天。
4. 【中】designnode 表补索引（C）：ALTER TABLE aiworkflow.qa_hub_designnode ADD KEY idx_flow_id(flow_id);（低峰执行），配合 OR→UNION 改写。
5. 【中】staging/8891 实例健康检查（F）：慢 commit + 慢 SHOW ENGINE INNODB STATUS 集中出现，查主机 IO 利用率与长事务。
6. 【低】备份窗口维持现状：01:00~02:15 mysqldump 量级正常，无异常放大；如需降低对白天的影响可保持现状（当前与业务高峰无重叠）。

数据来源与生成时间

• 数据来源：MCP addcn（es_slow_logs / es_search / describe_schema / explain，全程只读）
• ES 慢日志索引 mysql_slow-*，@timestamp 过滤 [2026-11-05T00:00:00+08:00, 2026-11-06T00:00:00+08:00)，全量 5,622 条（search_after 时间游标翻页，无丢弃）
• MySQL 分析实例：staging/8891（192.168.8.84:3306）等，均通过 MCP 只读连接后断开
• 指纹归一化：字符串/数字/IN 列表替换为 ?，保留库表与 SQL 骨架；共 684 个模式
• 生成时间：2026-11-06 10:00 (Asia/Shanghai)