MySQL 慢查询日报 2026-09-09

1. 统计概览

项目	数值
统计时间范围	2026-09-09 00:00:00 ~ 23:59:59（Asia/Shanghai，UTC 换算 [2026-09-08T16:00Z, 2026-09-09T16:00Z)）
慢查询总数	118,861 条
├ 591 集群	31,172 条
├ 8591 集群	66,719 条
└ 8891 集群	20,970 条
明细抽样（指纹聚合用）	59,026 条（每集群最多 4 页 × 5000）
SQL 指纹数	2,342 个
Top10 单条最大耗时	5,711 秒（约 95 分钟）
锁等待型慢查询	0 条（Top10 的 Lock_time 均 < 0.1s，占比可忽略）
最大单模式累计耗时	20,073 秒（约 5.6 小时）（`t8891.t_member_devices` 指纹）

⚠️ staging 环境数据缺失说明：staging ES（elasticsearch-master.es.svc.cluster.local:9200）API Key 认证失败（HTTP 401 invalid credentials），昨日与前日均无法取数。本次日报基于线上三套 ES（prod-591 / prod-8591 / prod-8891，索引 mysql-slow_2026.09）合并分析。建议更新 MCP config.yaml 中 es.staging 的 api_key。

2. Top10 慢查询明细

#	耗时	集群/实例	用户	库.表	扫描行数	返回行数	SQL 摘要	慢因类型
1	5711.5s	591 / ZHDX_t591_148	bi	t591 竞价相关多表	46.3 亿	21,367	竞价记录 BI 报表（mcrd/mcbr/ar/ase 多表 JOIN）	大 JOIN 扫描（缺索引）
2	4954.2s	591 / ZHDX_t591_148	bi	t591.sale	7.04 亿	0	售房物件数/会员数日报（子查询 + DISTINCT，EXPLAIN 超时）	大范围聚合扫描
3	4796.9s	8591 / ZHDX_t8591_107	bi	a8591.t8_mall_stat	3.23 亿	1.61 亿	`SELECT * FROM t8_mall_stat ORDER BY created_at DESC`	全表扫描 + 大结果集传输
4	4774.2s	591 / ZHDX_t591_148	bi	t591.sale + activity_plan_money	7.04 亿	1	同 #2（活动口径）	大范围聚合扫描
5	3836.8s	8591 / ZHDX_t8591_107	bi	a8591.t8_mall_stat	3.23 亿	1.62 亿	同 #3	全表扫描 + 大结果集传输
6	3075.5s	591 / ZHDX_t591_148	bi	t591.sale + activity_plan_money	7.04 亿	1	同 #4	大范围聚合扫描
7	3018.9s	8591 / ZHDX_t8591_107	bi	a8591 交易/订单多表	3,202 万	66	BI 交易报表（buyUser/sellUser 多表 JOIN）	大 JOIN 扫描
8	2990.2s	8591 / ZHDX_t8591_107	bi	a8591.t8_mall_stat	3.23 亿	1.62 亿	同 #3	全表扫描 + 大结果集传输
9	2914.5s	8591 / ZHDX_t8591_107	bi	a8591.t8_mall_stat	3.23 亿	1.61 亿	同 #3	全表扫描 + 大结果集传输
10	2706.3s	8591 / ZHDX_t8591_107	bi	a8591 订单多表	3,651 万	293 万	BI 订单报表（IFNULL 多路 JOIN）	大 JOIN 扫描 + 大结果集

Top10 关键结论

Top10 全部来自 bi 用户、集中在 BI 从库（ZHDX_t591_148、ZHDX_t8591_107），全部为只读 SELECT，无锁等待型。
#3/#5/#8/#9（同构）：SELECT * FROM t8_mall_stat ORDER BY created_at DESC 一天执行 4 次以上、每次约 50~80 分钟。EXPLAIN（8591-a 实测）：access_type=ALL、rows_examined_per_scan=21,642,902、using_filesort=true，单次返回 1.6 亿行。t8_mall_stat 上只有 mall_id、mcd_index 两个索引，created_at 无索引 → 全表扫描 + filesort + 宽行全量传输。
#2/#4/#6（同构）：t591.sale 上的 DISTINCT 日报统计，EXPLAIN 显示驱动表 activity_plan_money 走 type 索引仍需扫 745 万行/次，sale 走 user_id 索引；#2 的 EXPLAIN 直接超时（查询代价过大）。
#1/#7/#10：BI 多表 JOIN 报表，ES 侧 SQL 被截断（507 字符）无法完整 EXPLAIN，但 rows_examined（46 亿 / 3200 万 / 3650 万）已表明中间结果集巨大。

3. 高频慢查询模式（频次维度）

对 59,026 条明细做 SQL 指纹归一化（字符串/数字/IN 列表 → ?）后聚合。

3.1 按条数 Top5

