MySQL 慢查询日报 2026-09-10
统计口径：2026-09-10 00:00:00 ~ 23:59:59（Asia/Shanghai），环境 staging。
数据来源：ES 慢日志索引（经 MCP es_slow_logs / es_search，按 @timestamp UTC 换算），MySQL 侧全程只读（connect / describe_schema / explain / disconnect）。
生成时间：2026-09-11 10:0x CST ｜ 采集脚本：.agents/scripts/slow_report_daily.py（补充分析脚本见文末说明）。
一、统计概览
| 指标 | 值 |
|---|
| 统计时间范围 | 2026-09-10 00:00 ~ 2026-09-11 00:00 (+08:00)，未触发前日回退 |
| Top10 慢查询总耗时 | 约 10,234 s（≈ 2h50m） |
| 高频模式拉取文档数 | 5,115 条（es_search 单页 5,000 + 翻页，未超 2 万上限） |
| 指纹去重后模式数 | 见 JSON slow_report_20260910.json |
| 触发深度分析的非备份模式 | 8 个 |
| 数据异常 | 无（pattern 聚合无错误） |
总体结论：
- Top10 全部是
backup 用户的 mysqldump 全表导出（SELECT /*!40001 SQL_NO_CACHE */ *），无业务 SQL 进单条 Top10，属备份窗口正常行为，不需优化但建议错峰/限速。
- 真正值得关注的是高频业务模式：
t591 库的 tmp_cvd 系列临时表批处理（144 次/天、单条最高 294s，累计 42,406s ≈ 11.8 小时），根因是 house_source_ep_build_relate 缺复合索引导致全表扫描 + 相关子查询；tw8591/duyo 库一批精确卡在 300s 的 UPDATE/INSERT，是 innodb_lock_wait_timeout 锁等待超时，需排查长事务持锁；telescope_entries（Laravel Telescope）批量 INSERT 累计 14,347s，建议调低采样率。
二、Top10 慢查询明细
| # | 耗时(s) | 用户 | 实例(server_host → alias) | 库.表 | 扫描/返回行 | 慢因 |
|---|
| 1 | 2157.3 | backup | LAN_addcn_117 → staging/tw591 | test.facebook_photo | 101,727 / 101,727 | mysqldump 全表导出，大结果集传输 |
| 2 | 1343.8 | backup | LAN_addcn_84 → staging/8891 | t8891.t_item_modi_histories | 5,693,964 / 5,693,964 | mysqldump 全表导出（570 万行大表） |
| 3 | 1206.8 | backup | LAN_addcn_27 → staging/tw8591 | t8_game.t8_embeddings_cache | 79,835 / 79,835 | mysqldump 全表导出（含 JSON 向量宽行） |
| 4 | 1075.3 | backup | LAN_addcn_117 → staging/tw591 | t591_transcription.land_shape_coordinates | 15,616,508 / 15,616,508 | mysqldump 全表导出（1,562 万行大表） |
| 5 | 842.0 | backup | LAN_addcn_27 → staging/tw8591 | game.t8_embeddings_cache | 55,291 / 55,291 | mysqldump 全表导出（含 JSON 向量宽行） |
| 6 | 802.4 | backup | LAN_addcn_84 → staging/8891 | lighthouse.runs | 7,753 / 7,753 | mysqldump 全表导出 |
| 7 | 789.6 | backup | LAN_addcn_117 → staging/tw591 | t591_new.fetch_data_item | 398,940 / 398,940 | mysqldump 全表导出 |
| 8 | 713.5 | backup | LAN_addcn_84 → staging/8891 | t8891.t_sele_item_infos | 3,290,762 / 3,290,762 | mysqldump 全表导出（329 万行大表） |
| 9 | 703.4 | backup | LAN_addcn_117 → staging/tw591 | t591_estate_data.rental_market_raw | 48,006 / 48,006 | mysqldump 全表导出 |
| 10 | 600.0 | backup | LAN_addcn_117 → staging/tw591 | t591_bak.market_price_origin | 6,243,332 / 6,243,332 | mysqldump 全表导出（624 万行大表） |
Top10 说明：10 条全部 EXPLAIN type=ALL 属预期（无 WHERE 全表读取）；rows_examined == rows_sent、无锁等待，均判定为备份大结果集传输，非缺索引问题。test/t591_bak 等备份/测试库进入慢日志，建议评估是否仍需每日全量 dump。
三、高频慢查询模式（频次维度）
拉取 mysql_slow-* 全量 5,115 条，SQL 指纹归一化（字符串/数字/IN 列表 → ?）后聚合。
3.1 按条数 Top5
| # | 条数 | 平均(s) | 最大(s) | 累计(s) | 用户 | server | 指纹（截断） | 备注 |
|---|
| 1 | 1016 | 1.51 | 2.92 | 1533.9 | backup,jmysql | 117/37/40/40_3308/81 | SHOW ENGINE INNODB STATUS; | 🗄️ backup/监控模式，不深挖 |
| 2 | 288 | 9.06 | 21.01 | 2609.3 | t591 | LAN_addcn_117 | GetGoldenSourceCommunityIDRepairStreets 聚合查询 | ⚠️ 深度分析① |
| 3 | 144 | 10.48 | — | 1508.4 | t591 | LAN_addcn_117 | CREATE TEMPORARY TABLE tmp_cvd_t1 AS ... | 同 tmp_cvd 批处理族 |
| 4 | 144 | 294.48 | — | 42405.6 | t591 | LAN_addcn_117 | CREATE TEMPORARY TABLE tmp_cvd_t12 AS ... | 🔴 深度分析② |
| 5 | 144 | 2.05 | 5.22 | 295.0 | t591 | LAN_addcn_117 | CREATE TEMPORARY TABLE tmp_cvd_t14 AS ... | ⚠️ 深度分析③ |
3.2 按累计耗时 Top5
| # | 累计(s) | 条数 | 平均(s) | 用户 | server | 指纹（截断） | 备注 |
|---|
| 1 | 42405.6 | 144 | 294.48 | t591 | LAN_addcn_117 | CREATE TEMPORARY TABLE tmp_cvd_t12 AS SELECT ... house_ep_source... | 🔴 深度分析② |
| 2 | 14346.8 | 75 | 191.29 | a8591 | LAN_addcn_27 | INSERT INTO telescope_entries (...,content,...) VALUES | 🔴 深度分析④ |
| 3 | 6900.0 | 23 | 300.00 | a8591 | LAN_addcn_27 | SELECT ... dy_aigc_crawler_runs WHERE status IN(...) ORDER BY id LIMIT | 卡 300s 超时阈值 |
| 4 | 6300.0 | 21 | 300.00 | a8591 | LAN_addcn_27 | INSERT INTO t8_telescope_entries ... | 卡 300s 超时阈值 |
| 5 | 6174.6 | 26 | 237.48 | a8591 | LAN_addcn_27 | INSERT INTO telescope_entries ... | 同④ |
触发深度分析（条数>100 或 累计>30min，非备份）的模式共 8 个，详见下节。
四、深度分析（触发规则的模式）
① GetGoldenSourceCommunityIDRepairStreets（288 次，avg 9.06s，累计 43min）— 慢因：大范围索引扫描（近似缺索引）
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
- 表：
t591_estate_data.golden_source（现索引含 idx_comm_type_street(community_id,type,street_id,community_bid)）。
- EXPLAIN：gs 走
idx_comm_type_street range，但 rows_examined_per_scan ≈ 428 万；cb/c 为 eq_ref。
- 根因：
community_id = 0 是"待修复"标记值，命中索引前缀后仍需扫描该分区下 428 万行，再 JOIN 聚合，每 5 分钟定时跑一次（288 次/天 ≈ 每 5 分钟）。
- 建议：
- 修复是一次性数据迁移场景，修完后
community_id=0 行应趋近 0；先确认存量待修复行数，若已不多应排查为何任务空转仍全量扫描；
- 加专用窄索引让待修复行直接定位：
ALTER TABLE t591_estate_data.golden_source ADD INDEX idx_repair_pending (community_id, type, community_bid, street_id);（或改造任务：先 SELECT community_bid ... WHERE community_id=0 AND type=1 LIMIT 取 ID 列表再聚合）；
- 降低执行频率或加"无待修复数据即退出"短路条件。
② tmp_cvd_t12 临时表（144 次，avg 294.5s，累计 11.8 小时）— 慢因：缺索引 + 相关子查询，全表扫描🔴 当日最大耗时模式
- 指纹：
CREATE TEMPORARY TABLE tmp_cvd_t12 AS SELECT a.ep_source_id, a.post_id FROM t591_new.house_ep_source...（每日 144 次、几乎每次都打到 294s+，疑受 max_execution_time/慢日志水位影响）。
- 同族
tmp_cvd_t14 已做 EXPLAIN（同一基表 house_source_ep_build_relate）：
type=ALL, rows_examined_per_scan=228,162, dependent subquery (NOT EXISTS)
- 表
t591_new.house_source_ep_build_relate 现有索引：idx_ep_source_id(ep_build_id)、idx_out_id、idx_source_id、idx_relate_id。
- 根因：t14 取每个
ep_build_id 得分最高的 source（NOT EXISTS b.score>a.score OR (=, source_id>)），外表全表扫描 22.8 万行 × 相关子查询；t12 同理走 house_ep_source 关联。该批处理每天 00:00 起每 10 分钟一轮（144 次）。
- 建议：
ALTER TABLE t591_new.house_source_ep_build_relate ADD INDEX idx_ep_score_source (ep_build_id, score DESC, source_id);（t14 场景），使子查询从"按 ep_build_id 回表过滤"变为索引范围直接命中；- t14 语义可用窗口函数一步完成（MySQL 8）：
ROW_NUMBER() OVER (PARTITION BY ep_build_id ORDER BY score DESC, source_id DESC)，避免相关子查询；
- 评估该批处理频率（10 分钟一轮 × 全量重建临时表），改为增量或事件驱动。
③ tmp_cvd_t14（144 次，avg 2.05s，累计 295s）— 同②根因，索引加上后同步受益。
④ telescope_entries 批量 INSERT（75+26+21 次，累计 ≈ 6.6 小时）— 慢因：锁等待 + 大 payload 写入
a8591 用户的 Laravel Telescope 监控写入，单条 content JSON 可达数百 KB；多条精确卡 300s（innodb_lock_wait_timeout），说明与同一批处理/清理任务存在行锁或间隙锁冲突。telescope_entries 在 tw8591 上存在于多个库（describe_schema 返回"存在于多个库"，属应用分库）。- 建议：
- Telescope 生产/staging 调低采样：
TELESCOPE_ENABLED=false 或 entry 类型白名单 + watchers 收窄；
- 检查
telescope:prune 清理任务是否与写入高峰重叠造成锁冲突；
content 大字段写入改 batch + 压缩（Telescope 配置 chunk）。
⑤ duyo 库 300s 精确超时组（锁等待确认，非缺索引）
以下模式全部精确等于 300.00s，且 EXPLAIN 证明 WHERE 条件均走索引，判定为 innodb_lock_wait_timeout=300 锁等待超时，指向长事务持锁而非索引问题：
| 模式 | 条数 | 累计(s) | EXPLAIN（代表性条件） | 索引 |
|---|
UPDATE dy_aigc_news_raw_text_jobs SET status='failed' ... WHERE status='fetching' AND lease_until<... AND attempt_count>=max_attempts | 16 | 4800 | ref, key=idx_raw_text_claim, rows=1 | idx_raw_text_claim(status,available_at,id)、idx_raw_text_lease(status,lease_until) |
UPDATE dy_login_sessions ... WHERE session_id=? | 6 | 1800 | uk_session_id 唯一键命中 | uk_session_id(session_id) |
UPDATE dy_user_logins ... WHERE user_id=? | 12 | 3600 | const, key=user_id, rows=1 | user_id |
UPDATE dy_notification_tasks SET locked_by=... WHERE status IN(1,2,3) ... ORDER BY next_execute_at LIMIT 100 | 7 | 2100 | range, key=idx_status_execute, rows=3 | idx_status_execute(status,next_execute_at,locked_until) |
SELECT * FROM dy_aigc_crawler_runs WHERE status IN(...) ORDER BY id ASC LIMIT | 23 | 6900 | — | 同族任务队列 |
- 根因：duyo 的任务队列（aigc 抓取/通知）在 01:00 前后集中运行，worker 抢锁（
locked_by/locked_until）与 lease 回收 UPDATE 撞同一批行，持锁方有 300s 级长事务/慢查询（很可能是 ④ 的 telescope 大事务或抓取批处理），等待方全部超时。
- 建议：
- 在 tw8591 排查 01:00 时段长事务：
SELECT * FROM information_schema.innodb_trx WHERE trx_started < NOW() - INTERVAL 60 SECOND;（人工操作，本报告只读未执行）；
- 任务队列 UPDATE 改为原子抢占避免多 worker 扫同一批：
... WHERE status IN (...) AND (locked_until IS NULL OR locked_until<=...) LIMIT 100 FOR UPDATE SKIP LOCKED（MySQL 8.0.21+）；
- lease 回收（① 中 aigc_news_raw_text_jobs 的 UPDATE）加
idx_raw_text_lease 更贴合的过滤顺序已存在，问题不在索引；考虑把 lease 回收频率调低、或事务拆小。
⑥ # administrator command: Prepare;（33 次，avg 102s，累计 56min）
- 慢日志把 Prepare 阶段计入，实际慢的是对应预处理语句的执行/锁等待（与⑤同时段），随⑤④解决应消失，不单独处理。
未触发深度分析
SHOW ENGINE INNODB STATUS;（1016 次，users=backup/jmysql）：监控/备份脚本探测，标注为 🗄️ 备份模式，条数与既往持平（未见翻倍），不深挖。- 其余 backup 模式（mysqldump SELECT 全表导出）：见 Top10，单条标注，不深挖。
五、逐条优化建议汇总
| 优先级 | 对象 | 动作 |
|---|
| P0 | t591_new.house_source_ep_build_relate | 加索引 (ep_build_id, score, source_id)；tmp_cvd 批处理改窗口函数 / 增量。预计消除当日 11.8h 累计慢耗时的主因 |
| P0 | tw8591 duyo 任务队列（01:00 时段） | 排查长事务；队列抢占改 FOR UPDATE SKIP LOCKED；levée 回收降频 |
| P1 | Laravel Telescope（a8591） | 调低采样/prune 错峰；消除 6.6h 累计 INSERT 慢 |
| P1 | t591_estate_data.golden_source 修复任务 | 加窄索引或先查待修复行数短路；任务降频 |
| P2 | mysqldump 备份策略 | --single-transaction --where 拆分大表 / 限速 --max-allowed-packet+throttle；test、t591_bak 等备份/测试库评估停止每日全量 dump |
六、数据来源与生成时间
- ES 慢日志：MCP
es_slow_logs（Top10, env=staging）与 es_search（mysql_slow-*，size 5000 + search_after，共 5,115 条），时间过滤 @timestamp ∈ [2026-09-10T00:00:00+08:00, 2026-09-11T00:00:00+08:00)。
- MySQL 只读分析：MCP
connect → describe_schema → explain → disconnect（alias：staging/tw591、staging/tw8591、staging/8891）。
- 原始数据：
outputs/slow_report_20260910.json、outputs/slow_raw_20260910.json、outputs/slow_report_20260910_supp.json（补充 explain）。
- 生成时间：2026-09-11 10:05 (Asia/Shanghai)。全流程未执行任何写库、kill、配置修改或 git 提交。