MySQL 慢查询日报 2026-09-19（staging）

统计口径：2026-09-19 00:00:00 ~ 23:59:59（Asia/Shanghai），ES 慢日志按 @timestamp UTC 换算
环境：staging（ES 索引 mysql_slow-*，经 MCP es_slow_logs / es_search）
数据来源：MCP addcn（http://192.168.8.75:8200/mcp），全程只读（connect / describe_schema / explain / es_search / es_slow_logs）
生成时间：2026-09-20 10:00 +08:00

一、统计概览

指标	数值
昨日慢日志文档总数	3,645 条（es_search 全量拉取，单页取完）
Top10 单条最慢	2,333.9 s（mysqldump `test.facebook_photo`）
Top10 构成	10/10 全部为 `user=backup` 的 mysqldump 全表导出
慢因分布（Top10）	大结果集传输 10 条；缺索引 0；锁等待 0
最重高频模式	`CREATE TEMPORARY TABLE tmp_cvd_t12 ...`：144 条 × 平均 294.5 s = 累计 11.8 小时
涉及实例	staging/tw591（192.168.8.117）、staging/8891（192.168.8.84）

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

#	耗时(s)	库.表	行扫/行回	user	实例	慢因类型
1	2333.94	test.facebook_photo	101,727 / 101,727	backup	staging/tw591	大结果集传输（mysqldump）
2	1370.96	t8891.t_item_modi_histories	5,693,964 / 5,693,964	backup	staging/8891	大结果集传输（mysqldump）
3	1154.90	t591_transcription.land_shape_coordinates	15,616,508 / 15,616,508	backup	staging/tw591	大结果集传输（mysqldump）
4	1137.62	t8891.t_sele_item_infos	3,290,762 / 3,290,762	backup	staging/8891	大结果集传输（mysqldump）
5	1059.24	t591_new.fetch_data_item	398,940 / 398,940	backup	staging/tw591	大结果集传输（mysqldump）
6	1002.88	t591_estate_data.rental_market_raw	48,006 / 48,006	backup	staging/tw591	大结果集传输（mysqldump）
7	753.87	server_monitor.line_business_tests	331,786 / 331,786	backup	staging/tw591	大结果集传输（mysqldump）
8	713.93	t591_new.fetch_data	27,022 / 27,022	backup	staging/tw591	大结果集传输（mysqldump）
9	693.92	t591_new.market_spider_house_test	195,429 / 195,429	backup	staging/tw591	大结果集传输（mysqldump）
10	646.94	t591_data.full_web_detail_source	305,563 / 305,563	backup	staging/tw591	大结果集传输（mysqldump）

Top10 全部为备份导出（SELECT /*!40001 SQL_NO_CACHE */ *，Lock_time 均 <1ms，rows_examined = rows_sent，EXPLAIN 为预期全表扫描），非业务慢查询，不触发优化。已逐一走 describe_schema + explain 确认（DDL 详见附数据 JSON）。

三、高频慢查询模式（指纹归一化，3,645 条聚合）

按条数 Top5

#	条数	平均(s)	最大(s)	累计	user	server	指纹（截断）
1	909	1.54	—	1401.5s	jmysql	addcn_117/27/27_3307/40/40_3308	`SHOW ENGINE INNODB STATUS`
2	288	9.06	—	2610.0s	t591	addcn_117	`-- name: GetGoldenSourceCommunityIDRepairStreets :many SELECT gs.street_id, COUNT(*) ... FROM golden_source JOIN market_community_building cb ... GROUP BY gs.street_id LIMIT ?`
3	144	10.62	—	1529.3s	t591	addcn_117	`CREATE TEMPORARY TABLE tmp_cvd_t1 AS SELECT acv.id, ... JSON_EXTRACT(acv.viewing_targets, ...)`
4	144	294.51	—	42409.3s	t591	addcn_117	`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 = ? AND NOT EXISTS (...)` 🔥
5	144	1.88	—	270.6s	t591	addcn_117	`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 (...)`

按累计耗时 Top5

#	累计	条数	平均(s)	user	指纹（截断）	备注
1	42409.3s (11.8h)	144	294.51	t591	`tmp_cvd_t12`（house_ep_source_relate 反连接）	🔥 触发深度分析
2	2610.0s	288	9.06	t591	GetGoldenSourceCommunityIDRepairStreets	🔥 触发深度分析
3	2333.9s	1	2333.94	backup	mysqldump `test.facebook_photo`	【备份模式】
4	1529.3s	144	10.62	t591	`tmp_cvd_t1`（customer viewing JSON 展开）	🔥 触发深度分析
5	1401.5s	909	1.54	jmysql	`SHOW ENGINE INNODB STATUS`	监控探测，见下

四、触发深度分析的模式详情

以下均已在 staging/tw591 实例完成 connect → describe_schema → explain（只读）。

🔥 P0：tmp_cvd_t12 — 累计 11.8 小时，昨日最重模式

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 ... 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)))
频率：144 次/天（约每 10 分钟一次），avg 294.5s / max ≈ 294.5s
DDL：house_ep_source_relate（~146 万行）已有 idx_type_ep_score_post(type, ep_source_id, score, post_id) 等四个索引，不缺索引。
EXPLAIN：外层 a 走 idx_type_ep_score_post（仅用 type 前缀，index-only 扫 272,454 行）；子查询 b 为相关子查询（ref，每次 ~2 行）。语义是"每个 ep_source_id 取 score/post_id 最大的记录"（反连接去重）。
根因：逐行相关子查询执行 27 万次 NOT EXISTS 判断 → O(N×k) 评估成本（query_cost 55,023，eval_cost 占 98%）；每 10 分钟重复计算全量结果。属"写法问题 + 重复计算"，非缺索引。
建议：

