MySQL 慢查询日报 2026-09-20

统计范围：2026-09-20 00:00:00 ~ 23:59:59（Asia/Shanghai，ES @timestamp 已换算 UTC）

环境：staging | 数据来源：MCP addcn es_slow_logs / es_search（ES 索引 mysql_slow-*）| 全程只读

一、统计概览

单条耗时 Top10 全部为 backup（mysqldump）全表导出，非备份模式中累计耗时最高的是 tmp_cvd_t12 批处理（144 条 × 平均 295 s ≈ 11.8 h，详见第三节深度分析）。

二、Top10 慢查询明细（按单条耗时）

说明：

• Top10 的 lock_time 均在 1ms 级，排除锁等待；rows_examined ≈ rows_sent，属导出型顺序读，非缺索引。
• backup 全天共 819 条、累计 8.4 h，与备份窗口重叠时会挤压业务 SQL IO（见 #6，行数少却极慢）。
• 建议：test.facebook_photo（38 分钟）、land_shape_coordinates（19 分钟、1560 万行）这类非核心测试/原始数据表建议移出每日全量 dump 清单，或改为增量/低频导出，并将备份错峰到业务低峰。

三、高频慢查询模式（指纹归一化聚合，4,266 条 → 1,127 个模式）

3.1 按条数 Top5

3.2 按累计耗时 Top5

其他达阈值的模式：

• market_ep_build force index (idx_area) 地址匹配查询：各字面量指纹合计 250+ 条 / 累计 ≈420 s（单条 1.1~6.2 s）⚠️。
• commit;（sonic/airflow，112 条）与 SHOW ENGINE INNODB STATUS（zabbix 68 条）：提交/监控类，非 SQL 优化范畴。
• 备份模式全天 819 条，未见条数异常放大（环比无翻倍迹象），按规则不触发深度分析。

3.3 触发深度分析的模式（条数>100 或 累计>30min，已做 describe_schema + EXPLAIN）

① tmp_cvd_t12 — house_ep_source_relate 反连接（累计 11.8 h，最高优先级）

• 代表性 SQL（每 10 分钟执行一轮，144 次/天）：

  CREATE TEMPORARY TABLE tmp_cvd_t12 AS
  SELECT a.ep_source_id, a.post_id
  FROM t591_new.house_ep_source_relate a
  WHERE a.type = 2 AND NOT EXISTS (
      SELECT 1 FROM t591_new.house_ep_source_relate b
      WHERE b.type = 2 AND b.ep_source_id = a.ep_source_id
        AND (b.score > a.score OR (b.score = a.score AND b.id > a.id)))

• 表结构（t591_new.house_ep_source_relate，146 万行）：PK(id)，已有索引 idx_post_id_type(type,post_id)、idx_out_id、idx_ep_source_id、idx_type_ep_score_post(type,ep_source_id,score,post_id)。
• EXPLAIN：外层 ref 走 idx_type_ep_score_post 但只用到 type 前缀 → 单次扫描 283,240 行；每行触发 dependent subquery（ref 走 (type,ep_source_id)，本身高效，约 2 行/次）。即 28 万次关联子查询 × 144 轮 = 全天 4,000 万次子查询调用。索引不缺，是反连接逐行探测的算力问题。
• 根因：NOT EXISTS 反连接模式在外层 28 万行上逐行执行相关子查询；表数据随批次增长，扫描量线性恶化。
• 建议（按收益排序）：

1. 改写为窗口函数/聚合取最优：按 (type, ep_source_id) 分组取 score 最大（同分取 id 最大）的行，JOIN 回原表拿 post_id，把 O(N×子查询) 降为一次索引顺序扫描 + 分组（MySQL 8 窗口函数 ROW_NUMBER() OVER (PARTITION BY ep_source_id ORDER BY score DESC, id DESC)）。
2. 降频 + 复用：该任务每 10 分钟跑一次但结果依赖源表缓慢变化，可降为每小时，或增量只算变化的 ep_source_id。
3. 若保留现写法，确认 idx_type_ep_score_post 已覆盖子查询全部列（已覆盖，using_index=true），无需新增索引。

② GetGoldenSourceCommunityIDRepairStreets — golden_source 聚合（288 次 / 2,704 s）

