MySQL 慢查询日报 2026-09-17

统计范围：2026-09-17 00:00:00 ~ 23:59:59（Asia/Shanghai），staging 环境 ES 慢日志（索引 mysql_slow-*，按 @timestamp UTC 换算）。

数据来源：MCP addcn（es_slow_logs / es_search / connect→describe_schema→explain→disconnect，全程只读）。

生成时间：2026-09-18 10:0x CST；分析脚本：.agents/scripts/slow_report_20260917*.py。

一、统计概览

昨日慢日志文档总数：4,946 条（单页拉全，未触发翻页）
Top10 全部为 backup 用户（mysqldump 全表导出），单条最慢 2,373s（约 39.6 分钟）
Top10 累计耗时约 11,098s ≈ 3.08 小时，全部集中在 3 台实例：
staging/tw591（LAN_addcn_117）：5 条
staging/tw8591（LAN_addcn_27）：2 条
staging/8891（LAN_addcn_84）：2 条
高频模式（去指纹聚合）触发深度分析的共 16 个，最严重的是 tmp_cvd_t12 临时表构建（144 条 × 平均 294.5s ≈ 11.7 小时累计）
明显异常信号：tw8591 上出现 158 条精确 300.00s 的锁等待（innodb_lock_wait_timeout 到期），与备份窗口时间重合

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

#	耗时(s)	库.表	实例	行扫描/返回	慢因类型
1	2373.77	`test`.`facebook_photo`	staging/tw591	101,727 / 101,727	大结果集传输（含 base64 longtext，单次 join 数据量 119M）
2	1377.87	`t8891`.`t_item_modi_histories`	staging/8891	5,693,964 / 5,693,964	大结果集传输（569 万行、data_read 14G）
3	1135.02	`t591_transcription`.`land_shape_coordinates`	staging/tw591	15,616,508 / 15,616,508	大结果集传输（1,562 万行、json coordinate 列 10G）
4	1130.58	`t8_game`.`t8_embeddings_cache`	staging/tw8591	79,835 / 79,835	大结果集传输（仅 8 万行但 vector json 宽行，70M/次）
5	1038.40	`t591_new`.`fetch_data_item`	staging/tw591	398,940 / 398,940	大结果集传输（longtext 抓取原文，576M/次）
6	897.60	`t591_estate_data`.`rental_market_raw`	staging/tw591	48,006 / 48,006	大结果集传输（raw_html/raw_json 宽行，372M/次）
7	868.19	`lighthouse`.`runs`	staging/8891	7,753 / 7,753	大结果集传输（lhr longtext 全量报告 JSON）
8	795.66	`game`.`t8_embeddings_cache`	staging/tw8591	55,291 / 55,291	大结果集传输（同 #4，43M/次）
9	693.23	`t591_new`.`fetch_data`	staging/tw591	27,022 / 27,022	大结果集传输（body longtext）
10	687.04	`t8891`.`t_sele_item_infos`	staging/8891	3,290,762 / 3,290,762	大结果集传输（329 万行、20G/次）

判定依据（已逐条 EXPLAIN）：全部 access_type=ALL 且 rows_examined == rows_sent、Lock_time 均 < 0.03s——是 mysqldump 的预期全表扫描，不缺索引、无锁问题，慢因纯属"全量宽行导出传输"。

建议（backup 类，不触发深度分析）：

备份错峰：facebook_photo（base64 图床）、t8_embeddings_cache（向量 json）、rental_market_raw（原始 HTML）这类"非核心可重建数据"建议从每日全量 dump 中剔除，单独低频备份或直接不入备份（数据可从源站重抓）。
t_item_modi_histories / t_sele_item_infos（1400 万/330 万行、14~20G）建议改为分库分文件 dump 或用 mydumper 并行 + 压缩流。
昨日 backup 模式条数与常规持平（未环比翻倍），无异常。

三、高频慢查询模式（指纹聚合）

指纹归一化规则：字符串/数字/IN 列表 → ?，保留库表与 SQL 骨架。共聚合出高频模式，Top5 如下。

3.1 按条数 Top5

#	条数	平均(s)	最大(s)	累计	实例	用户	指纹
1	1048	1.53	5.58	26.7min	117/37/40/40_3308/46	jmysql	`SHOW ENGINE INNODB STATUS`
2	280	9.22	11.88	43.0min	117	t591	`SELECT gs.street_id, COUNT(*) FROM golden_source JOIN market_community_building cb … GROUP BY gs.street_id`（GetGoldenSourceCommunityIDRepairStreets）
3	149	1.66	4.17	4.1min	117	t591	`select * from market_ep_build force index (idx_area) where regionid=? and sectionid=? and addr_num1=? and addr_num2=? and status=?`
4	144	10.56	11.38	25.4min	117	t591	`CREATE TEMPORARY TABLE tmp_cvd_t1 AS SELECT … JSON_EXTRACT(viewing_targets …)`（带视图目标 JSON 展开联查）
5	144	294.49	308.71	11.78h	117	t591	`CREATE TEMPORARY TABLE tmp_cvd_t12 AS SELECT … FROM house_ep_source_relate a WHERE type=? AND NOT EXISTS (SELECT 1 FROM … b WHERE … b.score > a.score)` 🔥

