MySQL 慢查询日报 2026-09-23

统计口径：2026-09-23 00:00:00 ~ 23:59:59（Asia/Shanghai，ES @timestamp UTC 换算）
环境：staging（env="staging"，经 MCP es_slow_logs / es_search）
数据来源：ES 索引 mysql_slow-*（MCP addcn，实例路由 server_name/IP → 可连接实例）
生成时间：2026-09-24（Asia/Shanghai）
全程只读：仅 SELECT / EXPLAIN / SHOW，无写库、无 KILL、无配置变更

1. 统计概览

指标	数值
慢日志总数	4,218 条
Top10 总耗时	11,703 s（≈3.25 h），全部为 backup(mysqldump) 导出
backup 用户条数 / 累计耗时	840 条 / 32,314 s（≈8.98 h）
非备份慢查询条数 / 累计耗时	3,378 条 / 54,183 s（≈15.05 h）
慢查询来源主机 Top3	LAN_addcn_117 (2,663)、LAN_addcn_84 (317)、LAN_addcn_40 (283)
业务用户 Top5	t591 (1,641)、jmysql (757)、a8591 (199)、8591 (192)、news_ai (192)
SQL 指纹数（归一化后）	1,182 个

说明：单条耗时 Top10 全被 backup 全表导出占据（正常备份行为，非异常）；真正值得优化的是高频模式中的 t591 批处理任务（见第 3 节，非备份累计 15 小时，其中 tmp_cvd_t12 一个模式就占 11.8 小时）。

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

#	耗时(s)	用户	实例	库.表	扫描行/返回行	慢因类型	分析结论
1	2344.07	backup	staging/tw591	test.facebook_photo	101,727 / 101,727	大结果集传输	mysqldump 全表导出；表含 `base64_photo`、`ocr_result` 等超宽列，`data_read_per_join≈43M`，瓶颈在传输非扫描。备份行为，无需处理
2	1516.95	backup	staging/8891	t8891.t_item_modi_histories	5,693,964 / 5,693,964	大结果集传输	历史表 570 万行全量导出，rows_examined==rows_sent，无扫描浪费
3	1298.34	backup	staging/tw591	t591_estate_data.rental_market_raw	48,006 / 48,006	大结果集传输	同上，全表导出
4	1290.07	backup	staging/tw591	t591_new.fetch_data_item	398,940 / 398,940	大结果集传输	同上
5	1163.03	backup	staging/tw591	t591_transcription.land_shape_coordinates	15,616,508 / 15,616,508	大结果集传输	1,561 万行坐标数据导出，staging 单表最大导出
6	1093.73	backup	staging/8891	t8891.t_sele_item_infos	3,290,762 / 3,290,762	大结果集传输	同上
7	959.15	backup	staging/tw591	server_monitor.line_business_tests	331,786 / 331,786	大结果集传输	同上
8	906.16	backup	staging/tw591	t591_new.fetch_data	27,022 / 27,022	大结果集传输	同上
9	808.52	backup	staging/tw591	t591_data.full_web_detail_source	305,563 / 305,563	大结果集传输	同上
10	804.19	backup	staging/tw591	t591_new.market_spider_house_test	195,429 / 195,429	大结果集传输	同上

Top10 深度核验（抽样 #1、#2 实测 describe_schema + explain）：facebook_photo PRIMARY range 扫描、rows_examined==rows_sent、Lock_time < 1ms——确认全部为顺序全表读，无缺索引、无锁等待。

3. 高频慢查询模式（指纹聚合，全量 4,218 条 / 1,182 个指纹）

3.1 按条数 Top5

