MySQL 慢查询日报 2026-09-13

统计口径：2026-09-13 00:00:00 ~ 23:59:59（Asia/Shanghai，即 UTC [2026-09-12T16:00:00Z, 2026-09-13T16:00:00Z)）

环境：staging　|　数据来源：MCP es_slow_logs（Top10）+ es_search 索引 mysql_slow-*（高频模式，实际拉取 4,150 条）

生成时间：2026-09-14 10:0x +08:00　|　全程只读（connect / describe_schema / explain / es_search）

1. 统计概览

昨日 staging 慢日志共拉取 4,150 条（es_search 单页 5000 内一次取完，无翻页）。
Top10 全部为 user=backup 的 mysqldump 全表导出（SELECT /*!40001 SQL_NO_CACHE */ * FROM 库.表），单条最长 2,183s（36 分钟，test.facebook_photo）。属备份窗口正常行为，不触发深度分析。
业务侧最突出的问题在 频次维度：
tmp_cvd_t12（t591_new.house_ep_source_relate 反连接建临时表）：144 次 × 平均 294s ≈ 累计 11.8 小时，全天最大耗时来源；
一批精确 300.00s 的语句（telescope_entries 大 JSON INSERT、dy_aigc_crawler_runs FOR UPDATE）：典型 innodb_lock_wait_timeout（默认 300s）锁等待超时，全天合计约 6.6 小时；
监控账户 jmysql 的 SHOW ENGINE INNODB STATUS 出现 828 次、平均 1.46s，侧面反映实例存在锁/信号量压力。

2. Top10 明细（按单条耗时）

#	耗时(s)	用户	实例(alias)	表	扫描/返回行	慢因分类
1	2183.48	backup	staging/tw591	test.facebook_photo	101,727 / 101,727	备份全表导出（mysqldump SQL_NO_CACHE）
2	1420.42	backup	staging/8891	t8891.t_item_modi_histories	5,693,964 / 5,693,964	备份全表导出（大表 570 万行）
3	1132.85	backup	staging/tw8591	t8_game.t8_embeddings_cache	79,835 / 79,835	备份全表导出
4	1099.97	backup	staging/tw591	t591_transcription.land_shape_coordinates	15,616,508 / 15,616,508	备份全表导出（1,560 万行宽表，最重）
5	899.23	backup	staging/8891	lighthouse.runs	7,753 / 7,753	备份全表导出（单行宽，Byte 流大）
6	837.25	backup	staging/tw591	t591_new.fetch_data_item	398,940 / 398,940	备份全表导出
7	806.12	backup	staging/tw8591	game.t8_embeddings_cache	55,291 / 55,291	备份全表导出
8	781.91	backup	staging/8891	t8891.t_sele_item_infos	3,290,762 / 3,290,762	备份全表导出
9	774.41	backup	staging/tw591	t591_estate_data.rental_market_raw	48,006 / 48,006	备份全表导出
10	606.28	backup	staging/tw591	t591_new.fetch_data	27,022 / 27,022	备份全表导出

EXPLAIN 对上述导出 SQL 均为全表扫描（type=ALL），但这是 mysqldump 预期行为；rows_examined == rows_sent，无低效问题。唯一注意点：#2/#4/#8 三张大表（数百万~千万行）备份单表耗时超 12 分钟，建议核对备份窗口是否与业务定时任务（如 144 次的 cvd 任务）重叠造成 IO 争抢。

3. 高频慢查询模式（指纹聚合，共 4,150 条）

3.1 按条数 Top5