改写为窗口函数一次性去重：SELECT ep_source_id, post_id FROM (SELECT ep_source_id, post_id, ROW_NUMBER() OVER (PARTITION BY ep_source_id ORDER BY score DESC, post_id DESC) rn FROM t591_new.house_ep_source_relate WHERE type = 2) t WHERE rn = 1，配合现有索引可一遍索引扫描完成；
更根本：该结果对 type=2 数据基本静态，改为物化表/每日低频刷新，去掉每 10 分钟的 CREATE TEMPORARY TABLE 全量重算。

🔥 P1：GetGoldenSourceCommunityIDRepairStreets — 288 次/天 × 9.06s

SQL：SELECT gs.street_id, COUNT(*) ... FROM golden_source gs JOIN t591_new.market_community_building cb ON cb.id=gs.community_bid JOIN t591_new.market_community c ON c.id=cb.community_id AND c.deleted_at IS NULL 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
DDL：golden_source（~890 万行）已有 idx_comm_type_street(community_id, type, street_id, community_bid)；两张 JOIN 表均走 PRIMARY eq_ref。
EXPLAIN：gs 走 idx_comm_type_street range，扫描 428 万行、产出 192.8 万行参与 JOIN+GROUP BY（data_read 4G）。
根因：community_id = 0（待修复数据）本身占表约一半，索引前缀选择不出更小集合 —— 属大聚合 + 高频重复执行（每 5 分钟一次 LIMIT 5 的修复扫描），非缺索引。
建议：

结果做缓存（SQL_CALC 或应用层 cache，TTL ≥ 30 分钟），避免 288 次/天全量 GROUP BY；
若必须实时，把条件改为等值前缀利用 (community_id, type) 之后仍需扫 4M 行，可考虑维护一个只含 community_id=0 待修复行的影子索引表或定期将修复后的行 community_id 回填，缩小集合；
LIMIT 5 只取前 5 个 street_id，可用 GROUP BY ... ORDER BY cnt DESC LIMIT 5 的近似 TOP-N 物化减少无效计算。

🔥 P2：tmp_cvd_t1 — customer viewing JSON 展开，144 次/天 × 10.6s

SQL：CREATE TEMPORARY TABLE tmp_cvd_t1 AS SELECT acv.id, acv.customer_id, acv.viewing_date, JSON_UNQUOTE(JSON_EXTRACT(acv.viewing_targets, CONCAT('$[', n.n, '].type'))), ...
根因：对带看记录表逐行做 JSON_EXTRACT 展开多目标，CPU 密集 + 无索引可用（JSON 函数不可索引）。
建议：与 P0 同一调度链路（同为 144 次/天），建议整条 ETL 降频/合并到离线窗口执行；若 MySQL 8 可评估生成列 + 索引，但更实际的是减少重复执行次数。

P3：SHOW ENGINE INNODB STATUS — 909 次/天 × 1.54s（jmysql 监控）

监控账号探测命令本身，非业务 SQL，不适用索引优化。单次 1.5s 偏高，侧面反映 tw591 实例负载重（与 P0 每 10 分钟 5 分钟级大查询直接相关）。优先解决 P0 后此项预计自然下降；同时建议监控侧将采集间隔从 1 分钟适度放宽或错峰。

备份模式说明（不触发深度分析）

mysqldump 全表导出（user=backup）昨日条数与耗时未见异常倍增（Top10 单条最大 2333s，历史常态量级）；建议维持备份窗口错峰即可。

五、逐条优化建议汇总

优先级	对象	建议	预期收益
P0	`tmp_cvd_t12`（house_ep_source_relate 去重）	窗口函数改写 + 物化/降频	累计 11.8h/天 → 分钟级
P1	GetGoldenSourceCommunityIDRepairStreets	结果缓存（TTL≥30min）+ 修复数据回填缩小 community_id=0 集合	2610s/天 → ~100s/天
P2	`tmp_cvd_t1` JSON 展开	ETL 离线化/降频（与 P0 同链路）	1529s/天显著下降
P3	SHOW ENGINE INNODB STATUS 慢	解决 P0 后复查；监控错峰	909×1.5s 自然缓解
—	Top10 mysqldump	无需索引改动，保持备份错峰窗口	—

六、数据来源与生成时间

MCP：http://192.168.8.75:8200/mcp（es_slow_logs top=10 env=staging；es_search mysql_slow-* 全量 3,645 条；connect/describe_schema/explain 于 staging/tw591、staging/8891，分析后均 disconnect）
原始数据：outputs/slow_20260919_data.json、outputs/slow_20260919_deep2.json、outputs/slow_20260919_deep3.json
生成时间：2026-09-20 10:00（Asia/Shanghai）；脚本：.agents/scripts/slow_report_20260919.py
说明：es_search 单页即取完全部 3,645 条，未触发 search_after 翻页；昨日数据充足，未回退前日。