MySQL 慢查询日报 2026-09-02

环境：staging ｜ 统计范围：2026-09-02 00:00:00 ~ 23:59:59 (Asia/Shanghai)

数据来源：Elasticsearch 慢日志索引（@timestamp，UTC+8 全天 → UTC [2026-09-01T16:00Z, 2026-09-02T16:00Z)），经 MCP es_slow_logs 聚合 Top10 ｜ env=staging

一、统计概览

一句话结论：昨日 staging 无业务 SELECT 缺索引问题；慢查询几乎全部来自 ①mysqldump 类备份任务对大表/宽表的全表 SELECT * 导出，②Laravel Telescope 调试组件向 t8_extends.telescope_entries 写入超长 JSON 时被阻塞到精确 300 秒（超时阈值）。

二、Top10 明细

三、逐条分析与优化建议

#1/#2 t8_embeddings_cache 全表导出（1152s / 817s）

• 表结构（describe_schema 实测）：t8_game.t8_embeddings_cache 与 game.t8_embeddings_cache 结构相同 —— key varchar(255) 主键、vector json NOT NULL（向量数据）、expired datetime。PK 为 key，无其他索引；无 id 列。
• 慢因：备份用 SELECT * SQL_NO_CACHE 导出含 vector json 宽行，单行可达数百 KB~MB，8 万行即产生 GB 级传输，耗在网络/磁盘传输，非缺索引（全表导出本来就无过滤条件）。
• 建议：

1. 备份窗口错峰：该查询 01:30 开始、持续 19 分钟，与业务低峰重叠尚可，但建议限制 --single-transaction + 压缩流（| gzip / --compress）。
2. vector 缓存数据本质可再生，可评估用逻辑导出（仅 key+expired）+ 过期重建策略，跳过大 JSON 列。
3. 若需常驻查询，expired 列可加索引便于清理任务；对导出场景无收益。

#3 h8_telescope_entries 全表导出（314s）

• 注意：慢日志发生在 3307（hk8591 实例），MCP 连接的 tw8591（3306）上 hk8591.h8_telescope_entries 不存在，说明该表只在 3307 侧，instance 归属按 host:port 区分（LAN_addcn_27_3307）。分析结论按同构的 telescope 表推断。
• 慢因：Laravel Telescope 监控表，content longtext 超宽，19 万行全量导出，大结果集传输。
• 建议：Telescope 属调试数据，staging 定期归档/裁剪（telescope:prune），保持表体量在可备份范围；备份可用 --ignore-table 跳过。

#4 t1_daily_report 全表导出（311s，2933 万行）

• 表结构（实测）：60+ 列宽表（type/object_id/design_id + 各端 browse/pin/fb/line 分享、收藏、下载等计数），PK id；explain 等价短查询（WHERE id=1）命中 PRIMARY const，说明 PK 索引正常。
• 慢因：2933 万行全表 SELECT * 导出，大结果集传输，rows_examined = rows_sent，无浪费扫描。
• 建议：

1. 该表为按日累积的统计明细，评估分区（RANGE by date）后备份可按分区增量。
2. 备份流压缩；或改用 XtraBackup 物理备份，避免 SQL 层全表传输。

#5 # administrator command: Prepare（300.0038s）

• 特征：Query_time = 300.0038s，精确卡在 300s（5 分钟）整数阈值，rows=0、lock_time=0 —— 典型的连接/语句被阻塞至超时（如 innodb_lock_wait_timeout 或代理端 read timeout）后被记录。
• 建议：核对 01:05 前后该连接（user 8591, client 192.168.8.82）的上下文；结合 #6~#10 判断是同一批 Telescope 写入被长事务阻塞。

#6~#10 INSERT INTO telescope_entries（各 ≈300.00s）

• 表结构（实测 t8_extends.telescope_entries）：sequence PK、uuid 唯一键、batch_id/type/family_hash 索引齐全，content longtext；AUTO_INCREMENT 已到 2.31 亿，表体量巨大。
• 慢因：Query_time 全部精确 ≈300.00s、lock_time=0 —— 写入被阻塞到超时阈值（锁等待/mdl/redo 刷盘被备份大事务挤压），同一时间窗（01:05 左右）成批出现，与 #1/#2 的 19 分钟备份大事务高度相关：备份 SELECT 长事务 + 大写入并发 → 写入被卡满 300s。
• 建议（优先级从高到低）：

1. 关闭/限流 staging 的 Laravel Telescope：调试组件不该在 staging 产生亿级行写入，TELESCOPE_ENABLED=false 或采样模式即可消除 #3/#5~#10 全部 7 条。
2. 立即执行 telescope:prune 清理历史数据（2.31 亿 auto_increment 说明从未清理）。
3. 备份任务改 --single-transaction 并与写入低峰错开，避免长读事务阻塞写入（或从 100-slave 等从库备份）。

四、风险提示

• 昨日 staging 慢查询的 70%+（时间占比）由备份任务贡献，虽非业务故障，但备份长事务会连带造成写入超时（#5~#10 已出现 300s 级阻塞），建议尽快将备份切到从库或错峰。
• t8_extends.telescope_entries 表 2.31 亿自增、无清理机制，是持续性风险源。

五、数据来源与生成时间

• 数据来源：MCP es_slow_logs（Elasticsearch mysql_slow-*，@timestamp 过滤 2026-09-02 全天 UTC+8），env=staging，top=10；表结构经 MCP describe_schema 实测，执行计划经 MCP explain 实测（全程只读）。
• 说明：昨日数据充足（1,280 条），未触发前日回退。#1/#2/#6~#10 的 explain 因无 id 列/INSERT 语句无法直接 EXPLAIN，改用同表等价查询或结构分析。
• 生成时间：2026-09-03 10:02 (Asia/Shanghai) ｜ 工具链：fastmcp Client → http://192.168.8.75:8200/mcp