3.2 按累计耗时 Top5

#	条数	平均(s)	累计	实例	用户	指纹
1	144	294.49	11.78h	117	t591	`CREATE TEMPORARY TABLE tmp_cvd_t12 … NOT EXISTS …score > a.score`（同上 #5）🔥
2	94	300.00	7.83h	27	a8591	`insert into telescope_entries (batch_id, content, …) values (…)`（精确 300.00s）🔒
3	24	300.00	2.00h	27	a8591	`insert into t8_telescope_entries (…)`（精确 300.00s）🔒
4	24	300.00	2.00h	27	a8591	`SELECT * FROM dy_aigc_crawler_runs WHERE status IN (?) AND available_at<=? ORDER BY id LIMIT 1 FOR UPDATE`（精确 300.00s）🔒
5	16	300.00	1.33h	27	a8591	`UPDATE dy_aigc_news_raw_text_jobs SET status=?, lease_until=NULL …`（精确 300.00s）🔒

3.3 触发深度分析的模式（条数>100 或累计>30min，非 backup）

🔥 P1：`tmp_cvd_t12` 临时表构建 —— 昨日累计最重的模式（144 条 / 平均 294.5s / 累计 11.78 小时）

原始 SQL（staging/tw591，t591 用户，sqlmesh/任务 job 每 10 分钟跑一次的痕迹）：

  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);

DDL/索引（house_ep_source_relate，约 3 万 type=2 记录 × 索引基数推算 32 万行级表）：

KEY idx_post_id_type(type,post_id)、KEY idx_ep_source_id(ep_source_id)、KEY idx_type_ep_score_post(type,ep_source_id,score,post_id)

EXPLAIN（内层 SELECT）：外层走 idx_type_ep_score_post 仅用第 1 列 type（used_key_parts: ["type"]），rows_examined_per_scan=327,754；内层 NOT EXISTS 是 dependent subquery，对外层每一行都按 (type, ep_source_id) 回表比较 score —— O(N × 子查询)。
根因：相关子查询反连接（anti-join）逐行触发，MySQL 5.7 优化器未做物化；表数据量增长后从秒级退化到 ~300s。
建议：

改写为「按 ep_source_id 取最大 score 再回连」：

  CREATE TEMPORARY TABLE tmp_cvd_t12 AS
  SELECT a.ep_source_id, a.post_id
  FROM t591_new.house_ep_source_relate a
  JOIN (SELECT ep_source_id, MAX(score) AS max_score
        FROM t591_new.house_ep_source_relate WHERE type = 2
        GROUP BY ep_source_id) m
    ON m.ep_source_id = a.ep_source_id AND a.score = m.max_score
  WHERE a.type = 2;

聚合走覆盖索引 idx_type_ep_score_post(type,ep_source_id,score)，一次索引扫描完成，预期从 294s → 秒级。

若 MySQL ≥ 8.0.16 可保留 NOT EXISTS 写法（已自动转 anti-join），但当前实测仍是 dependent subquery，优先改写。
该 job 全天 144 次（每 10 分钟），先降频到每小时（累计耗时立减 5/6）作为止血。

🔒 P2：tw8591（LAN_addcn_27）批量精确 300.00s 锁等待（158 条 / 累计 ~13.2h）

涉及 5 个模式，全部 Query_time = 300.00x（= innodb_lock_wait_timeout 到期被杀）：

模式	条数	表	EXPLAIN 结论
`INSERT telescope_entries`（Laravel Telescope）	94	a8591.telescope_entries	插入被唯一键 `uuid` / 二级索引阻塞
`INSERT t8_telescope_entries`	24	t8_time.t8_telescope_entries	同上
`SELECT … FOR UPDATE dy_aigc_crawler_runs`	24	duyo.dy_aigc_crawler_runs	走 `idx_claim(status,…)` range，本身 cost 5.48，不缺索引
`UPDATE dy_aigc_news_raw_text_jobs …`	16	duyo.dy_aigc_news_raw_text_jobs	走 `idx_raw_text_claim(status,…)`，不缺索引
`UPDATE dy_user_logins SET last_login_time … WHERE user_id=?`	11	duyo.dy_user_logins	`const` 级、单行唯一键更新，执行计划零问题

根因：单行主键/唯一键更新也卡满 300s —— 排除索引问题，是长事务/大范围锁持有者阻塞。时间分布与 tw8591 昨日的 mysqldump 备份窗口（#4 t8_game.t8_embeddings_cache 1130s、#8 game.t8_embeddings_cache 795s 均来自 LAN_addcn_27）高度重合：若备份未加 --single-transaction（或表为 DDL 变更过的 MyISAM/无事务场景），FLUSH TABLES WITH READ LOCK / MDL 会卡住全部后续 DML。
建议：

