MySQL 慢查询日报 2026-09-21

统计口径：2026-09-21 00:00:00 ~ 23:59:59（Asia/Shanghai），staging 环境全部 MySQL 实例

数据来源：ES 慢日志索引 mysql_slow-*（经 MCP es_slow_logs / es_search，UTC+8 昨日全天 → UTC [09-20T16:00Z, 09-21T16:00Z)）

生成时间：2026-09-22 10:00 (CST) ｜全程只读（describe_schema / EXPLAIN / _search），无任何写库、kill 或配置变更

一、统计概览

指标	数值
慢查询总条数	4,187
累计耗时	85,673 s ≈ 23.8 小时
备份慢查询（mysqldump）	845 条 / 32,258 s（占累计 37.7%）
业务慢查询（非备份）	3,342 条 / 53,415 s
最慢单条	2,383.6 s（backup 导出 `test.facebook_photo`）
慢查询最多实例	LAN_addcn_117（staging/tw591，2,635 条，占 63%）
慢查询最多用户	t591（1,564）、backup（829）、jmysql 监控（826）
聚合指纹数	1,189 个模式

二、Top10 慢查询明细

昨日 Top10 全部为 backup 用户（mysqldump）全表导出，慢因均为「大结果集传输」：SELECT * 宽行 + SQL_NO_CACHE 全量回传，rows_examined ≈ rows_sent，无锁等待（Lock_time 均 < 1ms）。

#	耗时(s)	库.表	行数	实例	慢因
1	2383.6	test.facebook_photo	101,727	staging/tw591	大结果集：表含 `base64_photo longtext`/`ocr_result longtext` 超宽行（DDL 已核实），单行可达数 MB
2	1538.2	t8891.t_item_modi_histories	5,693,964	staging/8891	大结果集：570 万行历史表全量导出
3	1385.8	t591_new.fetch_data_item	398,940	staging/tw591	大结果集：`from_list`/`from_detail` 均 longtext
4	1310.5	t591_estate_data.rental_market_raw	48,006	staging/tw591	大结果集：`raw_html mediumtext` 原始 HTML 全量
5	1176.5	t591_transcription.land_shape_coordinates	15,616,508	staging/tw591	大结果集：1,562 万行，`coordinate json`
6	1143.9	t8891.t_sele_item_infos	3,290,762	staging/8891	大结果集：329 万行
7	994.7	t591_new.fetch_data	27,022	staging/tw591	大结果集：`body longtext` 抓取原文
8	891.3	server_monitor.line_business_tests	331,786	staging/tw591	大结果集：5 个 json 列宽行
9	837.4	t591_new.market_spider_house_test	195,429	staging/tw591	大结果集：`objet_data longtext`
10	755.0	t591_data.full_web_detail_source	305,563	staging/tw591	大结果集：`body longtext`

备份环比：昨日备份慢查询 845 条 vs 前日 829 条（+1.9%），无异常增长 → 按规则不触发深度分析。

Top10 建议（通用）：

备份窗口错峰，避免与 tmp_cvd_* 定时任务（LAN_addcn_117 每 5 分钟）叠加 IO；
test.facebook_photo 等 longtext/base64 列建议排除出常规备份（--ignore-table）或改存对象存储；
mysqldump 加 --where/分库分表并行，或改用 xtrabackup 物理备份避免逐行回传。

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

指纹归一化：字符串/数字/IN 列表 → ?，保留库表与 SQL 骨架。「按条数 Top5」：

#	条数	累计耗时	平均(s)	最大(s)	用户	实例	模式
1	748	1,127s	1.5	2.9	jmysql	多实例(117/27/37/40/46)	`SHOW ENGINE INNODB STATUS`（监控采集）
2	288	2,745s	9.5	12.7	t591	117	GetGoldenSourceCommunityIDRepairStreets：`golden_source ⋈ market_community_building ⋈ market_community GROUP BY street_id` ⚠️深析
3	144	1,540s	10.7	13.2	t591	117	`CREATE TEMPORARY TABLE tmp_cvd_t1`（带看记录 JSON 展开，每 5 分钟） ⚠️深析
4	144	42,294s	293.7	307.2	t591	117	`tmp_cvd_t12`：`house_ep_source_relate` 反连接去重（每 5 分钟） 🔴全天累计 11.7h，最大元凶
5	144	335s	2.3	5.2	t591	117	`tmp_cvd_t14`：`house_source_ep_build_relate` 反连接去重（每 5 分钟） ⚠️深析