#	条数	累计耗时	平均(s)	最大(s)	用户	模式（指纹）
1	696	1,044.7s	1.50	3.01	backup,jmysql	`SHOW ENGINE INNODB STATUS;`（监控采集，非业务）
2	288	2,873.8s	9.98	13.55	t591	`-- GetGoldenSourceCommunityIDRepairStreets SELECT gs.street_id,COUNT(*) … FROM golden_source JOIN market_community_building … GROUP BY street_id LIMIT ?` ⚠️触发深度分析
3	144	1,548.5s	10.75	12.08	t591	`CREATE TEMPORARY TABLE tmp_cvd_t1 AS SELECT … FROM agent_customer_viewing …(JSON 展开)` ⚠️触发深度分析
4	144	42,595.7s(11.8h)	295.80	369.54	t591	`CREATE TEMPORARY TABLE tmp_cvd_t12 AS SELECT … FROM t591_new.house_ep_source_relate a WHERE type=? AND NOT EXISTS(…)` 🔴最严重
5	144	345.6s	2.40	4.15	t591	`CREATE TEMPORARY TABLE tmp_cvd_t14 AS SELECT … FROM t591_new.house_source_ep_build_relate … NOT EXISTS(…)` ⚠️触发深度分析

3.2 按累计耗时 Top5

#	累计耗时	条数	平均(s)	最大(s)	用户	模式
1	42,595.7s (11.8h)	144	295.8	369.5	t591	`tmp_cvd_t12`（house_ep_source_relate 反连接去重）🔴
2	2,873.8s	288	9.98	13.5	t591	GetGoldenSourceCommunityIDRepairStreets 聚合
3	2,344.1s	1	2344.1	—	backup	mysqldump `test.facebook_photo`（备份，单列）
4	1,548.5s	144	10.75	12.1	t591	`tmp_cvd_t1`（agent_customer_viewing JSON 展开）
5	1,516.9s	1	—	—	backup	mysqldump `t8891.t_item_modi_histories`（备份，单列）

backup 模式（mysqldump 全表导出）共 840 条 / 累计 8.98h，条数与近期常规量级一致（未现环比翻倍），按规则单独标注、不做深度分析。

3.3 触发深度分析的模式详情

P1 🔴 tmp_cvd_t12 — t591_new.house_ep_source_relate 反连接去重（144 次 / 累计 11.8h / 单次最高 369.5s）

现有索引：PRIMARY(id)、idx_post_id_type(type,post_id)、idx_out_id、idx_ep_source_id(ep_source_id)、idx_type_ep_score_post(type,ep_source_id,score,post_id)
EXPLAIN（实测）：外表 a 走 idx_type_ep_score_post 仅用到第 1 列 type，rows_examined_per_scan=278,482、query_cost=56,240；相关子查询 b 走 (type,ep_source_id) 前缀、rows≈2——子查询本身有索引，但外表 27.8 万行 × 每行一次相关子查询探测，且任务每 10 分钟整点跑一次（全天 144 次），这是累计 11.8h 的根因。
根因：算法复杂度 O(N×探测) 的 NOT EXISTS 逐行反连接，高频定时执行；不是"缺单列索引"，而是逐行去重写法 + 调度过密。
建议：

改写为窗口函数一次去重：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——idx_type_ep_score_post(type,ep_source_id,score,post_id) 是完美覆盖索引，可全程索引内完成（MySQL 8.0）；
或降频：数据日变更量有限时改为每小时/每 6 小时一次，累计耗时可降 90%+；
若版本不支持窗口函数，可用 GROUP BY ep_source_id + MAX(CONCAT(score,post_id)) 技巧等价替换。

P2 GetGoldenSourceCommunityIDRepairStreets — golden_source 三表聚合（288 次 / 累计 47.9min / 平均 9.98s）

现有索引（t591_estate_data.golden_source）：idx_comm_type_street(community_id,type,street_id,community_bid)、idx_street_id 等
EXPLAIN（实测）：gs 走 idx_comm_type_street range，rows_examined_per_scan=4,285,534、rows_produced=1,928,490、data_read_per_join=4G；cb/c 为 eq_ref。WHERE 条件 community_id=0 落在索引首列的"零值"区间，只能 range 扫 428 万行再过滤，且 LIMIT 5 仍需先完成全部分组。
根因：过滤条件选择度差（community_id=0 是大头），GROUP BY street_id 无法利用该索引顺序，每次都要扫 4G 索引数据；任务每 5 分钟一次（288 次/天）。
建议：