核查 tw8591 备份命令，确保 mysqldump --single-transaction --no-lock-tables；备份窗口与 Telescope 批量写入、AIGC 任务队列错开。
Telescope 是调试观测组件：staging 上将 telescope_entries 改为队列异步写入并缩短保留期（prune），94 条 300s 大部分可消失。
dy_* 任务队列表的 FOR UPDATE 抢占改为 SKIP LOCKED（MySQL 8.0+）：… ORDER BY id ASC LIMIT 1 FOR UPDATE SKIP LOCKED，避免 worker 互相等锁。

⚠️ P3：GetGoldenSourceCommunityIDRepairStreets（280 条 / 平均 9.2s / 累计 43 分钟）

SQL：golden_source gs JOIN market_community_building cb ON cb.id=gs.community_bid JOIN market_community c … WHERE gs.community_bid!=0 AND gs.community_id=0 AND gs.street_id!=0 AND gs.type=1 GROUP BY gs.street_id ORDER BY gs.street_id LIMIT 5（golden_source 在 t591_estate_data 库）
DDL/索引：golden_source 有 idx_comm_type_street(community_id,type,street_id,community_bid) 等 9 个索引。
EXPLAIN：等价查询联表走不出索引组合（跨库 join 列 cb.id/c.id 主键 OK），瓶颈在 gs.community_id=0 AND gs.type=1 命中 idx_comm_type_street 前两列后仍需回表过滤 community_bid!=0 且 GROUP BY street_id 无法直接利用索引序（前导列 community_id 是等值，street_id 是第 3 列，理论上可用索引序——实际 rows 高说明 community_id=0 的行占比极大，索引选择性差）。
建议：给 golden_source 增加部分场景专用索引 idx_type_street_comm(community_id, type, street_id) 已存在近似覆盖；更有效的是将「community_id=0 待修复」清单改为任务跑完后落结果表（该查询明显是修复任务的轮询探查，280 次/天结果几乎不变），或加 LIMIT 前置 WHERE community_id=0 的计数缓存。

⚠️ P4：`market_ep_build FORCE INDEX (idx_area)` 地址匹配（149 条 / 平均 1.66s）

DDL/索引：idx_area(regionid,sectionid,streetid)、idx_out_id、idx_community_bid、idx_unit_sec_no。
EXPLAIN：used_key_parts: [regionid, sectionid]（streetid 不在 WHERE 中，只用 2 列），rows_examined_per_scan=155,798，返回仅 ~155 行，filtered 0.10% —— 典型的索引前缀选择性不足。
建议：新增索引覆盖地址匹配列：

  ALTER TABLE t591_new.market_ep_build
    ADD INDEX idx_area_addr (regionid, sectionid, addr_num1, addr_num2, status);

去掉 SQL 中的 FORCE INDEX (idx_area)（或改为 FORCE 新索引），预期 rows_examined 从 15.6 万 → 个位/百位级，单条 1.66s → 毫秒级，全天节省 ~4 分钟 DB 时间。

ℹ️ P5：`SHOW ENGINE INNODB STATUS`（1048 条 / 平均 1.53s / 26.7min）

来自监控（jmysql 用户，5 台实例），非业务 SQL。1.5s 均值说明 InnoDB 内部锁（SHOW ENGINE INNODB STATUS 需要 trx_sys mutex，阻塞说明当时有大事务/大量 purge）——它与 P1（tw591 300s 大查询）时间上互相印证。
建议：保留监控但降频（1048→300 次/天足够）；治本靠 P1 消灭长事务。

四、逐条优化建议汇总（按收益排序）

改写 tmp_cvd_t12（MAX(score) 聚合改写 + 降频） —— 收益最大：全天减少 ~11 小时 DB 耗时（P1）。
核查 tw8591 备份参数（--single-transaction）+ Telescope 异步化 + SKIP LOCKED —— 消灭 158 条 300s 锁等待（P2）。
market_ep_build 加 (regionid,sectionid,addr_num1,addr_num2,status) 索引 —— 149 条/天降到毫秒级（P4）。
GetGoldenSourceCommunityIDRepairStreets 结果缓存/落表 —— 去掉 280 次/天重复聚合（P3）。
备份集瘦身：facebook_photo(base64)、t8_embeddings_cache(向量)、rental_market_raw(原始 HTML) 移出每日全量 dump（Top10 全部为备份导出，合计 3 小时+ IO）。
SHOW ENGINE INNODB STATUS 监控降频（P5）。

五、数据来源与口径

ES 慢日志：staging ES mysql_slow-*，@timestamp ∈ [2026-09-16T16:00:00Z, 2026-09-17T16:00:00Z)（= UTC+8 昨日全天），共 4,946 条，单页拉全。
Top10：MCP es_slow_logs(start=2026-09-17T00:00:00+08:00, end=2026-09-18T00:00:00+08:00, top=10, env=staging)。
表结构与执行计划：MCP connect → describe_schema → explain → disconnect（staging/tw591、staging/tw8591、staging/8891），全程只读，未执行任何写操作/KILL/配置变更/git 提交。
高频聚合：es_search 分页拉取 + Python 指纹归一化（字符串/数字/IN 列表 → ?）。
局限说明：tmp_cvd_t1（JSON 展开）未单独 EXPLAIN（依赖存储过程上下文），其 25.4 分钟/天与 P1 同一 job 链路，改写 P1 时一并评估。