#	条数	平均(s)	最大(s)	累计	用户	server	模式（指纹摘要）
1	828	1.46	—	20.1 min	jmysql	LAN_addcn_117/40/40_3308/46	`SHOW ENGINE INNODB STATUS`（监控）
2	288	9.02	—	43.3 min	t591	LAN_addcn_117	`GetGoldenSourceCommunityIDRepairStreets`（golden_source 三表 JOIN + GROUP BY）
3	144	10.49	—	25.2 min	t591	LAN_addcn_117	`CREATE TEMPORARY TABLE tmp_cvd_t1 AS SELECT ... JSON_EXTRACT(...)`
4	144	294.38	300	11.8 h	t591	LAN_addcn_117	`CREATE TEMPORARY TABLE tmp_cvd_t12 ... NOT EXISTS (house_ep_source_relate 自反连接)` ⚠️
5	144	2.01	—	4.8 min	t591	LAN_addcn_117	`CREATE TEMPORARY TABLE tmp_cvd_t14 ... NOT EXISTS (house_source_ep_build_relate 自反连接)` ⚠️

3.2 按累计耗时 Top5

#	条数	平均(s)	累计	用户	server	模式（指纹摘要）
1	144	294.38	11.8 h	t591	LAN_addcn_117	`tmp_cvd_t12` 反连接（同上）⚠️
2	24	300.00	2.0 h	a8591	LAN_addcn_27	`INSERT INTO telescope_entries (...大 JSON content...)` 🔒
3	23	300.00	1.92 h	a8591	LAN_addcn_27	`INSERT INTO t8_telescope_entries (...)` 🔒
4	18	300.00	1.5 h	a8591	LAN_addcn_27	`SELECT ... FROM dy_aigc_crawler_runs ... FOR UPDATE` 🔒
5	15	300.00	1.25 h	a8591	LAN_addcn_27	`INSERT INTO telescope_entries (...)`（另一指纹变体）🔒

注：备份（user=backup）模式已从两表中按口径单独归入 Top10 明细；本日无备份模式条数/耗时异常环比。#4/#5 的 cvd 相关模式与 #1~#3 的 300s 精确整秒模式均触发深度分析（条数>100 或累计>30min），详见下节。

4. 触发深度分析的模式详情

4.1 ⚠️ tmp_cvd_t12 — house_ep_source_relate 自反反连接（累计 11.8h，本日最重）

代表 SQL：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.post_id>a.post_id)))
表索引（describe_schema 实测）：KEY (type,post_id)、(out_id)、(ep_source_id)、(type,ep_source_id,score,post_id)
EXPLAIN：外层 a 走 idx(type,ep_source_id,score,post_id) 的 type 前缀（ref），rows_examined_per_scan ≈ 318,160——即 type=2 的 31.8 万行每行都要做一次相关子查询比较，144 次执行 ≈ 全天反复做 4,500 万次行比较。
根因：反连接"取每组 score 最大的行"用相关子查询实现，外层命中行数巨大；虽有覆盖索引但算法复杂度仍为 O(N×组内行数)，且每日 144 轮（每 10 分钟一轮）全量重算。
建议：

改写为窗口函数（MySQL 8）：ROW_NUMBER() OVER (PARTITION BY ep_source_id ORDER BY score DESC, post_id DESC) 取 rn=1，一次扫描替代反连接；
或把结果物化到普通表 + 增量更新，替代每 10 分钟重建临时表；
降低调度频率（144 次/天 → 业务低峰几次），错开备份窗口。

4.2 ⚠️ tmp_cvd_t14 — house_source_ep_build_relate 自反反连接（144 次 × 2.01s）

代表 SQL：CREATE TEMPORARY TABLE tmp_cvd_t14 AS SELECT a.ep_build_id, a.source_id FROM t591_new.house_source_ep_build_relate a WHERE NOT EXISTS (SELECT 1 FROM ... b WHERE b.ep_build_id=a.ep_build_id AND (b.score>a.score OR (b.score=a.score AND b.source_id>a.source_id)))
表索引：KEY (ep_build_id)、(out_id)、(source_id)、(relate_id) —— 均为单列索引，无 (ep_build_id, score, source_id) 组合索引
EXPLAIN：外层 a type=ALL 全表扫描（≈228,162 行），每行再做相关子查询 → 明确缺索引。
建议：加组合索引 ALTER TABLE t591_new.house_source_ep_build_relate ADD INDEX idx_build_score_source (ep_build_id, score, source_id); 可同时覆盖外层分组与子查询比较；同样建议窗口函数改写。

