MySQL 慢查询日报 2026-08-30

一、统计概览

核心结论：

1. 备份全表导出拖垮时长榜前二：mysqldump 对 t8_game.t8_embeddings_cache（79,835 行 JSON 向量宽行）和 game.t8_embeddings_cache（55,291 行）执行 SELECT /*!40001 SQL_NO_CACHE */ *，分别耗时 1130s / 797s，属于大结果集传输，非索引问题。
2. 8 条精确卡在 300.00s 的写入慢查询：telescope_entries INSERT（Laravel Telescope 调试组件，自增已到 2.3 亿）与 t8_platform_game_embeddings INSERT，Query_time 均为 300.00x 秒、Lock_time 为 0，典型为 innodb_lock_wait_timeout=50×重试或连接被 wait_timeout/事务挂起阻塞所致——即应用侧长事务/未提交事务持有锁，写入等待至超时。

二、Top10 明细

注：全部来自同一主机 LANaddcn27（192.168.8.27），客户端均为 192.168.8.82。

三、逐条分析与优化建议

#1 / #2：备份导出 t8_embeddings_cache（1130s / 797s）

表结构（describe_schema 实测）：

CREATE TABLE `t8_embeddings_cache` (
  `key` varchar(255) NOT NULL COMMENT 'embeddings 明文唯一标识',
  `vector` json NOT NULL COMMENT '向量数据',
  `expired` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

• 现象：rows_examined == rows_sent（79,835 / 55,291），全表扫描但无扫描放大，属于备份工具的正常全量读，慢在 JSON 向量宽行 + SQL_NO_CACHE 逐行传输。
• 建议：

1. 备份窗口挪到业务低峰（当前 01:30 触发），或使用 --single-transaction --quick --skip-lock-tables 减少锁影响。
2. key 为 varchar(255) 主键偏宽，若可缩短（如 md5 32 位或前缀索引）可减小整表体积。
3. 该表本质是缓存表，备份时可考虑排除（--ignore-table）或改由源数据重建，直接省去 18 分钟。
4. 过期数据定期清理（按 expired），控制行数。

#3 / #8：# administrator command: Prepare 卡 300s

• Prepare 命令本身耗时 300s 说明连接在执行前语句时被阻塞（等锁或等对端），Query_time 精确等于 300s 阈值。
• 建议：排查 192.168.8.82 上应用连接池中是否有长事务未提交；确认 innodb_lock_wait_timeout 与应用重试策略叠加导致的整数倍等待。

#4~#7 / #9：telescope_entries INSERT 卡 300s

表结构（实测，自增 AUTO_INCREMENT≈2.3 亿）：

CREATE TABLE `telescope_entries` (
  `sequence` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `uuid` char(36) NOT NULL,
  `batch_id` char(36) NOT NULL,
  `family_hash` varchar(255) DEFAULT NULL,
  `should_display_on_index` tinyint(1) NOT NULL DEFAULT '1',
  `type` varchar(20) NOT NULL,
  `content` longtext NOT NULL,
  `created_at` datetime DEFAULT NULL,
  PRIMARY KEY (`sequence`),
  UNIQUE KEY `telescope_entries_uuid_unique` (`uuid`),
  KEY `telescope_entries_batch_id_index` (`batch_id`),
  KEY `telescope_entries_type_should_display_on_index_index` (`type`,`should_display_on_index`),
  KEY `telescope_entries_family_hash_index` (`family_hash`)
) ENGINE=InnoDB

• 索引齐全，INSERT 等价查询 explain 无异常（Impossible WHERE 仅因探测条件）。慢因是锁等待：同 batch 的多条 INSERT（相同 batch_id/uuid 前缀 a29ea669/a29ea672/a29ea71c 反复出现）在并发/重试下互相等待，或被其它长事务阻塞至 300s 超时。
• 建议：

1. staging 环境直接关闭 Laravel Telescope（或改用 TELESCOPE_ENABLED=false），可消掉 6/10 条慢查询并停止该表无限膨胀（已 2.3 亿行）。
2. 若保留，定期 prune（telescope:prune），content 为 longtext 大字段，表已过大。
3. 排查应用重试逻辑：同一 uuid/batch 的重复 INSERT 说明失败后重发。

#10：t8_platform_game_embeddings INSERT 卡 300s

表结构（实测）：

CREATE TABLE `t8_platform_game_embeddings` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `platform_game_id` bigint(20) NOT NULL DEFAULT '0',
  `vector` json DEFAULT NULL,
  `name_vector` json DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_platform_game_id` (`platform_game_id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=13851208

• INSERT 带 JSON 大向量（长 SQL），Query_time 精确 300s、Lock_time 0：唯一键冲突等待或大事务提交挂起。若是 INSERT ... ON DUPLICATE/重试场景，platform_game_id 唯一键冲突会等锁。
• 建议：

1. 批量向量写入改为事务分批（如每 500 行提交），避免单个大事务长时间持锁。
2. 冲突时用 INSERT ... ON DUPLICATE KEY UPDATE 显式处理，避免依赖应用重试。
3. 若 300s 为 innodb_lock_wait_timeout（50s）× 6 次重试的累积，应在应用侧将重试上限与间隔调小并加退避。

四、数据来源与生成时间

• 数据来源：ES 慢日志索引（mysql_slow-*，按 @timestamp 过滤 UTC [2026-08-29T16:00:00Z, 2026-08-30T16:00:00Z)），经 MCP es_slow_logs 工具（http://192.168.8.75:8200/mcp，top=10，env=staging）获取；表结构与执行计划经 MCP describe_schema / explain（staging/tw8591）只读分析。
• 生成时间：2026-08-31 10:00 (Asia/Shanghai)
• 全程只读：未执行任何写库、kill 或配置修改操作。