MySQL 慢查询日报 2026-09-03

统计概览

指标	数值
统计范围	2026-09-03 00:00:00 ~ 23:59:59（Asia/Shanghai）
ES 时间过滤	@timestamp ∈ [2026-09-03T00:00:00+08:00, 2026-09-04T00:00:00+08:00)
慢日志总数	8,221 条（含 SQL 字段 8,214 条，指纹聚合覆盖全部）
环境	staging（tw8591/tw591/8891 等实例，MySQL 5.7.44）
Top10 最大耗时	1,146.4 s（约 19 分钟，备份导出）
最大累计耗时模式	telescope_entries 巨型 INSERT 系列 ≈ 36,900 s（10.3 小时）
最高频模式	land_mark 地号查询 5,386 条 / 累计 ≈ 3.1 小时

总体结论：昨日慢查询三大来源——

land_mark 地号查询缺索引（5,386 条，avg 2.1s）：单条不进 Top10，但全天累计 3.1 小时扫描放大，是最值得马上加索引的模式；
Telescope 巨型 INSERT 与 01:00 批次锁风暴：telescope_entries / t8_ware_mall_extensions / dy_* 大量语句精确卡在 300s 超时，集中在凌晨 01:00–01:06 批次窗口，累计超 10 小时；
凌晨备份全表导出（user=backup）：Top10 中 4 条，属预期慢查询。

Top10 明细（按单条耗时）

#	耗时(s)	锁时间(s)	扫描行	返回行	用户	库.表	SQL 摘要	慢因类型
1	1146.37	0.0003	79,835	79,835	backup	t8_game.t8_embeddings_cache	SELECT SQL_NO_CACHE * FROM t8_game.t8_embeddings_cache	大结果集传输（宽行 JSON，约 70MB/表）
2	833.57	0.0032	55,291	55,291	backup	game.t8_embeddings_cache	SELECT SQL_NO_CACHE * FROM game.t8_embeddings_cache	大结果集传输（同上，43MB）
3	320.08	0.0002	192,385	192,385	backup	hk8591.h8_telescope_entries	SELECT SQL_NO_CACHE * FROM hk8591.h8_telescope_entries	大结果集传输（content longtext 宽行）
4	312.57	0.0002	3,882,432	3,882,432	backup	bee.django_session	SELECT SQL_NO_CACHE * FROM bee.django_session	大结果集传输（285 万行会话表全量导出）
5	300.01	0.0000	0	0	8591	a8591	administrator command: Prepare	连接/语句挂起至 300s 超时阈值
6	300.00	0.0000	0	0	a8591	t8_extends.telescope_entries	INSERT INTO telescope_entries (...content 巨型 JSON...)	锁等待/超时（300s 整数阈值）
7	300.00	0.0000	0	0	a8591	t8_extends.telescope_entries	INSERT INTO telescope_entries (...同 batch_id...)	锁等待/超时
8	300.00	0.0000	0	0	a8591	t8_extends.telescope_entries	INSERT INTO telescope_entries (...同 batch_id...)	锁等待/超时
9	300.00	0.0000	0	0	a8591	t8_extends.telescope_entries	INSERT INTO telescope_entries (...另一 batch...)	锁等待/超时
10	300.00	0.0000	0	0	a8591	t8_extends.telescope_entries	INSERT INTO telescope_entries (...同 batch...)	锁等待/超时

Top10 逐条分析与建议

1-2. backup 全量导出 t8_embeddings_cache（t8_game / game 两库，1146s / 834s）

表结构：key varchar(255) PK + vector json NOT NULL + expired datetime，估算 7.1 万 / 4.4 万行；EXPLAIN access_type=ALL，data_read_per_join 70M / 43M——每行约 1KB 的 JSON 向量宽行。
建议：备份语句属预期慢查询，调高备份时段 long_query_time 或过滤 user=backup；embeddings 缓存表本质可重建，可从备份清单排除；长期可改 XtraBackup 物理备份避免全表读出。

3. backup 全量导出 h8_telescope_entries（320s）

Laravel Telescope 调试日志表，估算 12 万行，content longtext 巨宽行，AUTO_INCREMENT 已达 11.6 亿。
建议：staging 配置 TELESCOPE_ENABLED=false 或缩短 prune 保留期（1-2 天）。

4. backup 全量导出 bee.django_session（313s）

session_key PK + session_data longtext + expire_date，估算 285 万行，大量过期 session 未清理。
建议：Django 侧执行 python manage.py clearsessions 计划任务可把表缩小一个数量级；纯会话表可排除出备份。

5. administrator command: Prepare 卡 300s（8591@a8591）

Query_time=300.0085 恰为整数超时阈值、rows=0，非真实 SQL，是连接挂起被服务端记账；与 #6-10 同源（Telescope 写入阻塞导致连接空闲挂起）。建议过滤该类条目并核对应用连接池超时配置。

6-10. INSERT INTO telescope_entries 卡 300s（a8591@t8_extends，5 条）