「按累计耗时 Top5」：

#	条数	累计耗时	平均(s)	最大(s)	用户	模式
1	144	42,294s (11.7h)	293.7	307.2	t591	`tmp_cvd_t12` 反连接去重（非备份） 🔴
2	845	32,258s (9.0h)	—	2,383.6	backup	mysqldump 全表导出（【备份】，环比+1.9% 无异常）
3	288	2,745s (45.8min)	9.5	12.7	t591	GetGoldenSource 社区街道修复查询
4	144	1,540s (25.7min)	10.7	13.2	t591	`tmp_cvd_t1` 带看 JSON 展开临时表
5	105	241s	2.3	4.8	bee,t8891	`COMMIT`（事务提交/组提交等待）

触发深度分析（条数>100 或累计>30min，非备份）：模式 2/3/4/5、SHOW ENGINE INNODB STATUS(748 条)、COMMIT(105 条)。后两者为监控/事务语句，不适用 describe_schema+EXPLAIN 链路，按语义分析见下。

四、深度分析详情（describe_schema + EXPLAIN 已核实）

🔴 P1：tmp_cvd_t12 —— 全天累计 11.7 小时（144 次 × 294s）

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)))
DDL（已核实）：house_ep_source_relate 146 万行，已有索引 idx_type_ep_score_post(type,ep_source_id,score,post_id)（覆盖索引）。
EXPLAIN（已核实）：外层 ref 走 idx_type_ep_score_post 仅用 type 前缀，rows_examined_per_scan=285,940；子查询为 dependent（不可缓存），每个外层行再回索引探测 ≈2 行。单次执行 ≈ 28.6 万外层行 × 相关子查询 = 数十万次索引探测，且 score 为 decimal OR 条件无法短路。
根因：反连接（NOT EXISTS 取组内最高分）算法本质是每行都比较组内其他行，O(n×组大小)；每 5 分钟全量重算。
建议（可执行）：

