MySQL 慢查询日报 2026-09-08

统计概览

⚠️ 采集链路说明：MCP 服务的 es_slow_logs / es_search 工具当日返回 ES 401（MCP 侧 ES API key 失效），已改用本地 es-query 只读直连 ES 拉取慢日志；MySQL 结构/执行计划仍全程通过 MCP 只读工具（connect → describe_schema → explain → disconnect），未执行任何写操作。

当日画像：Top10 中 9 条为 backup 用户的 mysqldump 全表导出（大结果集传输，非业务故障），1 条（#6）为业务侧 SELECT * FROM price_snapshot 全表导出式查询；真正的业务风险在高频模式——tw591 主库（192.168.8.117）tmp_cvd_t12 去重 SQL 全天 144 次、累计 6.49 h，GetGoldenSourceCommunityIDRepairStreets 288 次、累计 3.24 h；tw8591（192.168.8.27）上 Telescope 长事务写入与 FOR UPDATE 领单精确卡在 300 s（疑似 innodb_lock_wait_timeout），锁等待特征明显。

Top10 明细（按单条耗时）

Top10 锁等待占比均 <0.01%（Lock_time ≈ 0.0002~0.07 s），无锁等待型慢查；#1 facebook_photo（10 万行 / 42.7 GB，单行 ~420 KB）建议核查是否存了原图 base64，备份窗口可考虑 --single-transaction 之外限流或排除该测试库。

高频慢查询模式（指纹归一化聚合，4,768 条）

按条数 Top5

按累计耗时 Top5

备份模式（user=backup，mysqldump 全表导出）已从上表剔除单独标注：全天 1,146 条、累计 10.15 h，Top10 中 9 条由其贡献，单条最慢 35.9 分钟；较前日（约 3,000+ 条）明显减少，属常规备份量级、无环比翻倍异常，不触发深度分析。

SHOW ENGINE INNODB STATUS（1,021 条）为 PMM/监控采集语句，属正常采集成本。

另有 # administrator command: Prepare 模式（55 次 × 71.1 s，累计 65 min）与 Telescope 批处理同源（Prepare 是批量写入的伴随命令），随 Telescope 问题一并处理。

触发深度分析的模式详情

① tmp_cvd_t12 —— 累计 6.49h，全日报最大损耗 ⚠️

• 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)))
• 频率：每 10 分钟 1 次（全天 144 次），单次 162 s。
• EXPLAIN（内层 SELECT，tw591 实例）：外表 a 走覆盖索引 idx_type_ep_score_post(type)（ref，仅用到前缀 type），单次扫描 316,562 行，每行触发一次相关子查询探测同索引；query_cost 63,930，data_read 36 MB/JOIN。
• 表索引：house_ep_source_relate 已有 (type, post_id)、(type, ep_source_id, score, post_id) 等索引。
• 根因：不是缺索引——是去重反连接被优化器按相关子查询逐行执行（31.6 万行 × 每行一次索引探测），且任务全量重算、无增量。type=2 分量占该表比重过大，索引区分度失效。
• 建议：

1. 改写为一次性聚合派生表：JOIN (SELECT ep_source_id, MAX(CONCAT(LPAD(score,10,'0'), post_id)) … GROUP BY ep_source_id) 或窗口函数 ROW_NUMBER() OVER (PARTITION BY ep_source_id ORDER BY score DESC, post_id DESC) = 1，把 31.6 万次探测变为一次索引扫描 + 分组；
2. 增加 updated_at 增量水位，10 分钟窗口只处理增量数据，避免全天 144 次全量重算；
3. 结果落常规表加 TTL，供下游 tmp_cvd_t14 等复用。

② GetGoldenSourceCommunityIDRepairStreets —— 累计 3.24h ⚠️

• SQL：SELECT gs.street_id, COUNT(*) FROM t591_estate_data.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
• 频率：每 5 分钟 1 次（全天 288 次），单次 40.55 s（09-07 为 61.46 s/次，覆盖索引生效后已降约 34%）。
• EXPLAIN（tw591 实例）：gs 走覆盖索引 idx_comm_type_street(community_id, type, street_id, community_bid) range 扫描（using_index=true，无回表），rows_examined 4,285,534、产出 192 万行；随后 cb/c 对 192 万行逐行 eq_ref 主键点查（cb 侧 data_read ≈ 2G），最后 GROUP BY 聚合。
• 根因：索引已最优（community_bid 覆盖列已生效），瓶颈是数据量——community_id=0 AND type=1 的待修复存量约 192 万行，JOIN cb/c 的唯一目的是剔除已删除社区，却让每行付出两次主键点查；任何索引都无法减少必须聚合的行数。
• 建议：