#	条数	累计耗时	平均	最大	用户	指纹（骨架）	深度分析
1	3,932	20,072.8s (5.6h)	5.11s	14.7s	t8891	`select * from t_member_devices where (m_id=? and hash=?) limit ?`	✅（见 3.3-P1）
2	3,642	6,128.9s (1.7h)	1.68s	14.7s	tw591	`select count(*) from sale where status=? and closed=? and community_id=? and kind IN (?) and posttime>=?`	✅（P2）
3	2,935	10,319.3s (2.9h)	3.52s	7.2s	a8591	`SELECT c.* FROM t8_user_id_card_number_list c WHERE img_type=? AND status=? AND image!=? AND (ocr_result=? or null) ORDER BY id ASC LIMIT ?`	✅（P3）
4	2,600	3,489.0s (58min)	1.34s	1.9s	a591	`select t1_design_img.* ... join t1_design_work ... where check_status=? and is_show=? ...`	✅（P4）
5	2,080	10,371.5s (2.9h)	4.99s	33.4s	tw591	`select community_id, MIN(user_id) from t591.sale join t591_new.market_community_agent_bid_record b ... join im_user_bind im ...`	✅（P5）

3.2 按累计耗时 Top5

#	条数	累计耗时	平均	最大	用户	指纹（骨架）	深度分析
1	3,932	20,072.8s (5.6h)	5.11s	14.7s	t8891	同 3.1-#1	✅（P1）
2	363	13,938.9s (3.9h)	38.4s	107.3s	a8591	`select sum(searched_times) total, keyword from t8_keyword_statistics where date between ? and ? group by keyword order by total desc limit ?`	✅（P6）
3	2,080	10,371.5s (2.9h)	4.99s	33.4s	tw591	同 3.1-#5	✅（P5）
4	2,935	10,319.3s (2.9h)	3.52s	7.2s	a8591	同 3.1-#3	✅（P3）
5	1,845	9,200.2s (2.6h)	4.99s	7.9s	t8891	`select f_id, COUNT() from t_carinfo_favorite where m_id IN (?) and type=? and exists (select from t_carinfo_search_base_kind ...)`	✅（P7）

backup 模式：两表中无 user=backup（mysqldump）模式入选；全部高频模式均为业务/BI 查询，且全部触发深度分析（条数>100）。

3.3 触发深度分析的模式详情

P1 · t8891.t_member_devices（3932 条 / 累计 5.6h）— 头号模式

现象：select * from t_member_devices where m_id=? and hash=? limit 1，均 5.1s，分布在 YCJF_t8891_24/25 全部实例。
EXPLAIN：走 t_member_devices_m_id_index（仅 m_id 单列），rows_examined_per_scan≈800,287 —— hash 条件不在索引里，单个 m_id 下几十万设备行逐行回表过滤。
根因：缺 (m_id, hash) 复合索引。
建议：ALTER TABLE t8891.t_member_devices ADD INDEX idx_m_id_hash (m_id, hash);（现有 m_id 单列索引可被其完全替代，评估后删除 t_member_devices_m_id_index）。该索引可把扫描行数从 80 万降到 1，预计消除全天 5.6 小时慢查询。

P2 · t591.sale 社区计数（3642 条 / 1.7h）

EXPLAIN：走 idx_community_id（单列），rows≈1336，再逐行过滤 status/closed/kind/posttime。
建议：加复合索引 sale (community_id, status, closed, kind, posttime)（或至少 (community_id, posttime)）；这是 CDC 链路（/* ms:tw591ms-cdc */）发出的查询，索引收益直接降低主从延迟。

P3 · a8591.t8_user_id_card_number_list（2935 条 / 2.9h）

EXPLAIN：ORDER BY id ASC LIMIT 1 走 PRIMARY 全索引顺序扫描，从 id=1 开始逐行回表检查 img_type/status/ocr_result 条件，扫到第一条匹配为止（本例 explain 命中快，真实负载下匹配行越晚出现越慢，平均 3.5s）。
根因：过滤列无索引，优化器选择按 PK 顺序扫描来满足 ORDER BY ... LIMIT 1。
建议：ALTER TABLE a8591.t8_user_id_card_number_list ADD INDEX idx_type_status_id (img_type, status, id); 该查询是轮询消费型（OCR 重试队列），索引后可变成点查。

P4 · t591.t1_design_work/design_img 装潢列表（2600 条 / 58min，a591 用户，ZHDX_t8591_73）

EXPLAIN（等价化简后）：驱动表 t1_design_work 走 check_status 复合索引 range 扫 15,463 行、backward index scan、覆盖索引、无 filesort——计划本身健康；1.34s 均耗主要来自 JOIN t1_design_img 宽行（views/favor_count 等展示列）回表。
建议：优先确认线上与从库统计信息一致（ANALYZE TABLE）；若列表页字段可裁剪，改 SELECT 列子集或为 t1_design_img 建覆盖索引 (w_id, views, favor_count, ...)。收益中等，非最优先。

