MySQL 慢查询日报 2026-09-07
统计概览
| 项目 | 值 |
|---|
| 统计范围 | 2026-09-07 00:00:00 ~ 23:59:59（Asia/Shanghai，未触发前日回退） |
| 环境 | staging |
| 慢日志条数（ES 拉取，mysql_slow-*） | 5,113 条（1 页 + 翻页） |
| Top10 单条最慢 | 2,151.94 s（backup 全表导出 test.facebook_photo） |
| 非备份模式最大累计耗时 | 17,699 s ≈ 4.91 h（GetGoldenSourceCommunityIDRepairStreets，288 次 × 61.46 s） |
| 数据来源 | ES mysql_slow-*（@timestamp，UTC+8→UTC 换算）+ MCP 只读 MySQL（describe_schema / explain） |
当日画像：Top10 全部为 backup 用户的 mysqldump 全表导出（SQL_NO_CACHE SELECT *），属大结果集传输，非业务故障；真正的业务风险集中在高频模式——tw591 主库（192.168.8.117）上一条 61s 的黄金源统计 SQL 全天跑了 288 次、累计近 5 小时。
Top10 明细（按单条耗时）
| # | 耗时(s) | 库.表 | 行数 sent/examined | user | 慢因分类 |
|---|
| 1 | 2151.94 | test.facebook_photo | 101,727 / 101,727 | backup | 备份导出：大结果集传输（EXPLAIN ALL 全表扫，宽行 SELECT *） |
| 2 | 1490.20 | t8891.t_item_modi_histories | 5,693,964 / 5,693,964 | backup | 备份导出：大结果集传输（569 万行全表扫） |
| 3 | 1129.09 | t8_game.t8_embeddings_cache | 79,835 / 79,835 | backup | 备份导出：大结果集传输（含 embedding 宽字段） |
| 4 | 1070.12 | t591_transcription.land_shape_coordinates | 15,616,508 / 15,616,508 | backup | 备份导出：大结果集传输（1,561 万行） |
| 5 | 971.56 | t8891.t_sele_item_infos | 3,290,762 / 3,290,762 | backup | 备份导出：大结果集传输 |
| 6 | 795.04 | t591_new.fetch_data_item | 398,940 / 398,940 | backup | 备份导出：大结果集传输 |
| 7 | 784.44 | game.t8_embeddings_cache | 55,291 / 55,291 | backup | 备份导出：大结果集传输 |
| 8 | 753.42 | lighthouse.runs | 7,753 / 7,753 | backup | 备份导出：大结果集传输 |
| 9 | 731.91 | t591_estate_data.rental_market_raw | 48,006 / 48,006 | backup | 备份导出：大结果集传输 |
| 10 | 611.28 | t591_bak.market_price_origin | 6,243,332 / 6,243,332 | backup | 备份导出：大结果集传输 |
Top10 锁等待占比均 <0.1%（Lock_time ≈ 0.0002~0.005 s），无锁等待型慢查。
高频慢查询模式（指纹归一化聚合，5,113 条）
按条数 Top5
| # | 模式（指纹摘要） | 条数 | 平均(s) | 最大(s) | 累计 | server | user |
|---|
| 1 | SHOW ENGINE INNODB STATUS | 985 | 1.57 | — | 25.8 min | 117/27_3307/40/40_3308/46 | jmysql |
| 2 | SELECT mp.* … FROM market_price mp …（宽列聚合查询） | 454 | 5.83 | — | 44.1 min | LAN_addcn_117 | t591 |
| 3 | GetGoldenSourceCommunityIDRepairStreets（golden_source 3 表 JOIN + GROUP BY） | 288 | 61.46 | — | 4.91 h | LAN_addcn_117 | t591 |
| 4 | CREATE TEMPORARY TABLE tmp_cvd_t1 AS SELECT …（JSON_EXTRACT 展开 viewing_targets） | 144 | 10.53 | — | 25.3 min | LAN_addcn_117 | t591 |
| 5 | CREATE TEMPORARY TABLE tmp_cvd_t12 AS SELECT … house_ep_source_relate 反连接去重 | 144 | 71.43 | — | 2.85 h | LAN_addcn_117 | t591 |
按累计耗时 Top5
| # | 模式 | 条数 | 平均(s) | 累计 | server | user |
|---|
| 1 | GetGoldenSourceCommunityIDRepairStreets | 288 | 61.46 | 4.91 h | LAN_addcn_117 | t591 |
| 2 | INSERT INTO telescope_entries … VALUES（Laravel Telescope 批量写入，longtext content） | 68 | 240.01 | 4.53 h | LAN_addcn_27 | a8591 |
| 3 | tmp_cvd_t12（house_ep_source_relate NOT EXISTS 去重） | 144 | 71.43 | 2.85 h | LAN_addcn_117 | t591 |
| 4 | INSERT INTO telescope_entries … VALUES（不同指纹变体） | 22 | 251.04 | 1.53 h | LAN_addcn_27 | a8591 |
| 5 | SELECT * FROM dy_aigc_crawler_runs … FOR UPDATE | 18 | 300.00 | 1.50 h | LAN_addcn_27 | a8591 |
备份模式（user=backup，mysqldump 全表导出）已从上表剔除单独标注：全天共约 3,000+ 条、Top10 全部由其贡献，单条最慢 35.9 分钟，条数与耗时均在常规备份量级（未现环比翻倍异常），不触发深度分析。
SHOW ENGINE INNODB STATUS（985 条）为监控采集语句，属正常采集成本。
触发深度分析的模式详情
① GetGoldenSourceCommunityIDRepairStreets —— 累计 4.91h，全日报最大损耗 ⚠️
SELECT gs.street_id, COUNT(*) AS golden_source_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;
- EXPLAIN（staging/tw591，t591_estate_data.golden_source）：驱动表
gs 走 idx_street_id range 扫描，street_id != 0 条件几乎不过滤 → rows_examined_per_scan = 4,285,534，filtered 仅 4.50%，数据读取量 423M/次；后两表 eq_ref 无问题。
- 根因：
golden_source 上没有覆盖 type + community_id + community_bid + street_id 的组合索引，优化器只能用 street_id != 0 这种几乎无选择性的 range，428 万行逐行回表过滤。
- 建议：为
t591_estate_data.golden_source 增加组合索引 ALTER TABLE golden_source ADD INDEX idx_type_cid_cbid_street (type, community_id, community_bid, street_id)（等值列在前、street_id 兼容 GROUP BY）。该 SQL 带 LIMIT 5 且 288 次/天（约 5 分钟一次的定时任务），索引落地后预计单次降至亚秒级，全天节省约 4.5 小时扫描。
② telescope_entries 批量 INSERT —— 累计 4.53h + 1.53h
INSERT INTO `telescope_entries` (`batch_id`,`content`,`created_at`,`family_hash`,`type`,`uuid`)
VALUES (…多行批量…);
- 表结构（a8591.telescope_entries）：
content longtext NOT NULL，AUTO_INCREMENT 已到 14,774,881；索引含 uuid 唯一键 + batch_id/family_hash/created_at 等 6 个二级索引。
- 根因：Laravel Telescope 调试组件把请求/异常快照（含大 JSON，单条可达数百 KB）批量写入
longtext，每次触发 68~144 个值组、批量 240s+；这是大行写入 + 二级索引维护型慢，不是缺索引（写入本身无索引可走）。staging 环境已无保留 1400 万条调试数据的必要。
- 建议：staging 关闭或降采样 Telescope（
.env 中 TELESCOPE_ENABLED=false 或队列 prune）；执行 php artisan telescope:prune 清理历史数据（业务低峰，只删不锁表可分批）；若需保留，把 content 压缩后再写。同类还有 dy_telescope_entries（7 条×300s）、t8_telescope_entries（11 条×300s）。
③ dy_aigc_crawler_runs SELECT … FOR UPDATE —— 平均精确 300.00s（锁等待）
SELECT * FROM `dy_aigc_crawler_runs`
WHERE status IN ('waiting','retry_waiting') AND available_at <= '…'
ORDER BY id ASC LIMIT 1 FOR UPDATE;
- EXPLAIN（duyo.dy_aigc_crawler_runs）：
idx_claim(status,next_retry_at,created_at,id) range，rows≈2，执行计划本身很快（cost 5.48）；但 18 条平均耗时精确等于 300.00s = innodb_lock_wait_timeout 默认值。
- 根因：典型锁等待——队列 worker
FOR UPDATE 领取任务时，行已被长事务（见上：Telescope 长写入占用连接/事务）或其他 worker 持有，等到超时阈值整秒放弃。另有 7×300s、11×300s 的 telescope 写入同样卡在 300s，互相印证 tw8591 主库存在长事务持锁。
- 建议：排查 192.168.8.27 长事务（
information_schema.innodb_trx / show_lock_waits）；给领队查询改用 WHERE … AND worker_id='' LIMIT 1 FOR UPDATE SKIP LOCKED（MySQL 8.0+，该实例为 8.0）可彻底消除排队；同时降低任务重试频率避免空转。
④ tmp_cvd_t12 / tmp_cvd_t1（CREATE TEMPORARY TABLE，各 144 次）
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)));
- EXPLAIN：外层
a 仅用 idx_post_id_type 的 type 前缀，rows_examined_per_scan = 323,724；相关子查询 b 走 idx_ep_source_id（每次 ref 查 3 行）但整条是 NOT EXISTS 反连接 + 相关子查询，32 万行×多次索引探测。
- 根因：
house_ep_source_relate 缺 (type, ep_source_id, score, post_id) 组合索引，反连接无法做索引下推的最优覆盖。
- 建议：
ALTER TABLE t591_new.house_ep_source_relate ADD INDEX idx_type_epid_score_post (type, ep_source_id, score, post_id)，外层与子查询均变覆盖索引，预计 71s → 秒级。tmp_cvd_t1（10.5s×144）是 JSON_EXTRACT 展开 viewing_targets 数组的固有成本，建议在写入侧落一列规范化明细表替代运行时 JSON 展开。
⑤ market_price 宽列查询（454 次 × 5.83s ≈ 44 min）
SELECT mp.id AS source_id, mp.serial_number, mp.trans_date, …(30+ 宽列) FROM market_price mp …
- EXPLAIN（代表性条件
community_id=）：走 idx_community_id ref，rows≈9，计划健康；慢在每行 30+ 列宽行传输（表含多个 decimal(20,4)/varchar 大列）。
- 建议：非缺索引问题。确认调用方是否真需要全部列；若用于列表展示，拆出精简视图或分页加
LIMIT；若为报表，建议走 tw591-slave 只读实例分流，避免 454 次/天都压主库 117。
逐条优化建议（按收益排序）
- 加索引（最高收益，预计省 ≈7.5h/天）：
t591_estate_data.golden_source(type, community_id, community_bid, street_id) → 模式① 4.91h；t591_new.house_ep_source_relate(type, ep_source_id, score, post_id) → 模式④ 2.85h。
- 治理 tw8591 长事务/锁等待：排查 192.168.8.27 的 innodb_trx；
FOR UPDATE 领队改 SKIP LOCKED；Telescope 停用/清数据（模式②③合计 ≈7.5h）。
- 业务查询分流：market_price 宽列报表查询 454 次/天改走 tw591-slave；评估是否可减列/分页。
- 备份窗口管理：Top10 全为 mysqldump 全表导出（单条最长 35.9 min），建议固定低峰窗口、大表（land_shape_coordinates 1,561 万行、t_sele_item_infos 329 万行）改用 xtrabackup/快照或
--where 分片，减少主库 SQL_NO_CACHE 全表扫描。
- 观察项：
# administrator command: Prepare 46 条 × 66.5s 为 prepared statement 通道上的等待透传，根因大概率同为上述长事务，索引与锁治理后复评。
数据来源与生成时间
- 慢日志：ES
mysql_slow-*（@timestamp ∈ [2026-09-07T00:00:00+08:00, 2026-09-07T16:00:00Z)），MCP es_slow_logs（top=10, env=staging）+ es_search search_after 翻页共 5,113 条。
- 表结构/执行计划：MCP 只读工具
connect / describe_schema / explain / disconnect（staging/tw591、staging/tw8591 等），全程未执行任何写库、kill 或配置变更。
- 生成时间：2026-09-08 10:0x（Asia/Shanghai）；原始数据：
outputs/slow_report_20260907.json。