1. 改写为先聚合后 JOIN：用小结果集反连接剔除已删除社区——WHERE gs.community_bid NOT IN (SELECT cb.id FROM … cb JOIN … c WHERE c.deleted_at IS NOT NULL)，192 万次点查 → 一次纯索引聚合 + 小反连接，预计 40 s → 1~3 s；
2. 结果缓存/物化：该统计每 5 分钟跑一次但存量变化远慢于调度，改为 15~30 分钟一次或物化成 golden_source_street_stats 汇总表，288 次→几十次；
3. 收敛 community_id=0 的 192 万行待修复存量，修复脚本吃完后查询自然变快；
4. 注意：prod-591/master 上该表尚无 idx_comm_type_street（生产为真全表扫描），如该 SQL 也跑生产需补建。

③ Telescope 长事务写入（telescope_entries / t8_telescope_entries）—— 累计约 6.5h ⚠️

• SQL：INSERT INTO telescope_entries (batch_id, content, created_at, family_hash, type, uuid) VALUES (…, '{超长 JSON}', …)（同型多指纹：42 次×265 s、21 次×268 s、10 次×257 s；t8 变体 23 次×300.00 s）。
• 表结构（a8591.telescope_entries）：索引 uuid/batch_id/family_hash/created_at 等 6 个二级索引，content 为 longtext。
• 根因：单条 INSERT 耗时 250~300 s 且 300.00 精确整秒，指向 innodb_lock_wait_timeout=300 到期——Telescope 的 telescope:prune（每小时整点，样本可见 01:00:02 调度）大批 DELETE 与写入互锁，prune 长事务持 gap/next-key 锁，业务 INSERT 等锁超时。
• 建议：

1. staging 环境直接关闭 Telescope（TELESCOPE_ENABLED=false）或采样模式，一次性消除全天 ~110 次慢写；
2. 保留则把 prune 改为小批量分片删除（DELETE … LIMIT 1000 循环）+ 避开整点业务高峰，缩小锁范围；
3. content 落库前截断/压缩，减小行宽与 undo 压力。

④ dy_aigc_crawler_runs … FOR UPDATE —— 18 次 × 300.00s，锁等待 ⚠️

• SQL：SELECT * FROM dy_aigc_crawler_runs WHERE status IN ('waiting','retry_waiting') AND available_at <= … ORDER BY id ASC LIMIT 1 FOR UPDATE（duyo 库，tw8591）。
• EXPLAIN：走 idx_claim(status, next_retry_at, created_at, id)，rows_examined=2——查询本身毫秒级，慢因不是执行计划而是锁：18 次全部精确 300.00 s，多 worker 抢同一条待领记录，FOR UPDATE 互斥直至锁等待超时。
• 建议：

1. 领单改乐观抢占：UPDATE dy_aigc_crawler_runs SET status='running', worker_id=? WHERE status IN ('waiting','retry_waiting') ORDER BY id LIMIT 1 先到先得、无长持锁，或 MySQL 8 用 FOR UPDATE SKIP LOCKED；
2. 降低 worker 并发数（当前争抢强度下 18 次超时说明 worker 数 > 待领任务数）；
3. 会话级调低 innodb_lock_wait_timeout 并加重试，避免 300 s 长占连接。

逐条优化建议汇总

数据来源与生成时间

• 数据来源：Elasticsearch mysql_slow-*（@timestamp 过滤 2026-09-08T00:00:00+08:00 ~ 2026-09-09T00:00:00+08:00，共 4,768 条，es-query 只读直连）；MySQL 结构与执行计划经 MCP 只读工具（connect / describe_schema / explain / find_instance / search_schema / disconnect，实例 staging/tw591、staging/tw8591 等），全程未执行任何写库、kill 或配置变更。
• 采集脚本：.agents/scripts/slow_report_20260908_run.py，中间数据 outputs/slow_report_20260908.json。
• 报告生成时间：2026-09-09 10:0x（Asia/Shanghai）。