表索引完备（uuid 唯一键 + batch_id/type/family_hash 索引），AUTO_INCREMENT=2.3 亿说明写入量巨大；单条 content 达数 MB（序列化整个 Laravel 容器），写入期间占 binlog 与行锁时间长，同一 batch 并发写入互相等待整体超时。
建议：① staging 关闭 Telescope（TELESCOPE_ENABLED=false）或排除 SocialiteWasCalled 等事件监控、限制 content 截断长度；② php artisan telescope:prune 加入 cron（保留 ≤2 天）；③ 必要时 Telescope 存储切独立实例/SQLite；④ 核对 max_allowed_packet 与应用侧 PDO timeout（300s 更像应用超时而非 innodb_lock_wait_timeout 默认 50s）。

高频慢查询模式分析（指纹聚合，8,214 条全量）

SQL 指纹归一化：字符串/数字/IN 列表 → ?，保留库表与骨架。

按条数 Top5

#	条数	平均(s)	最大(s)	累计(s)	用户	服务器	指纹摘要	备注
1	5,158	2.08	10.00	10,707	t591	addcn_117/80	SELECT ... FROM land_mark WHERE land_no IN(?..) AND region_id=? AND section_id=? AND sect_id=?	🔍 深度分析（缺索引）
2	416	1.63	2.95	677	jmysql	多台	SHOW ENGINE INNODB STATUS	监控采集，非业务
3	233	1.87	4.80	436	airflow	addcn_117	SELECT dag_run ... max(execution_date) 子查询	🔍 深度分析（实例负载）
4	165	1.64	4.30	271	t591	addcn_117/80	同 #1（land_mark 变体）	与 #1 同根因
5	82	217.27	300.00	17,816	a8591	addcn_27	INSERT INTO telescope_entries (content 巨型 JSON)	🔍 深度分析（锁/超时）

按累计耗时 Top5

#	条数	平均(s)	累计(s)	用户	服务器	指纹摘要	备注
1	82	217.3	17,816	a8591	addcn_27	INSERT INTO telescope_entries（巨型 content）	🔍 深度分析
2	5,158	2.08	10,707	t591	addcn_117/80	SELECT ... FROM land_mark ...	🔍 深度分析（缺索引）
3	30	300.0	9,000	a8591	addcn_27	UPDATE t8_ware_mall_extensions SET rank_score... WHERE id=?	🔍 深度分析（锁等待）
4	33	230.1	7,592	a8591	addcn_27	INSERT INTO telescope_entries（变体 batch）	同 #1 根因
5	21	300.0	6,300	a8591	addcn_27	INSERT INTO t8_telescope_entries（schedule 事件）	同 #1 根因

backup（mysqldump 全表导出）模式条数仅个位数、未进两表 Top5，环比无明显翻倍，不触发深度分析。

另有按累计耗时应关注：golden_source 修复查询 82 条 × 61s ≈ 5,012s、tmp_cvd_t12 40 条 × 74s ≈ 2,976s、dy_aigc_crawler_runs FOR UPDATE 14 条 × 300s、dy_user_logins UPDATE 10 条 × 300s。

触发深度分析的模式详情

以下模式满足「非 backup 且条数>100 或累计>30 分钟」，已走 connect → describe_schema → explain 只读链路。

A. land_mark 地号查询 —— 缺索引/扫描放大（最高优先级）

规模：5,158 + 165 + 63 ≈ 5,386 条，avg 2.1s，累计 ≈ 3.1 小时；来自 /* ms:tw591ms-trend-price */ 服务，LAN_addcn_117 / LAN_addcn_80。
表：t591_transcription.land_mark，估算 1,677 万行。
EXPLAIN：key=idx_area，仅用到 (region_id, section_id) 两列，rows_examined_per_scan=170,042，filtered=2%——每个乡镇仍扫 17 万行，sect_id、land_no 只能作为 attached_condition 逐行过滤。
根因：索引列不足以覆盖等值条件，扫描放大约 50 倍。
建议：新增复合索引 ALTER TABLE t591_transcription.land_mark ADD INDEX idx_region_sect_land (region_id, section_id, sect_id, land_no);（四列全部等值/IN，可把扫描降到个位数行；索引列均较窄，写入放大约一个 int+char(9)，建议低峰在 gh-ost/pt-osc 或主从轮换方式执行）。

B. golden_source 修复查询（GetGoldenSourceCommunityIDRepairStreets）—— 缺索引

规模：82 条，avg 61.1s，累计 ≈ 5,012s（1.4 小时）。
表：t591_estate_data.golden_source 估算 857 万行；JOIN t591_new.market_community_building / market_community（均 eq_ref 走 PK，无问题）。
EXPLAIN：gs 表 access_type=range，key=idx_street_id（条件 street_id != 0），rows_examined=428 万，filtered=4.5%——用 street_id 范围扫了半张表，真正筛掉的 community_id=0 AND type=1 AND community_bid!=0 全靠回表过滤。
建议：新增复合索引 ALTER TABLE t591_estate_data.golden_source ADD INDEX idx_type_community (type, community_id, community_bid, street_id); 让 WHERE 四条件直接走索引定位；857 万行大表建议 pt-osc 低峰执行。另建议把「修复类」查询改为离线批量任务避免白天反复执行。

