MySQL 慢查询日报 2026-08-27

统计范围：2026-08-27 00:00:00 ~ 23:59:59（Asia/Shanghai）｜环境：staging｜数据来源：ES 慢日志（MCP es_slow_logs，按 @timestamp 过滤）

一、统计概览

指标	数值
慢查询总数（昨日全天）	1,306 条
涉及实例	staging/tw8591（192.168.8.27:3306，LANaddcn27）
最长单条耗时	1,107.08 s（≈18.5 分钟）
Top10 耗时区间	300.00 s ~ 1,107.08 s
慢因分类	大结果集传输 2 条（backup 全表导出）；锁等待超时 8 条（`telescope_entries` INSERT 精确卡 300.00 s）

Top10 分布： 2 条 mysqldump 备份全表 SELECT *（t8_embeddings_cache，含宽 JSON 向量列）；8 条 Laravel Telescope 写入 telescope_entries 的 INSERT，全部精确停在 300.002 s —— 典型 InnoDB 锁等待超时（innodb_lock_wait_timeout=300）特征，非执行慢。

二、Top10 明细

#	Query_time(s)	Lock_time(s)	Rows_examined	Rows_sent	用户	库	SQL 摘要	慢因类型
1	1107.08	0.000211	79,835	79,835	backup	a8591	`SELECT /!40001 SQL_NO_CACHE / * FROM t8_game.t8_embeddings_cache`	大结果集传输
2	788.25	0.000406	55,291	55,291	backup	t8_yy	`SELECT /!40001 SQL_NO_CACHE / * FROM game.t8_embeddings_cache`	大结果集传输
3	300.0029	0.000000	0	0	a8591	t8_extends	`INSERT INTO telescope_entries (...)` (batch a2989dcd…)	锁等待超时
4	300.0028	0.000000	0	0	a8591	t8_extends	`INSERT INTO telescope_entries (...)` (batch a2989dcd…)	锁等待超时
5	300.0028	0.000000	0	0	a8591	t8_extends	`INSERT INTO telescope_entries (...)` (batch a2989d74…)	锁等待超时
6	300.0028	0.000000	0	0	a8591	t8_extends	`INSERT INTO telescope_entries (...)` (batch a2989d74…)	锁等待超时
7	300.0025	0.000000	0	0	a8591	t8_extends	`INSERT INTO telescope_entries (...)` (batch a2989e28…)	锁等待超时
8	300.0021	0.000000	0	0	a8591	t8_extends	`INSERT INTO telescope_entries (...)` (batch a2989d73…)	锁等待超时
9	300.0019	0.000000	0	0	a8591	t8_extends	`INSERT INTO telescope_entries (...)` (batch a2989d73…)	锁等待超时
10	300.0018	0.000000	0	0	a8591	t8_extends	`INSERT INTO telescope_entries (...)` (batch a2989d73…)	锁等待超时

三、逐条分析与优化建议

1–2. backup 全表导出 `t8_embeddings_cache`（1,107 s / 788 s）

证据（只读核验）：

t8_game.t8_embeddings_cache：约 70,796 行；EXPLAIN access_type=ALL，全表扫描，data_read_per_join≈70M，query_cost 158,324。
game.t8_embeddings_cache：约 44,105 行；access_type=ALL，data_read_per_join≈43M。
表结构：key varchar(255) PK + vector json（宽行）+ expired datetime。SQL 带 /*!40001 SQL_NO_CACHE */，来自 mysqldump（客户端 192.168.8.82，user=backup），发生时间 01:30（备份窗口）。

结论： 非缺索引——备份语句无 WHERE 条件，必然全表扫描。慢因是大结果集传输：每行携带 JSON 向量（约 1KB/行），7 万+ 行串行读出耗时 18 分钟。

建议：

vector 列可压缩存储或迁移到向量库/对象存储，减少 dump 体积（长期方案）。
备份改用 mysqldump --single-transaction --quick --skip-lock-tables，或对这张缓存表 排除备份（--ignore-table）——它是可重建的缓存，重建成本低。
错峰：避开业务批处理时间窗；staging 库可拉长备份周期。

3–10. `telescope_entries` INSERT 精确 300.00 s 超时（8 条）

证据：

8 条 INSERT 全部 Query_time 精确停在 300.001~300.003 s、Lock_time=0、Rows=0 —— 未执行任何行即超时返回，是 innodb_lock_wait_timeout=300 触发的锁等待超时，不是语句本身慢。
表结构（t8_extends.telescope_entries）索引齐全：PK(sequence)、UNIQUE(uuid)、KEY(batch_id)、KEY(type,should_display_on_index)、KEY(family_hash)；当前仅 ~5,689 行且每日清理。
慢日志中同一 batch_id/uuid 出现成对重试（如 a2989dcd…、a2989d74… 各两次）：Laravel Telescope 并发写入相同 uuid 时，唯一键冲突的 INSERT 持有/等待间隙锁（duplicate-key 检查产生的 S 锁），互相阻塞直至 300 s 超时，应用重试进一步放大。

结论： 锁等待（唯一键冲突 + 并发重复写入），索引与表结构无问题。

建议：

staging 关闭 Telescope（TELESCOPE_ENABLED=false）或改用 redis watcher 驱动，避免调试数据直写 MySQL——这是最直接的止血方案。
若需保留 DB 驱动：排查为何同一批次重复提交（队列重试/超时重发），在应用侧做幂等（INSERT ... ON DUPLICATE KEY UPDATE 或写入前去重）。
保留 telescope:prune 定时清理；可评估把 innodb_lock_wait_timeout 在 staging 调低（如 30 s），让失败快速暴露而非挂 5 分钟。

优先级排序

🔴 Telescope 写入超时（8 条，staging 应用可观测性受损）→ 关闭/改驱动，当天可落地。
🟡 备份导出 2 条 → 缓存表排除备份，下一个备份窗口生效。
🟢 表结构/索引层面昨日 Top10 无需改动。

四、数据来源与生成时间

慢日志：ES mysql_slow* 索引（@timestamp ∈ [2026-08-27T00:00:00+08:00, 2026-08-28T00:00:00+08:00)），经 MCP es_slow_logs（top=10, env=staging）获取，共命中 1,306 条。
表结构/行数/执行计划：MCP describe_schema / count_estimate / explain，连接 staging/tw8591，全程只读。
生成时间：2026-08-28 10:05（Asia/Shanghai）；由 AI Agent 自动生成。
假设说明：Query_time 按 MySQL 慢日志秒数解读。