MySQL 慢查询日报 2026-08-31

环境：staging（192.168.8.27 LANaddcn27，实例 staging/tw8591 3306 / staging/hk8591 3307）

统计区间：2026-08-31 00:00:00 ~ 23:59:59（Asia/Shanghai，ES @timestamp 按 UTC 换算为 [2026-08-31T00:00:00+08:00, 2026-09-01T00:00:00+08:00)）

一、统计概览

指标	数值
昨日慢查询总数	1104 条
Top10 门槛耗时	300.0 秒
最长单条耗时	1119.3 秒（约 18.7 分钟）
Top10 涉及实例	staging/tw8591（LANaddcn27:3306，按 hostname 匹配）
Top10 涉及库表	`t8_game`.`t8_embeddings_cache`、`game`.`t8_embeddings_cache`、`t8_extends`.`telescope_entries`
慢因分布	大结果集传输（backup 全量导出）×2；超时/阻塞（精确卡 300s 阈值）×8

总体结论：昨日 Top10 无一来自业务高峰期的普通慢查询，全部集中在凌晨 01:00~01:30 的备份窗口：

#1、#2 为 mysqldump（backup@192.168.8.82）带 SQL_NO_CACHE 全量导出 embeddings 缓存表，慢因是宽行大结果集顺序传输（JSON 向量列，单表数据量 70M/43M），属备份期预期行为；
#3~#10 全部精确卡在 300.00 秒（rows_examined/rows_sent 均为 0、lock_time 为 0），是 telescope_entries 的 INSERT 与 Prepare 语句在备份窗口被阻塞至 5 分钟超时，属备份期间的锁/元数据锁等待超时，非 SQL 本身执行慢。

二、Top10 明细

#	耗时(s)	锁时间(s)	扫描行	返回行	用户	库	SQL（摘要）	慢因类型
1	1119.30	0.000371	79,835	79,835	backup	t8_yy	`SELECT SQL_NO_CACHE * FROM t8_game.t8_embeddings_cache`	大结果集传输
2	797.50	0.038273	55,291	55,291	backup	a8591	`SELECT SQL_NO_CACHE * FROM game.t8_embeddings_cache`	大结果集传输
3	300.01	0	0	0	8591	a8591	`administrator command: Prepare`	超时/阻塞
4	300.00	0	0	0	a8591	t8_extends	`INSERT INTO telescope_entries ...`（batch a2a0a96a…）	超时/阻塞
5	300.00	0	0	0	a8591	t8_extends	`INSERT INTO telescope_entries ...`（batch a2a0a96f…）	超时/阻塞
6	300.00	0	0	0	a8591	t8_extends	`INSERT INTO telescope_entries ...`（batch a2a0a96a…）	超时/阻塞
7	300.00	0	0	0	a8591	t8_extends	`INSERT INTO telescope_entries ...`（batch a2a0a9be…）	超时/阻塞
8	300.00	0	0	0	a8591	t8_extends	`INSERT INTO telescope_entries ...`（batch a2a0a96f…）	超时/阻塞
9	300.00	0	0	0	a8591	t8_extends	`INSERT INTO telescope_entries ...`（batch a2a0a9be…）	超时/阻塞
10	300.00	0	0	0	a8591	t8_extends	`INSERT INTO telescope_entries ...`（batch a2a0a96b…）	超时/阻塞

三、逐条分析与优化建议

#1 / #2 — backup 全量导出 `t8_embeddings_cache`（缺索引不适用，大结果集传输）

EXPLAIN（等价短查询 SELECT * FROM t8_game.t8_embeddings_cache WHERE 1）：access_type=ALL 全表扫描，rows≈70,796，data_read_per_join≈70M（t8_game 库）；game 库 rows≈44,105、≈43M。表结构：仅 key(PK, varchar 255) + vector(json, 向量) + expired(datetime)，无二级索引。

判定：全表扫描本身是备份导出的正常形态，慢在 vector JSON 宽行（平均单行约 1KB）+ SQL_NO_CACHE 逐行读盘传输，7.9 万行跑了 18 分钟，说明 dump 期间 I/O 被打满或被其他锁拖慢。
建议：

t8_embeddings_cache 是缓存表，建议备份脚本排除该表（mysqldump --ignore-table）或改用可重建策略，直接省去 19 分钟备份时长；
若必须备份，将备份窗口与 Telescope 清理任务错开，并考虑 --single-transaction 已具备的一致性读下用 nice/限速（--max-allowed-packet、throttle）降低 I/O 冲击；
expired 字段可加索引并定期清理过期向量，压缩表体积（当前 70k 行 × JSON 向量，长期只增不减）。

#3 ~ #10 — `telescope_entries` INSERT / Prepare 精确 300s 超时

表结构（t8_extends.telescope_entries）：PK sequence，UNIQUE uuid，索引 batch_id、(type,should_display_on_index)、family_hash；AUTO_INCREMENT=230,415,669 —— 历史写入量超 2.3 亿条，当前仅保留约 1 小时数据（实测 9,936 行，09:00~10:01），说明存在高频写入+定期清空的删改 churn。

判定：8 条语句耗时全部为 300.00x 秒且扫描/返回行数为 0、lock_time=0 —— 典型的语句级超时被杀（300s = 5 分钟，疑似 Laravel PDO timeout 或连接层 kill），而非执行慢。发生时间 01:05 前后正处备份窗口，最可能是 mysqldump FLUSH TABLES WITH READ LOCK / 长查询导致写入被阻塞直至超时。EXPLAIN 读路径（uuid const 命中 UNIQUE 索引）正常，无缺失索引问题。
建议：

错峰：Laravel Telescope 的批量写入若能与 01:00 备份窗口错开（或备份期间暂停 Telescope 采集），可消除整批 300s 超时；
降噪：staging 环境 Telescope 建议 TELESCOPE_ENABLED=false 或缩短保留期/降低采样，减少凌晨批量的写入压力（AUTO_INCREMENT 2.3 亿说明写入量巨大）；
定位超时来源：确认 300s 阈值来源（应用 PDO timeout / 代理 kill），若是备份 FTWRL 阻塞，可改 --single-transaction 备份避免全局读锁；
该表现有索引已覆盖常用查询，无需新增索引。

四、数据来源与生成时间

数据来源：MCP 服务 http://192.168.8.75:8200/mcp → es_slow_logs 工具（Elasticsearch 慢日志索引，@timestamp 过滤，env=staging，top=10）；表结构/行数估算/执行计划来自 MCP describe_schema / count_estimate / explain（staging/tw8591，全程只读）。
生成时间：2026-09-01（Asia/Shanghai）
原始数据：outputs/slow_raw_20260831.json、outputs/slow_analysis_20260831.json