MySQL 慢查询日报 2026-09-06

• 统计范围：2026-09-06 00:00:00 ~ 23:59:59（Asia/Shanghai，UTC 已换算）
• 环境：staging
• 数据来源：ES 慢日志索引 mysql_slow-*（经 MCP es_slow_logs / es_search，全程只读）
• 生成时间：2026-09-07 10:04:52

一、统计概览

Top10 单条耗时全部为 mysqldump 备份导出（user=backup），属预期行为；真正需要关注的是高频模式（见第三节）。

二、Top10 明细（按单条耗时）

Top10 均为 SELECT /*!40001 SQL_NO_CACHE */ * FROM 库.表; 形式的 mysqldump 全表导出，Lock_time 均 <0.01s，不构成优化对象。建议：备份避开业务高峰、大表（land_shape_coordinates 1560 万行、t_item_modi_histories 569 万行）考虑用物理备份/增量方案减少 binlog 与 IO 压力。

三、高频慢查询模式

3.1 按条数 Top5

3.2 按累计耗时 Top5

SHOW ENGINE INNODB STATUS（956 次）为 zabbix/jmysql 监控探测，非业务 SQL；# administrator command: Prepare 为连接协议开销，均不触发深度分析。user=backup 模式条数与日常持平，未触发深度分析。

四、触发深度分析的模式（条数>100 或 累计>30min，非备份/监控）

4.1 GetGoldenSourceCommunityIDRepairStreets（288 次，avg 60.7s，累计 4.86h）— 最高优先级

SELECT gs.street_id, COUNT(*) FROM golden_source gs
  JOIN t591_new.market_community_building cb ON cb.id = gs.community_bid
  JOIN t591_new.market_community c ON c.id = cb.community_id AND c.deleted_at IS NULL
 WHERE gs.community_bid != 0 AND gs.community_id = 0 AND gs.street_id != 0 AND gs.type = 1
 GROUP BY gs.street_id ORDER BY gs.street_id LIMIT 5;

• EXPLAIN：golden_source（890 万行）走 idx_street_id range 扫描 428 万行，ICP 过滤后仅 4.5% 有效（community_id=0 AND type=1 附加条件回表过滤）；cb/c 均 eq_ref 无问题。
• 现有索引：idx_community_id(community_id)、idx_street_id(street_id)，无覆盖组合过滤条件的复合索引。
• 根因：缺复合索引，等值列（community_id、type）不在索引前缀，导致按 street_id<>0 范围扫描近半表。
• 建议：ALTER TABLE t591_estate_data.golden_source ADD INDEX idx_comm_type_street (community_id, type, street_id, community_bid);（等值列在前，street_id/community_bid 覆盖输出与连接列，可成覆盖索引）。预期扫描量降至万级，单条从 60s 降至亚秒级。

4.2 CREATE TEMPORARY TABLE tmp_cvd_t12（144 次，avg 70.4s，累计 2.82h）

SELECT a.ep_source_id, a.post_id FROM t591_new.house_ep_source_relate a
 WHERE a.type = 2 AND NOT EXISTS (
   SELECT 1 FROM t591_new.house_ep_source_relate b
    WHERE b.type = 2 AND b.ep_source_id = a.ep_source_id
      AND (b.score > a.score OR (b.score = a.score AND b.post_id > a.post_id)));

• 根因：NOT EXISTS 反连接按 (ep_source_id, score, post_id) 求每组最大值，house_ep_source_relate 无 (type, ep_source_id, score, post_id) 复合索引时退化为近自连接全扫（O(N²) 特征，144 次每次 70s，疑似每 10 分钟跑一次的定时任务）。
• 建议：① 加索引 ALTER TABLE t591_new.house_ep_source_relate ADD INDEX idx_type_ep_score_post (type, ep_source_id, score, post_id); ② 或改写为窗口函数 ROW_NUMBER() OVER (PARTITION BY ep_source_id ORDER BY score DESC, post_id DESC) 取 r=1，单次扫描即可；③ 该结果按日几乎不变，建议缓存/降频为每日 1 次。

4.3 CREATE TEMPORARY TABLE tmp_cvd_t1（144 次，avg 10.5s，累计 25min）

• SQL 为带看报表：agent_customer_viewing 与 0~999 数字表 CROSS JOIN 展开 viewing_targets JSON，并 LEFT JOIN agent_customer。
• 表本身仅 3200 行且 idx_customer_id/idx_viewing_date/idx_deleted_at 齐全；WHERE 为跨表 OR（created/updated/deleted_at >= CURDATE()），OR 导致全表扫 + 每行多次 JSON_EXTRACT。
• 建议：① OR 条件改 UNION ALL 各自走索引；② 加 idx_created_at(created_at)、idx_updated_at(updated_at) 与 agent_customer 侧时间索引；③ viewing_targets 结构化落列，避免运行期 JSON 展开。当前量级影响中等，优先级低于 4.1/4.2。

4.4 telescope_entries INSERT（61+21+16 次，avg 230~300s，累计 ~6.7h）

• Laravel Telescope 遥测写入，content 为大 JSON，多条 max 恰为 300.0s 整 —— 符合 innodb_lock_wait_timeout=300 锁等待超时特征；伴随的 DELETE FROM telescope_entries WHERE created_at < ? LIMIT ?（19 次，max 300s）说明清理任务与大 INSERT 互相持锁。
• 建议：① 降低采集采样（Telescope watchers 白名单化 / staging 关闭）；② 清理任务改为小批量分次删除并避开写入高峰；③ 确认 created_at 有索引（清理谓词）。

4.5 dy_login_sessions UPDATE（6 次，avg 300s，全部恰 300.0s）

• UPDATE dy_login_sessions SET last_active_at=... WHERE session_id=?：session_id 已有 uk_session_id 唯一索引，非缺索引，而是行锁被长事务/并发会话持有导致 6 次全部锁等待超时。
• 建议：排查 2026-09-06 当日 01:01 前后持有该 session 行的事务（应用侧长事务/未提交连接）；与会话保持心跳写同一条记录并发过高时考虑合并写或异步化。

五、逐条优化建议汇总

1. [高] golden_source 加复合索引 (community_id, type, street_id, community_bid) —— 消除全天 4.86h 最大头（288 次 × 60s）。
2. [高] house_ep_source_relate 加索引 (type, ep_source_id, score, post_id) 或改窗口函数 —— 消除 2.82h。
3. [中] tmp_cvd_t1 报表 SQL：OR 改 UNION + 补时间索引，报表任务降频。
4. [中] Telescope：staging 降采样、清理改小批量，消除 ~6.7h 锁等待型慢日志。
5. [低] dy_login_sessions 锁超时：排查应用长事务。
6. [低] 备份调度：mysqldump 大表避开高峰；land_shape_coordinates（1560 万行）等考虑快照/增量备份。
7. [低] house_repost 查询（27 次，ispay/status/type 过滤 + ORDER BY rectime，全表扫 1s 级）：可加 (ispay, status, rectime) 复合索引，量小优先级低。

六、数据来源与说明

• ES 慢日志：索引 mysql_slow-*，@timestamp 过滤 [2026-09-06T00:00:00+08:00, 2026-09-07T00:00:00+08:00)，共拉取 4217 条（单页全量，未超 2 万条上限）。
• Top10：MCP es_slow_logs（top=10, env=staging）。
• 执行计划/表结构：MCP connect → describe_schema → explain → disconnect（MySQL 全程只读，未做任何写操作/killed 连接/配置变更/git 提交）。
• SQL 指纹归一化：字符串、数字、IN 列表替换为 ? 后分组。
• 高频模式聚合正常完成，无失败项。