| 项目 | 值 |
|---|---|
| 统计范围 | 2026-09-15 00:00:00 ~ 23:59:59（Asia/Shanghai，ES 查询按 UTC [09-14T16:00Z, 09-15T16:00Z)） |
| 环境 | staging |
| 慢日志文档数（es_search 拉取） | 4,707 条（单页 5000 内，无翻页） |
| Top10 门槛 | 单条 ≥ 685s |
| 慢因分布 | Top10 全部为 backup 用户 mysqldump 全表导出；高频模式集中在定时任务 CTAS、telescope 写入、锁等待超时 |
| 最大单条耗时 | 2,231.85s（test.facebook_photo 备份导出） |
全部 10 条均为 SELECT /*!40001 SQL_NO_CACHE */ * FROM 库.表;（mysqldump 全表导出，user=backup），分类统一为「大结果集传输（备份导出，SELECT * 宽行、rows_sent=rows_examined）」。
| # | 耗时(s) | 实例 | 库.表 | rows_sent | 慢因分类 |
|---|---|---|---|---|---|
| 1 | 2231.85 | staging/tw591 | test.facebook_photo | 101,727 | 备份导出·大结果集传输 |
| 2 | 1395.60 | staging/8891 | t8891.t_item_modi_histories | 5,693,964 | 备份导出·大结果集传输 |
| 3 | 1145.61 | staging/tw8591 | t8_game.t8_embeddings_cache | 79,835 | 备份导出·大结果集传输（含大字段） |
| 4 | 1115.80 | staging/tw591 | t591_transcription.land_shape_coordinates | 15,616,508 | 备份导出·大结果集传输（行数最大） |
| 5 | 935.75 | staging/tw591 | t591_new.fetch_data_item | 398,940 | 备份导出·大结果集传输 |
| 6 | 863.90 | staging/tw591 | t591_estate_data.rental_market_raw | 48,006 | 备份导出·大结果集传输 |
| 7 | 855.59 | staging/8891 | lighthouse.runs | 7,753 | 备份导出·大结果集传输 |
| 8 | 821.48 | staging/8891 | t8891.t_sele_item_infos | 3,290,762 | 备份导出·大结果集传输 |
| 9 | 810.37 | staging/tw8591 | game.t8_embeddings_cache | 55,291 | 备份导出·大结果集传输（含大字段） |
| 10 | 685.88 | staging/tw591 | t591_new.fetch_data | 27,022 | 备份导出·大结果集传输 |
Top10 全部来自例行备份（user=backup），非业务故障；但备份窗口的磁盘/IO 压力会放大同时段业务写入延迟（见第三节 telescope 插入模式）。
| # | 模式（指纹摘要） | 条数 | 平均(s) | 最大(s) | 累计 | user | server |
|---|---|---|---|---|---|---|---|
| 1 | SHOW ENGINE INNODB STATUS;（监控采集） | 1,055 | 1.53 | 3.33 | 26.9min | jmysql | 多台 |
| 2 | golden_source JOIN market_community(_building) 修复统计（GetGoldenSourceCommunityIDRepairStreets） | 288 | 9.04 | 11.51 | 43.4min | t591 | tw591(117) |
| 3 | CTAS tmp_cvd_t12：house_ep_source_relate 反连接去重 | 144 | 293.61 | 303.68 | 11.7h | t591 | tw591(117) |
| 4 | CTAS tmp_cvd_t1：agent_customer_viewing JSON 展开透视 | 144 | 10.51 | 12.69 | 25.2min | t591 | tw591(117) |
| 5 | CTAS tmp_cvd_t14：house_source_ep_build_relate 反连接 | 144 | 1.99 | 2.87 | 4.8min | t591 | tw591(117) |
| # | 模式（指纹摘要） | 条数 | 平均(s) | 累计 | user | server |
|---|---|---|---|---|---|---|
| 1 | CTAS tmp_cvd_t12：house_ep_source_relate 反连接去重 | 144 | 293.61 | 11.7h | t591 | tw591(117) |
| 2 | INSERT telescope_entries（多行 values，Laravel Telescope） | 85 | 222.06 | 5.2h | a8591 | tw8591(27) |
| 3 | INSERT t8_telescope_entries 单行（telescope:prune 定时） | 23 | 300.00 | 1.9h | a8591 | tw8591(27) |
| 4 | INSERT telescope_entries（另一多行批次指纹） | 28 | 237.94 | 1.9h | a8591 | tw8591(27) |
| 5 | SELECT ... FOR UPDATE 领取任务（dy_aigc_news_raw_text_jobs，status IN + available_at <= now） | 18 | 300.00 | 1.5h | a8591 | tw8591(27) |
backup 用户模式（mysqldump 导出，约 4,700 条中占比最高）按口径单独标注、不触发深度分析；本日各备份表导出条数与耗时无异常翻倍迹象。
代表 SQL（每 10 分钟执行一次的定时任务）：
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 t591_new.house_ep_source_relate 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)));表结构（~85 万行）：已有索引 idx_post_id_type(type,post_id)、idx_ep_source_id、idx_type_ep_score_post(type,ep_source_id,score,post_id)。
EXPLAIN：外层走 idx_type_ep_score_post 仅用到 type 前缀，rows_examined_per_scan=322,956（覆盖索引，using_index=true）；子查询为相关子查询（dependent，每次 2 行，索引命中良好）。
根因：反连接（取每个 ep_source_id 下 score/post_id 最大的一条）本质是对 type=2 的 ~32 万行做 O(N×log) 的逐行相关子查询判断，单次近 5 分钟，且任务每 10 分钟全量重算一遍 → 全天 11.7 小时数据库时间。索引已覆盖，属于计算模式问题而非缺索引。
建议：
ROW_NUMBER() OVER (PARTITION BY ep_source_id ORDER BY score DESC, post_id DESC) 取 rn=1，MySQL 8.0 可把 32 万行相关子查询降为单次索引扫描 + 排序，预期单次从 ~294s 降到秒级；idx_type_ep_score_post(type,ep_source_id,score,post_id) 已是窗口函数改写的理想索引，无需新增。现象：tw8591（192.168.8.27）上 INSERT INTO telescope_entries ...（content 为 longtext，含完整异常/命令 payload）平均 222~238s，多条精确卡在 300.00s —— 与 innodb_lock_wait_timeout 典型值 300 吻合，判定为锁等待超时（与同时段 tw8591 大表 mysqldump 备份的 IO/锁竞争叠加）。
建议：
TELESCOPE_ENABLED=false 或按 type 过滤），telescope:prune --hours=1 已在跑但写入量仍大；content longtext 无压缩、AUTO_INCREMENT 已到 1547 万，建议缩短 prune 周期/限流写入；代表 SQL：SELECT ... WHERE status IN (...) AND available_at <= ? ORDER BY id ASC LIMIT ? FOR UPDATE 与租约逾期回收 UPDATE。EXPLAIN 显示 idx_raw_text_claim(status,available_at,id) 命中良好（rows=1），不是缺索引；平均耗时精确 300.00s → 锁等待超时。任务表仅 ~900 行，属于工作线程数 > 可领任务数时的 FOR UPDATE 排队。
建议：领取任务加 SKIP LOCKED/NOWAIT（MySQL 8.0：LIMIT 1 FOR UPDATE SKIP LOCKED），避免 worker 空转排队占锁 300s。
SQL：SELECT sum(after_amount - before_amount) FROM h8_finance_account_logs WHERE user_id = 1010158 AND sub_account = 11;
表（~1,359 万行）：索引 asacca(user_id,sub_account,course,created_at)、idx_user_sub_account_id(user_id,sub_account,id DESC)。
EXPLAIN：仅用到 user_id 前缀（key_len=8），sub_account 走 ICP 回表过滤，rows_examined_per_scan=1,099,006。
根因：类型不匹配——sub_account 是 char(2)，SQL 传的是整数 11，隐式类型转换使复合索引第二列无法用于定位，单次扫描 ~110 万行。
建议：SQL 改为 sub_account = '11'（应用侧绑定参数按字符串传），可立即把扫描量从百万级降到该用户实际分账户行数，预期 131s → 毫秒级。这是一行改动、收益最大的修复。
SHOW ENGINE INNODB STATUS 1,055 次：监控采集命令本身变慢（1.5~3.3s），通常由实例高负载（本日即备份+CTAS 高峰）导致 mutex 等待，属症状而非病因，无需单独处理。golden_source(type, community_bid, street_id) 建覆盖索引，预计可明显下降（未达 30 分钟累计线，仅作建议）。| 优先级 | 对象 | 建议 | 预期收益 |
|---|---|---|---|
| P0 | h8_finance_account_logs 查询 | sub_account = 11 → sub_account = '11' | 单次 131s → ms 级 |
| P0 | tmp_cvd_t12 定时任务 | NOT EXISTS 改 ROW_NUMBER() 窗口函数或增量计算 | 全天 -11h 数据库时间 |
| P1 | dy_aigc 任务领取 | FOR UPDATE SKIP LOCKED | 消除 300s 锁排队 |
| P1 | tw8591 Telescope | staging 关闭/采样 + prune 限流 + 与备份错峰 | 消除 ~9h 写入迟滞 |
| P2 | golden_source 修复统计 | 加覆盖索引 (type, community_bid, street_id) | 288×9s 明显下降 |
| P3 | 备份窗口 | t_item_modi_histories(570万行)、land_shape_coordinates(1560万行) 等 giant 表考虑分块导出/增量备份 | 降低备份时段 IO 峰值 |
es_slow_logs（Top10，env=staging）与 es_search（索引 mysql_slow-*，@timestamp ∈ [2026-09-14T16:00:00Z, 2026-09-15T16:00:00Z)，4,707 条）；表结构/执行计划来自 describe_schema/explain（全程只读）。