新增部分场景索引（低选择性等值列放前面）：ALTER TABLE t591_estate_data.golden_source ADD INDEX idx_type_comm0_street (type, community_id, street_id, community_bid)——type=1 AND community_id=0 等值前缀 + street_id 可支持分组，扫描量可从 428 万降至实际命中行数（预计 1~2 个数量级下降）；
结果短期不变（修复街道映射的统计），建议加 5~10 分钟应用层缓存或改为定时物化表。

P3 tmp_cvd_t1 — agent_customer_viewing JSON 展开（144 次 / 累计 25.8min）

EXPLAIN：主表 range 扫 880 行（表本身不大），慢点在 JSON_EXTRACT + 数字辅助表 n 展开多目标行的 CPU 计算，单次 ~10.7s。
根因：JSON 逐元素展开计算密集，非索引问题。
建议：任务级合并——该脚本与 tmp_cvd_t12/t14 同属一个批处理，随 P1 降频一并处理即可；单条 SQL 无需加索引。

P4 tmp_cvd_t14 — house_source_ep_build_relate 反连接去重（144 次 / 累计 5.8min / 平均 2.4s）

现有索引：仅 idx_ep_source_id(实际为 ep_build_id)、idx_out_id、idx_source_id、idx_relate_id
EXPLAIN（实测）：外表 type=ALL 全表扫 228,162 行，相关子查询 b 可走 idx_ep_build_id（rows≈1）。
根因：外表无可用过滤索引导致全表扫，但子查询探测便宜，总量尚可控。
建议：与 P1 同构，新增覆盖索引 (ep_build_id, score, source_id) 使外表与子查询都走索引；同样建议随批处理降频。

其他未触发但值得关注：SHOW ENGINE INNODB STATUS（696 条，监控采集，jmysql 用户，单条 ~1.5s 属正常开销）；commit（98 条 547s，来自 airflow/eagle/sonic，为大事务提交，建议排查上游写入批量）；news_ai 两类 SELECT（94/90 条，单条 1~3s，暂未达阈值）。

4. 逐条优化建议（按收益排序）

🔴 重写 tmp_cvd_t12 去重 SQL 为窗口函数 / 降频批任务（收益：-11.8h/天，非备份慢耗时的 78%）——见 P1。
golden_source 加索引 idx_type_comm0_street(type, community_id, street_id, community_bid)（收益：单次 10s → 预计 <1s，-47min/天）——见 P2。
批处理任务整体降频（tmp_cvd_t1/t12/t14 全天各 144 次、每 10 分钟一次，改为每小时可再省 80%+）。
house_source_ep_build_relate 加索引 (ep_build_id, score, source_id)——见 P4。
排查 airflow/eagle/sonic 的大事务提交（98 次 commit 平均 5.6s）。
backup 导出（Top10 全部）为正常行为，无需处理；若备份窗口影响业务，可考虑限速（mysqldump --max-allowed-packet/throttle）或改物理备份。

5. 数据来源与生成时间

数据：ES mysql_slow-2026.09.22~2026.09.23（@timestamp ∈ [2026-09-22T16:00:00Z, 2026-09-23T16:00:00Z)），MCP addcn（http://192.168.8.75:8200/mcp）es_slow_logs(top=10, env=staging) + es_search(size=5000，全量 4,218 条一次性拉齐，未超一页)。
分析：MCP connect / describe_schema / explain / disconnect（staging/tw591、staging/8891），全部只读。
指纹归一化：字符串/数字/IN 列表 → ?，保留库表与 SQL 骨架。
生成时间：2026-09-24（Asia/Shanghai），自动化脚本 outputs/slow_report_20260923_run.py / _phase2.py。