P5 · t591 竞价社区代理（2080 条 / 2.9h，max 33.4s）

EXPLAIN：sale 走 idx_community_id range 15,363 行 → JOIN market_community_agent_bid_record 走 idx_user_id 每行 431 行 → JOIN im_user_bind 1 行。中间层 431 行/次的 fan-out 是主要成本（15363×431 量级），且 b 表还要再按 start_time/end_time 过滤。
建议：给 t591_new.market_community_agent_bid_record 建 (user_id, start_time, end_time) 复合索引；给 im_user_bind (im_uid) 确认已有 uid 索引。此模式与 Top10-#1 同族，索引一并受益。

P6 · a8591.t8_keyword_statistics 关键词月度汇总（363 条 / 累计 3.9h，单条均 38.4s、max 107s）

EXPLAIN：range 扫 idx_date_keyword_searched_times 669,892 行（using_index 覆盖），但 GROUP BY keyword + ORDER BY sum() 触发 temporary + filesort，data_read_per_join≈669MB。
根因：31 天跨度行数大 + 聚合排序无法用索引消除。
建议：① 量级允许时改用 (keyword, date) 索引让 GROUP BY 走索引序；② 更优：增加按日/按周预聚合表或把「热门关键词 Top5」做缓存（该查询一天 363 次、结果按天变化，缓存命中率极高）。

P7 · t8891.t_carinfo_favorite EXISTS 计数（1845 条 / 2.6h）

原始 SQL 的 IN 列表被 ES 截断，EXPLAIN 用等价短查询（explain 为 const，仅验证表可访问）；表上已有 m_id_type (m_id, type) 复合索引，IN+type 条件本身可走。
根因（推断）：EXISTS (select * from t_carinfo_search_base_kind where favorite.f_id = base_kind...) 子查询若 t_carinfo_search_base_kind 关联列无索引，外层每个 f_id 都触发一次子查询全扫。
建议：核查 t_carinfo_search_base_kind 上关联列（f_id/id）是否有索引，无则补；外层可确认走 m_id_type。

4. 逐条优化建议（按收益排序）

[P1] t8891.t_member_devices 加 (m_id, hash) 复合索引 — 预计消除全天 5.6h、3932 条慢查询，单条从 5.1s → 毫秒级。最高收益/成本比。
[Top10-#3/5/8/9] a8591.t8_mall_stat BI 导出改造 — 加 created_at 索引可消 filesort，但根本问题是 SELECT * 全量 1.6 亿行导出：改为分页/分批（WHERE created_at > 游标 LIMIT n）或落地到离线数仓，避免每次 50~80 分钟占用 BI 从库。
[P6] t8_keyword_statistics 热词汇总加缓存或预聚合 — 3.9h/天，363 次重复计算，缓存即可归零。
[P2] t591.sale 加 (community_id, status, closed, kind, posttime) 复合索引 — CDC 链路 3642 次/天，且降低主从延迟。
[P5] market_community_agent_bid_record 加 (user_id, start_time, end_time) — 2.9h/天，并缓解 Top10-#1。
[P3] t8_user_id_card_number_list 加 (img_type, status, id) — 轮询队列 2935 次/天、2.9h，索引后变点查。
[P7] 核查 t_carinfo_search_base_kind 关联列索引 — 2.6h/天。
[Top10-#1/2/4/6/7/10] BI 大报表迁移 — 591 竞价/物件日报、8591 交易/订单报表单条 45~95 分钟，扫描 7 亿~46 亿行，建议统一迁到离线数仓（已占用昨日 Top10 全部席位）。
[运维] 更新 staging ES api_key（MCP config.yaml es.staging），恢复 staging 慢日志覆盖。
DDL 均建议先在从库/低峰执行并利用 online DDL；本次分析全程只读，未做任何变更。

5. 数据来源与生成时间

数据来源：MCP 服务 http://192.168.8.75:8200/mcp（fastmcp Client）
es_slow_logs（top=10，prod-591 / prod-8591 / prod-8891 合并）
es_search（索引 mysql-slow_2026.09，按 @timestamp 过滤，翻页抽样 59,026 条）
connect / describe_schema / explain / disconnect（MySQL 只读分析，涉及 prod-591/master、prod-8591/8591-a、prod-8591/8591-b、prod-8591/100、prod-8891/master）
慢因判定口径：rows_examined vs rows_sent、EXPLAIN access_type/key/filesort、Lock_time 占比、Bytes/行传输量。
生成时间：2026-09-10 10:00 (Asia/Shanghai)；分析脚本：.agents/scripts/slow_report_20260909.py + slow_report_20260909_fix.py；中间数据：outputs/analysis_20260909.json。
已知局限：① staging ES 401 未纳入；② ES 的 SQL 字段超长会截断（507 字符），#1/#7/#10 无法完整 EXPLAIN；③ 明细抽样上限每集群 2 万条（591/8591 全量未拉完，聚合为抽样近似）。