C. telescope_entries 巨型 INSERT 系列 —— 锁等待/超时风暴（累计耗时第一）

规模：82×217s + 33×230s + 23×228s + 21×300s(t8_telescope) ≈ 36,945s（10.3 小时），全部集中在 01:00–01:06。
表：t8_extends.telescope_entries 索引完备（uuid 唯一键、batch_id/type/family_hash 索引），AUTO_INCREMENT 2.3 亿；单条 content 为序列化整个 Laravel 容器的数 MB JSON（含 SocialiteWasCalled 事件、DumpServer/SmsService 配置等调试信息）。
根因：非缺索引——是巨型行写入 + 同 batch 并发互等 + 01:00 cron 批次（statistical:game-sales 等调度任务同时写 schedule 事件）叠加，应用侧 300s 超时后断开。
建议：① staging 关闭 Telescope 或裁剪监控项/截断 content（最有效）；② telescope:prune cron 保留 ≤2 天；③ 避开 01:00 与其他批处理任务同时段调度。

D. t8_ware_mall_extensions rank_score 批量 UPDATE —— 锁等待

规模：30×300s + 15×300s = 13,500s，01:00 批次窗口。
EXPLAIN：WHERE id=? 走 PK，access_type=const、cost=1——语句本身零成本，300s 全部是等锁。
根因：与 C 同窗口；每行携带数 KB 的 rank_score_detail JSON，批量任务长事务持锁，叠加 Telescope 巨型 INSERT 拖慢整体。
建议：批处理改小事务分批提交（每批 ≤100 行）；同窗口任务错峰；先解决 C 后观察是否自愈。

E. dy_aigc_crawler_runs FOR UPDATE / dy_user_logins UPDATE —— 锁等待

规模：14×300s（SELECT ... FOR UPDATE）+ 10×300s（UPDATE ... WHERE user_id），同为 300s 整数超时、01:00 窗口。
EXPLAIN：crawler_runs 走 idx_claim(status) range + filesort，cost 5.48，仅 142 行小表；user_logins 走 user_id 唯一索引 cost=1。
根因：队列表 FOR UPDATE 争用——有 worker 在 01:00 窗口长时间持锁/挂起，后续领取任务的连接全部等到超时。
建议：任务领取改为 FOR UPDATE SKIP LOCKED（MySQL 8.0+）或先 SELECT id 再带版本号 UPDATE；核对 worker 心跳/超时回收逻辑；与 C/D 的窗口错峰。

F. airflow dag_run 查询 —— 实例负载而非 SQL

规模：233 条，avg 1.87s，user=airflow，LAN_addcn_117。
EXPLAIN（staging/8891 airflow_db.dag_run，表仅 124 行）：子查询 dag_run_dag_id_execution_date_key 索引覆盖，cost 1.2——SQL 本身无可优化。
根因：124 行表跑出 1.9s 均值，说明是所在主机整体饱和（addcn_117 同时承载 land_mark 5 千余次慢查询等负载），非该 SQL 问题。先治理 A 再观察。

优化建议汇总（按优先级）

【高】land_mark 加索引 (region_id, section_id, sect_id, land_no)：消除全天 5,386 次、累计 3.1 小时的扫描放大（模式 A）。
【高】golden_source 加索引 (type, community_id, community_bid, street_id)：修复查询从 61s 降到亚秒级（模式 B）。
【高】staging 关闭/裁剪 Telescope 并加 prune cron：一次性消除累计 10.3 小时的 INSERT 超时与 #6-10、Prepare 挂起（模式 C、Top10）。
【中】01:00 批处理窗口错峰 + 小事务化：rank_score 批量 UPDATE、dy_* 任务领取（模式 D/E）。
【中】house_ep_source_relate / house_source_ep_build_relate 的 NOT EXISTS 临时表任务（tmp_cvd_t12 40×74s、tmp_cvd_t14 43×2.1s）：建议为 house_ep_source_relate 增加 (type, ep_source_id, score, post_id) 覆盖索引，让反连接两端都走索引；或改写为 JOIN (SELECT MAX(...)) 派生表写法。
【低】备份治理：过滤 user=backup 慢日志告警；django_session 执行 clearsessions；embeddings 缓存表移出备份清单（Top10 1-4）。
【低】监控噪声：SHOW ENGINE INNODB STATUS（416 条，jmysql）与 administrator command 条目可从慢日志聚合中过滤。

数据来源与生成时间

慢日志：Elasticsearch mysql_slow-* 索引（@timestamp 过滤 UTC+8 昨日全天），经 MCP es_slow_logs（top=10, env=staging）与 es_search（size 5000 + search_after 翻页，全量 8,221 条）获取。
表结构/执行计划：MCP connect / describe_schema / count_estimate / explain 只读查询 staging/tw591(-slave)、staging/tw8591(-slave)、staging/8891，查询后均已 disconnect。
全程只读：未执行任何写库操作、未 kill 任何连接、未修改任何配置、未做 git 提交。
生成时间：2026-09-04 14:4x（Asia/Shanghai），自动化日报脚本。