• EXPLAIN：golden_source（约 430 万行）走 idx_comm_type_street range 扫描 428 万索引行、产出 193 万行；随后对 market_community_building（791 万行表）做 193 万次 PK eq_ref，再对 market_community 做 19 万次 eq_ref 过滤 deleted_at IS NULL。
• 根因：过滤条件只命中 10% 数据，但关联与聚合在 193 万中间结果上进行，每 5 分钟重复一轮。
• 建议：

1. 把 c.deleted_at IS NULL 前置：先筛出未删除社区的 cb id 集合（或 cb 表冗余 deleted 标记），将 eq_ref 次数从 193 万降到与最终结果同量级。
2. 结果缓存：GROUP BY street_id 的修复清单变化缓慢，建议 sqlc 调用方加 5~30 分钟缓存，或落缓存表每 5 分钟刷新一次，替代 288 次/天全量聚合。
3. 中期：将 golden_source 中 community_bid!=0 AND community_id=0 的待修复行物化为小表，聚合在小表上做。

③ market_ep_build force index (idx_area) 地址匹配（250+ 条 / ≈420 s）

• EXPLAIN：ref 走 idx_area 但仅用到 (regionid, sectionid) 两列 → 单次扫描 352,226 行，attached_condition 再过滤 addr_num1/addr_num2/lane/alley/room_num/floors（FIND_IN_SET），filtered 0.00%，最终仅产出 ~2 行。
• 根因：索引前缀列不足——idx_area 未包含 addr_num1/addr_num2，导致每个地址查询都把整个行政区的 35 万行读出来再丢弃。
• 建议（可执行）：新增/替换索引

  ALTER TABLE t591_new.market_ep_build
    ADD INDEX idx_area_v2 (regionid, sectionid, addr_num1, addr_num2, room_num);

去掉 force index (idx_area) 改为 force idx_area_v2（或让优化器自选）。lane/alley 的 OR NULL 条件与 floors 的 FIND_IN_SET 保持回表过滤即可——基数已被前 4 列砍掉 99.99%。预期单条从 1~2 s 降至 10 ms 级，全天省 ≈400 s。

• 注：room_num/floors 为 varchar 且条件含 is null or ''，不强制入索引；前 4 列已足够。

④ tmp_cvd_t1 — 带看记录 JSON 展开（144 次 / 1,535 s）

• EXPLAIN：数字生成器（0..999）与 tw591_ms_agent.agent_customer_viewing（仅 3,253 行，AUTO_INCREMENT=3253）做 BNL 展开连接，cost 7,087；宽行 SELECT（agent_customer 多列 + 每行 6 次 JSON_EXTRACT）。
• 根因：行×JSON 数组元素展开 + 逐元素多次 JSON 解析 + 宽列回表，纯算力型；表本身很小。
• 建议：低优先级。可用 MySQL 8 JSON_TABLE 替代数字生成器 CROSS JOIN；SELECT 列按下游需要裁剪；任务降频（该表日均新增极少，10 分钟一轮偏密）。

3.4 未触发深度分析的说明

• SHOW ENGINE INNODB STATUS（867 条，jmysql/zabbix）：监控采集自身入慢日志，非业务 SQL，建议调整该监控项阈值或忽略此模式。
• COMMIT/commit（287 条）：提交耗时属 binlog/redo fsync 与大事务，t8891 批处理（LAN_addcn_84）为主，与备份 IO 争用相关；建议排查 t8891 批任务事务大小（分批提交）。
• backup 模式 819 条：常规 mysqldump 全量导出，条数未见异常放大，按规则不深入。

四、逐条优化建议汇总

五、数据来源与生成时间

• 数据来源：MCP addcn（http://192.168.8.75:8200/mcp）es_slow_logs（top=10, env=staging）+ es_search（索引 mysql_slow-*，单页取全 4,266 条）；表结构与执行计划来自 describe_schema / explain（staging/tw591，只读连接，已断开）。
• 深度分析均先查 DDL 再 EXPLAIN，符合排查硬性规则；未执行任何写操作、未 kill、未改配置。
• 生成时间：2026-09-21 10:00 (Asia/Shanghai)，由 slow_report_20260920 系列脚本自动生成。