4.3 🔒 精确 300s 锁等待组（telescope_entries INSERT / dy_aigc_crawler_runs FOR UPDATE，合计 ≈6.6h）

特征：平均耗时精确 300.0002s —— 即 innodb_lock_wait_timeout（默认 300s）超时，属锁等待而非缺索引。
dy_aigc_crawler_runs（duyo 库）已验证：EXPLAIN 走 idx_claim(status,...) range 扫描仅 2 行，FOR UPDATE 领取任务的查询本身很快；慢是因为多 worker 并发 FOR UPDATE 争同一批 waiting 行，等锁至 300s 超时。
telescope_entries（Laravel Telescope，存在于 a8591/addcn_share 等 8 个库）：插入的是超大 JSON content（整段事件 payload），单行体积大 + 高频写入，与大事务/锁争用叠加后批量超时。
建议：

telescope：缩短 content（截断 payload）、开启 Telescope 入队异步写入（telescope.queue）、或降低采样；对历史表做定期 prune；
dy 爬虫领取：把 SELECT ... FOR UPDATE 改为 SKIP LOCKED（ORDER BY id LIMIT 1 FOR UPDATE SKIP LOCKED），worker 之间不再互相等锁，可消除全部 300s 超时；
排查 192.168.8.27（tw8591）上持有这些行锁的长事务（可用 show_lock_waits 复核）。

4.4 其他触发项

GetGoldenSourceCommunityIDRepairStreets（288 次 × 9.02s，golden_source 三表 JOIN + GROUP BY）：explain 因 golden_source 未带库名未能执行；从指纹看 golden_source 与 market_community_building 仅单列索引（community_id/streetid/lat,lng/door_plate_id），JOIN 键 gs.community_bid、过滤键 (community_id, street_id, type) 疑似缺组合索引，建议补 golden_source(community_id, street_id, type, community_bid) 后复核。
SHOW ENGINE INNODB STATUS 828 次平均 1.46s（jmysql 监控）：该命令需要拿锁读 status，本身 1.4s+ 说明实例存在锁/信号量压力，与 4.3 的锁等待互相印证；建议监控降频（如 30s→60s）并优先解决 4.3。
tmp_cvd_t1（JSON_EXTRACT 临时表，144×10.5s）：JSON 逐行函数计算无索引可用，建议业务侧预计算列（generated column + 索引）。

5. 逐条优化建议汇总

优先级	对象	动作
P0	t591_new.house_source_ep_build_relate	加组合索引 `(ep_build_id, score, source_id)`
P0	duyo.dy_aigc_crawler_runs 领取逻辑	`FOR UPDATE` → `FOR UPDATE SKIP LOCKED`
P0	telescope_entries（多库）	content 截断/队列异步写入/定期 prune
P1	tmp_cvd_t12（house_ep_source_relate）	窗口函数改写或结果物化 + 降频（当前 10 分钟一轮全量重算）
P1	golden_source	组合索引 `(community_id, street_id, type, community_bid)` 并复核 explain
P2	备份窗口	核对 mysqldump 大表（land_shape_coordinates 1560 万行等）与 cvd 定时任务是否重叠，错峰
P2	监控	SHOW ENGINE INNODB STATUS 采集降频，降低自身锁竞争

6. 数据来源与生成时间

数据来源：MCP addcn（http://192.168.8.75:8200/mcp）es_slow_logs（Top10, env=staging）、es_search（mysql_slow-*，4,150 docs）、connect/describe_schema/explain/disconnect（staging/tw591、staging/tw8591，全只读）。
中间产物：outputs/slow_report_20260913.json、outputs/slow_raw_20260913.json、outputs/slow_fixup_20260913.json。
生成时间：2026-09-14（Asia/Shanghai）。高频模式节聚合与拉数均成功，无降级说明项。