MySQL 慢查询日报 2026-09-01

统计范围：2026-09-01 00:00:00 ~ 23:59:59（Asia/Shanghai，UTC+8），环境 staging

数据来源：ES 慢日志索引（@timestamp，UTC 换算 [2026-09-01T00:00:00+08:00, 2026-09-02T00:00:00+08:00)），经 MCP es_slow_logs 工具获取，Top 10 按耗时降序

生成时间：2026-09-02 10:0X +08:00 ｜ 分析工具全程只读（connect / describe_schema / count_estimate / explain，未执行任何写操作、DDL 或 KILL）

一、统计概览

总体结论：昨日无业务 SELECT 缺索引类慢查询进入 Top10。Top3 均为 backup 账号（mysqldump，SQL_NO_CACHE）对宽行 JSON/longtext 表的全表导出，属于备份代价问题；Top4~10 全部是 Laravel Telescope 写入 t8_extends.telescope_entries 的 INSERT 恰好停在 ~300.00 秒（Lock_time 为 0、rows 为 0），是典型的锁等待超时（innodb_lock_wait_timeout=300s）特征，且多条与备份窗口（01:29~01:30 备份同一实例）重叠。

二、Top10 明细

三、逐条分析与优化建议

Top1 / Top2：mysqldump 导出 t8_embeddings_cache（1,125s / 815s）

• 证据（staging/tw8591 只读核查）：
• 表结构：key varchar(255) PK + vector json NOT NULL + expired datetime，仅主键索引；行数估算 t8_game 库 ~70,796 行、game 库 ~44,105 行。
• EXPLAIN：access_type=ALL 全表扫描，data_read_per_join 约 70MB / 43MB（每行含整段 JSON 向量，宽行）。
• 判断：大结果集传输。rows_examined == rows_sent，无索引可加（全量导出本来就取全部行）；慢在 7 万+ 宽 JSON 行的网络/磁盘吞吐。
• 建议：

1. 备份时间与业务/Telescope 写入高峰错开（本次 01:29~01:30 的备份与 telescope_entries INSERT 锁等待在时间上重叠）。
2. 若该缓存表可重建，备份时用 --ignore-table 排除，或改用可增量方式；staging 环境尤其如此。
3. 长期看 vector json 建议改存外部向量库/对象存储，表中只留引用，可同时大幅缩小备份与查询代价。

• 风险/注意：无写操作建议；仅调整备份策略。

Top3：mysqldump 导出 hk8591.h8_telescope_entries（300.61s）

• 证据（staging/hk8591 只读核查）：
• 表结构：标准 Laravel Telescope 表，content longtext，AUTO_INCREMENT 已达 11.5 亿、实际行数 ~127,596 → 历史写入/清理量极大。
• EXPLAIN：全表扫描，data_read_per_join ~127MB（longtext 宽行）。
• 判断：大结果集传输（19 万行 × longtext）。耗时恰超 300s，疑似还撞上了锁/超时边界。
• 建议：Telescope 监控数据不建议纳入常规备份；配置 Telescope prune（保留期缩短），减少表体积；staging 可直接关闭 Telescope。

Top4 ~ Top10：INSERT INTO t8_extends.telescope_entries 锁等待超时（各 ~300.00s）

• 证据（staging/tw8591 只读核查）：
• 表结构：sequence PK、uuid UNIQUE、batch_id/type+should_display/family_hash 普通索引；实际行数仅 ~10,281，但 AUTO_INCREMENT 已达 2.3 亿 → 高频写入+清理。
• EXPLAIN 等价 SELECT：batch_id 条件走 telescope_entries_batch_id_index（ref，1 行），说明读路径索引正常，问题不在缺索引。
• 慢日志特征：Query_time 全部 ≈ 300.002s 且 Lock_time=0、rows=0 → 精确卡在 300s 整数阈值，典型 innodb_lock_wait_timeout=300 锁等待超时；慢日志记录的 lock_time 只含表级锁，行锁等待时间体现在 Query_time。
• 多条 SQL 的 uuid/batch_id 重复出现（如 a2a2ac6c-... 出现 3 次），是超时后应用重试、进一步加剧竞争的风暴特征。实例隔离级别为 REPEATABLE-READ，UNIQUE(uuid) 插入冲突时 next-key 锁易互锁。
• 判断：锁等待（并非缺索引）。触发源头很可能是同时段的 mysqldump（backup 对 telescope 相关表/库的导出持锁）叠加 Telescope 高频写入。
• 建议：

1. 错峰：把 mysqldump 安排到 Telescope 写入低谷，且避免与 API 压测/定时任务同窗（本次 01:29~01:30 备份、04:05 前后均有慢日志聚集）。
2. staging 关闭或降采样 Telescope（TELESCOPE_ENABLED=false 或只记录异常请求），从源头消灭这批 INSERT。
3. 应用侧对 INSERT 设置较短超时并加指数退避重试，避免 uuid 重复重试堆积。
4. 如保留 Telescope，考虑 innodb_lock_wait_timeout 在 staging 调小（如 30s）以快速失败，避免连接被拖 300s。

• 风险/注意：以上均为配置/代码层建议，未对数据库做任何变更。

四、数据来源与生成时间

• ES 慢日志：MCP es_slow_logs（http://192.168.8.75:8200/mcp），start=2026-09-01T00:00:00+08:00、end=2026-09-02T00:00:00+08:00、top=10、env=staging，命中 total=1,350。
• 表结构/行数/执行计划：MCP connect → describe_schema / count_estimate / explain → disconnect，全程只读（staging/tw8591、staging/hk8591）。
• Query_time 按 MySQL slow log 秒数解析；报告生成于 2026-09-02（Asia/Shanghai）。