改写为窗口函数，一次扫描取组内最优：SELECT ep_source_id, post_id FROM (SELECT ep_source_id, post_id, ROW_NUMBER() OVER (PARTITION BY type, 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，单次 28.6 万行一遍即可完成，预计从 294s 降至 2~5s；
调度降频：全量去重结果变化缓慢，5 分钟 → 1 小时即可再降 12 倍；
若 MySQL < 8.0，可用 LEFT JOIN 自连接取 MAX(score) 等价改写，同样消除相关子查询。

🟠 P2：GetGoldenSourceCommunityIDRepairStreets —— 288 次 × 9.5s = 45.8 min/天

SQL：FROM golden_source gs JOIN market_community_building cb ON cb.id=gs.community_bid JOIN 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 LIMIT 5（golden_source 实际位于 t591_estate_data 库，已定位）
DDL（已核实）：golden_source 有 idx_comm_type_street(community_id,type,street_id)；两 JOIN 表均以主键 eq_ref 命中。
EXPLAIN（已核实）：gs 走 idx_comm_type_street range 扫描 rows_examined_per_scan=4,285,534，产出 192.8 万行，随后对 cb、c 各做 192.8 万次 eq_ref 主键回表（data_read_per_join 4G）。
根因：community_id=0 AND type=1（待修复数据）命中近 200 万行，聚合基数大；索引已是覆盖索引，问题在每次全量重算 + 海量 join 回表。
建议：

该查询结果是「修复任务」扫描集，LIMIT 5 却仍聚合全部行——先 GROUP BY … LIMIT 语义不变，但建议加 AND gs.updated_at > ? 增量水位条件，配合索引 idx_comm_type_updated(community_id,type,updated_at) 只扫新增/变更行；
调度降频（5 分钟 → 30 分钟，结果集变化慢）；
或落地汇总表 golden_source_street_agg(street_id, cnt) 由触发器/定时任务维护，查询改读汇总表。

🟠 P3：tmp_cvd_t1 —— 144 次 × 10.7s = 25.7 min/天

SQL：agent_customer_viewing acv × 0~999 数字表展开 viewing_targets JSON 数组，LEFT JOIN agent_customer，WHERE 为跨两张表的 5 个 OR 条件（acv/ac 的 created_at/updated_at/deleted_at >= CURDATE()）。
DDL/EXPLAIN（已核实）：acv 仅 1,760 行，EXPLAIN 中 acv 为 ALL 全表扫（OR 跨表导致无法用 idx_deleted_at 等），ac 走主键 eq_ref。
根因：表本身很小，耗时主要在 JSON_EXTRACT × 数字表 CROSS JOIN 的逐行函数计算与宽行临时表写入；OR 跨表条件使优化器放弃索引（本例影响有限）。
建议：拆 OR 为 UNION ALL（各自走 created_at 索引）；JSON 展开改用 MySQL 8.0 JSON_TABLE()；该任务与 tmp_cvd_t12 同属一个 5 分钟定时任务链，可一并降频。

🟡 P4：tmp_cvd_t14 —— 144 次 × 2.3s = 5.6 min/天

EXPLAIN（已核实）：外层 house_source_ep_build_relate ALL 全表扫 228,162 行（无 type 过滤、ep_build_id 无可用前缀），子查询 dependent ref 走 idx_ep_source_id(ep_build_id)。
建议：与 t12 同款窗口函数改写（PARTITION BY ep_build_id ORDER BY score DESC, source_id DESC 取 rn=1）；另补复合索引 (ep_build_id, score, source_id)（现 idx_ep_source_id 仅单列）。DDL 变更属写操作，本报告仅建议、未执行。

🟡 P5：SHOW ENGINE INNODB STATUS（748 条）/ COMMIT（105+84 条）

前者为 jmysql/zabbix 监控采集命令，非业务 SQL，不适用 EXPLAIN；其本身 1.5~2.9s 的耗时是实例繁忙的果而非因（昨日在 7 台实例上均变慢，与备份导出 + tmp_cvd 任务 IO 叠加时段吻合）。
COMMIT 慢（avg 2.3s，max 15.7s）指向大事务/组提交等待与 fsync 压力：建议业务侧减小事务批量（分批提交），并错峰 backup。
治本优先级：先解决 P1（tmp_cvd_t12，全天 11.7h IO），监控/COMMIT 变慢预计随之缓解。

五、逐条优化建议汇总

优先级	对象	动作	预期收益
P0	tmp_cvd_t12 SQL	窗口函数改写（ROW_NUMBER PARTITION BY ep_source_id）+ 调度降频至 1h	单次 294s→秒级，全天省 ~11h
P1	GetGoldenSource 修复查询	增量水位条件 + 新增 (community_id,type,updated_at) 索引 + 降频	全天省 ~45min
P2	tmp_cvd_t1	UNION ALL 拆 OR、JSON_TABLE 改写	单次 10.7s→1s 级
P2	tmp_cvd_t14	窗口函数改写 + 补 (ep_build_id,score,source_id) 索引	单次 2.3s→亚秒
P3	备份任务	错峰备份窗口；facebook_photo 等 longtext 表 `--ignore-table` 或对象存储化	削峰 IO，减少对监控/COMMIT 的挤压
P3	监控采集	无需改 SQL；随 P0~P2 落地观察	SHOW ENGINE INNODB STATUS 耗时回落

注：以上所有索引/DDL 仅为建议，本次未对数据库执行任何写操作。

六、数据来源与生成时间

慢日志：MCP es_slow_logs（Top10）+ es_search（全量 4,187 条，单页 ≤5000 无需翻页），索引 mysql_slow-*，@timestamp ∈ [2026-09-21T00:00:00+08:00, 2026-09-22T00:00:00+08:00)
结构与执行计划：MCP connect → describe_schema / explain（staging/tw591、staging/8891，只读），分析后 disconnect
备份环比：前日（09-20）SQL_NO_CACHE 命中 829 条
脚本：.agents/scripts/slow_report_20260921_{gather,docs,fps,deep}.py（数据缓存 outputs/slow_*_20260921.json）
报告生成：2026-09-22 10:00 CST，自动生成，未经人工复核