MySQL 慢查询日报（线上 prod591）2026-09-08

统计概览

Top10 明细（按单条耗时）

高频慢查询模式（指纹聚合，取样 20,583 条）

按条数 Top5

按累计耗时 Top5

备份模式全天 40 条 / 1.48h，未触发深度分析（如条数环比异常翻倍再人工介入）。

触发深度分析的模式（条数>100 或 累计>30min，非备份，最多 8 个）

1. select a.community_id, MIN(a.user_id) as user_id from t591.sale as a inner join t591_new.market_community_agent_bid_record as b on a.user_id = b.user_id inner j —— 2,578 次 × 4.96s = 3.55h

• 代表性 SQL：

select a.community_id, MIN(a.user_id) as user_id from t591.sale as a inner join `t591_new`.`market_community_agent_bid_record` as `b` on `a`.`user_id` = `b`.`user_id` inner join `t591_new`.`im_user_bind` as `im` on im.im_uid=CONCAT(a.user_id,"") where `a`.`community_id` in ('105035', '3695078', '3681594') and `b`.`start_time` >= '2026-09-08 00:00:00' and `b`.`end_time` <= '2026-09-08 23:59:59' and `b`.`status` = '3' and `b`.`proc_status` = '3' and `b`.`deleted` = '0' and `a`.`status` = '2' and `a`.`closed` = '0' group by `a`.`community_id` /* ms:tw591ms-community */;

• 库表：t591.sale；实例 alias：prod-591/master
• explain SQL：

select a.community_id, MIN(a.user_id) as user_id from t591.sale as a inner join `t591_new`.`market_community_agent_bid_record` as `b` on `a`.`user_id` = `b`.`user_id` inner join `t591_new`.`im_user_bind` as `im` on im.im_uid=CONCAT(a.user_id,"") where `a`.`community_id` in ('105035', '3695078', '3681594') and `b`.`start_time` >= '2026-09-08 00:00:00' and `b`.`end_time` <= '2026-09-08 23:59:59' and `b`.`status` = '3' and `b`.`proc_status` = '3' and `b`.`deleted` = '0' and `a`.`status` = '2' and `a`.`closed` = '0' group by `a`.`community_id` /* ms:tw591ms-community */;

• 执行计划（EXPLAIN 表节点，按 JOIN 顺序）：

• 慢因：扫描行数远大于返回行数(1,796,844/3)、索引选择性差(a: key=idx_community_id 扫 20,285 行回表后仅剩 1.0%，建议把其余 WHERE 等值列并入复合索引)、JOIN 条件含函数(如 ON col=CONCAT(...))导致索引失效, 建议冗余类型一致列直连
• 建议：补索引（按 WHERE 等值列在前、范围列收尾建复合索引）; 用 EXPLAIN 验证 key 命中; 扩复合索引: 把其余 WHERE 等值列追加到现有索引尾部, 避免 10 万+ 行回表; JOIN 两侧列改为同类型直连(如int列配int列), 或新增冗余绑定列建索引
• 可执行 DDL（建议先在低峰期 EXPLAIN 验证再执行）：

ALTER TABLE `t591`.`sale` ADD INDEX `idx_status_proc_statu_deleted_closed_community__start_time` (`status`, `proc_status`, `deleted`, `closed`, `community_id`, `start_time`);

2. SELECT CURDATE() dt,count(DISTINCT user_id) ?, count(?) ? FROM t591.sale WHERE posttime>=UNIX_TIMESTAMP(?) and closed=? -- and status=? and end_time>=UNIX_TIMES —— 2 次 × 3672.90s = 2.04h

• 代表性 SQL：

SELECT CURDATE() dt,count(DISTINCT user_id) '会员数', count(1) '物件数' 
FROM t591.sale 
WHERE posttime>=UNIX_TIMESTAMP('2023-01-01') and `closed`=0 -- and `status`=2
and end_time>=UNIX_TIMESTAMP('2023-07-03') and user_id in (
SELECT DISTINCT user_id from t591.activity_plan_money where `type`=2 and sign=2 and `status`=1 and posttime<UNIX_TIMESTAMP('2023-07-03')
);

• 库表：t591.sale；实例 alias：prod-591/master
• explain SQL：

SELECT CURDATE() dt,count(DISTINCT user_id) '会员数', count(1) '物件数' 
FROM t591.sale 
WHERE posttime>=UNIX_TIMESTAMP('2023-01-01') and `closed`=0 -- and `status`=2
and end_time>=UNIX_TIMESTAMP('2023-07-03') and user_id in (
SELECT DISTINCT user_id from t591.activity_plan_money where `type`=2 and sign=2 and `status`=1 and posttime<UNIX_TIMESTAMP('2023-07-03')
);

• 执行计划（EXPLAIN 表节点，按 JOIN 顺序）：

• 计划标志：⚠️ 产生临时表
• 慢因：扫描行数远大于返回行数(703,425,917/1)、索引选择性差(activity_plan_money: key=type 扫 7,454,991 行回表后仅剩 0.5%，建议把其余 WHERE 等值列并入复合索引)、DISTINCT/GROUP BY 产生临时表(大范围去重/聚合)、IN (SELECT ...) 子查询(易退化为相关子查询逐行执行, 建议改 JOIN/EXISTS)
• 建议：补索引（按 WHERE 等值列在前、范围列收尾建复合索引）; 用 EXPLAIN 验证 key 命中; 扩复合索引: 把其余 WHERE 等值列追加到现有索引尾部, 避免 10 万+ 行回表; 缩小聚合/去重范围(补时间等过滤条件), 或预聚合到中间表/定时任务; 改写为 JOIN/EXISTS 并验证子查询能下推; 该实例无 MCP 映射, 建议在库上手动 EXPLAIN 复核
• 可执行 DDL（建议先在低峰期 EXPLAIN 验证再执行）：

ALTER TABLE `t591`.`sale` ADD INDEX `idx_closed_status_type_sign_user_id_posttime` (`closed`, `status`, `type`, `sign`, `user_id`, `posttime`);

3. SELECT mcrd.id, mcbr.period_id as ?, mcrd.record_id ?, if(mcbr.parent_id!=?,mcbr.parent_id,null) ?, mcrd.oid ?, mcrd.user_id ?, case mcrd.payment_type when ? th —— 1 次 × 5978.92s = 1.66h

• 代表性 SQL：

SELECT 
mcrd.`id`,
mcbr.period_id as '期数',
mcrd.`record_id` '竞价ID',
if(mcbr.parent_id!=0,mcbr.parent_id,null) '父竞价ID',
mcrd.oid '订单ID',
mcrd.`user_id` '会员ID',
case mcrd.`payment_type` when 1 then '竞价' when 2 then '调价' end '出价类型',
mcrd.`money` '(出价/调价)金额',
mcrd. `type` '竞价类型',
mcrd.`rank` '预排名',
mcrd.`community_id` '社区ID',
-- mc.`name` '社区名称',
ar.`name` '社区县市',
ase.`name` '社区乡镇',
case when mcrd.`source`=1 then '推荐' when mcrd.`source`=2 then '搜寻' when mcrd.`source`=3 then '收藏' when mcrd.`source`=4 then '上期' 
when mcrd.`source`=5 then '历史' when mcrd.`source`=6 then '续购' when mcrd.`source`=7 then '物件管理页' when mcrd.`source`=8 then '会员中心推荐社区弹窗' when mcrd.`source`=9 then '召集令活动页' when mcrd.`source`=10 then '企业号触屏' when mcrd.`source`=11 then '精准营销弹窗' when mcrd.`source`=12 then '物件刊登成功页' when mcrd.`source`=13 then '物件管理页顶部推荐' when mcrd.`source`=14 then '最新续购' 
when mcrd.`source`=15 then '优质社区推荐'
when mcrd.`source`=16 then '弹窗复购'
when mcrd.`source`=17 then '弹窗續費'
when mcrd.`source`=18 then '中古屋詳情頁PC端'
when mcrd.`source`=19 then '中古屋詳情頁觸屏端'
when mcrd.`source`=20 then '中古屋詳情頁APP端'
when mcrd.`source`=21 then '租屋詳情頁PC端'
when mcrd.`source`=22 then '租屋詳情頁觸屏端'
when mcrd.`source`=23 then '租詳情頁APP端'
when mcrd.`source`=24 then 'PC-会员中心优惠券'
when mcrd.`source`=25 then '触屏-会员中心'
when mcrd.`source`=26 then 'APP-会员中心'
when mcrd.`source`=27 then '四端-金牌专家版位'
when mcrd.`source`=28 then '四端-介绍页'
when mcrd.`source`=29 then '待办事项提醒续费'
when mcrd.`source`=30 then '待办事项体系到期复购'
when mcrd.`source`=31 then 'PC-现金券列表'
when mcrd.`source`=32 then '触屏-现金券列表'
when mcrd.`source`=33 then 'PC-领取成功弹窗社区推荐'
when mcrd.`source`=34 then 'PC-待使用弹窗社区推荐' 
when mcrd.`source`=35 then '物件管理页顶部推荐(物件推荐)'
when mcrd.`source`=37 then '曝光失败弹窗复购'
when mcrd.`source`=38 then '即将到期一键续购'
when mcrd.`source`=39 then '已到期一键续购'
when mcbr.`source`=40 then '即将到期一键续购-触屏'
when mcbr.`source`=41 then '即将到期一键续购-APP'
when mcrd.`source`=101 then '其他'
when mcrd.`source`=102 then 'pc金牌专家购买列表'
when mcrd.`source`=103 then '触屏金牌专家购买列表'
when mcrd.`source`=104 then 'PC物件管理页列表'
when mcrd.`source`=105 then 'PC弹窗引导'
when mcrd.`source`>=100 and mcrd.`source`<=200 then '自定义' else mcrd.`source` end '订单入口来源',
mcrd.`deleted` '是否刪除',  -- ，1、為已刪,0、未未刪
case mcrd.`pay_status` when 1 then '待支付' when 2 then '已支付' when 3 then '退款' when 4 then '取消' when 5 then '失败' else mcrd.`pay_status` end '支付状态',
mcrd.`created_at` '创建时间',
mcrd.`updated_at` '更新时间' 
from t591_new.market_community_agent_bid_record_detail mcrd 
LEFT JOIN t591_new.market_community_agent_bid_record mcbr on mcrd.record_id=mcbr.id and mcrd.user_id=mcbr.user_id 
LEFT JOIN t591_new.market_community_bid_rules mcr on mcbr.`community_id`=mcr.community_id -- and mcbr.period_id=mcr.period_id
LEFT JOIN t591_new.`market_community` mc on mcrd.community_id=mc.id 
left JOIN t591_new.area_region ar on mcr.`regionid`=ar.id
left JOIN t591_new.`area_section` ase on mcr.sectionid=ase.id 
LEFT JOIN t591_new.market_community_agent_order mco on mcrd.oid=mco.id 
LEFT JOIN t591_new.market_voucher_use mvu on mcrd.user_id=mvu.user_id and mcrd.oid=mvu.oid and mvu.oid!=0
LEFT join t591_new.market_voucher mv on mvu.voucher_id=mv.id
LEFT join t591_new.market_voucher_config mvc on mv.config_id=mvc.id 
WHERE mcrd.created_at>='2023-08-21' and mcbr.parent_id!=0
and (mcrd.created_at>=DATE_SUB(CURDATE(),INTERVAL 2 DAY) or mcrd.updated_at>=DATE_SUB(CURDATE(),INTERVAL 2 DAY));

• 库表：t591_new.market_community_agent_bid_record_detail；实例 alias：prod-591/master
• explain SQL：

SELECT * FROM `t591_new`.`market_community_agent_bid_record_detail` WHERE created_at>='2023-08-21' LIMIT 10

• 执行计划（EXPLAIN 表节点，按 JOIN 顺序）：

• 慢因：扫描行数远大于返回行数(4,686,578,641/21,533)、索引范围扫描量过大(market_community_agent_bid_record_detail: key=idx_created_at, rows=3,568,860)
• 建议：补索引（按 WHERE 等值列在前、范围列收尾建复合索引）; 用 EXPLAIN 验证 key 命中

4. select count(*) as aggregate from sale where status = ? and closed = ? and community_id = ? and kind IN (?...) and posttime >= ? /* ms:tw591ms-cdc */; —— 3,524 次 × 1.65s = 1.62h

• 代表性 SQL：

select count(*) as aggregate from `sale` where `status` = '2' and `closed` = '0' and `community_id` = '34062' and `kind` in ('6', '8', '9', '10', '24') and `posttime` >= '1787500800' /* ms:tw591ms-cdc */;

• 库表：t591.sale；实例 alias：prod-591/master
• explain SQL：

SELECT * FROM `t591`.`sale` WHERE `status` = '2' LIMIT 10

• 执行计划（EXPLAIN 表节点，按 JOIN 顺序）：

• 慢因：扫描行数远大于返回行数(7,737/1)、EXPLAIN 全表扫描/未用索引
• 建议：补索引（按 WHERE 等值列在前、范围列收尾建复合索引）; 用 EXPLAIN 验证 key 命中
• 可执行 DDL（建议先在低峰期 EXPLAIN 验证再执行）：

ALTER TABLE `t591`.`sale` ADD INDEX `idx_status` (`status`);

5. select last_contacted_at, uid, is_sticked from im_conversations where conversation IN (?...) and uid != ? and im_conversations.deleted_at is null /* ms:hongyan- —— 1,886 次 × 2.84s = 1.49h

• 代表性 SQL：

select `last_contacted_at`, `uid`, `is_sticked` from `im_conversations` where `conversation` in (select `conversation` from `im_conversations` where `app_id` = '3' and `uid` = '1001' and `deleted_at` is null) and `uid` != '1001' and `im_conversations`.`deleted_at` is null /* ms:hongyan-web-server */

• 库表：?.im_conversations；实例 alias：None
• explain：未执行（无 alias(该 server 无可连 MCP 实例)）
• 慢因：IN (SELECT ...) 子查询(易退化为相关子查询逐行执行, 建议改 JOIN/EXISTS)
• 建议：改写为 JOIN/EXISTS 并验证子查询能下推; 该实例无 MCP 映射, 建议在库上手动 EXPLAIN 复核
• 可执行 DDL（建议先在低峰期 EXPLAIN 验证再执行）：

ALTER TABLE `im_conversations` ADD INDEX `idx_app_id_uid_conversati` (`app_id`, `uid`, `conversation`);

6. select * from (SELECT CURDATE() dt,count(DISTINCT user_id) ?, count(?) ? FROM t591.sale WHERE posttime>=UNIX_TIMESTAMP(?) and closed=? -- and status=? and end_t —— 1 次 × 4613.29s = 1.28h

• 代表性 SQL：

select *
from (SELECT CURDATE() dt,count(DISTINCT user_id) '会员数', count(1) '物件数' 
FROM t591.sale 
WHERE posttime>=UNIX_TIMESTAMP('2023-01-01') and `closed`=0 -- and `status`=2
and end_time>=UNIX_TIMESTAMP('2023-07-03') and user_id in (
SELECT DISTINCT user_id from t591.activity_plan_money where `type`=2 and sign=2 and `status`=1 and posttime<UNIX_TIMESTAMP('2023-07-03')
)
) as `T`
limit 0;

• 库表：t591.sale；实例 alias：prod-591/master
• explain SQL：

select *
from (SELECT CURDATE() dt,count(DISTINCT user_id) '会员数', count(1) '物件数' 
FROM t591.sale 
WHERE posttime>=UNIX_TIMESTAMP('2023-01-01') and `closed`=0 -- and `status`=2
and end_time>=UNIX_TIMESTAMP('2023-07-03') and user_id in (
SELECT DISTINCT user_id from t591.activity_plan_money where `type`=2 and sign=2 and `status`=1 and posttime<UNIX_TIMESTAMP('2023-07-03')
)
) as `T`
limit 0;

• 执行计划：（explain 未返回有效计划）
• 慢因：扫描行数远大于返回行数(703,424,935/0)、IN (SELECT ...) 子查询(易退化为相关子查询逐行执行, 建议改 JOIN/EXISTS)
• 建议：补索引（按 WHERE 等值列在前、范围列收尾建复合索引）; 用 EXPLAIN 验证 key 命中; 改写为 JOIN/EXISTS 并验证子查询能下推; 该实例无 MCP 映射, 建议在库上手动 EXPLAIN 复核
• 可执行 DDL（建议先在低峰期 EXPLAIN 验证再执行）：

ALTER TABLE `t591`.`sale` ADD INDEX `idx_closed_status_type_sign_user_id_posttime` (`closed`, `status`, `type`, `sign`, `user_id`, `posttime`);

7. select * from t591.sale where status = ? and closed = ? and community_id = ? and room = ? and id != ? order by posttime desc limit ?; —— 50 次 × 78.36s = 1.09h

• 代表性 SQL：

select * from `t591`.`sale` where `status` = 2 and `closed` = 0 and `community_id` = 34577 and `room` = 99 and `id` != 20559989 order by `posttime` desc limit 2;

• 库表：t591.sale；实例 alias：prod-591/master
• explain SQL：

select * from `t591`.`sale` where `status` = 2 and `closed` = 0 and `community_id` = 34577 and `room` = 99 and `id` != 20559989 order by `posttime` desc limit 2;

• 执行计划（EXPLAIN 表节点，按 JOIN 顺序）：

• 慢因：扫描行数远大于返回行数(20,047,324/2)、全索引扫描(sale: key=posttime, rows=5,538，缺更优过滤索引)
• 建议：补索引（按 WHERE 等值列在前、范围列收尾建复合索引）; 用 EXPLAIN 验证 key 命中; 扩复合索引: 把其余 WHERE 等值列追加到现有索引尾部, 避免 10 万+ 行回表
• 可执行 DDL（建议先在低峰期 EXPLAIN 验证再执行）：

ALTER TABLE `t591`.`sale` ADD INDEX `idx_status_closed_community__room` (`status`, `closed`, `community_id`, `room`);

8. select id, name, checkstatus, deleted, build_purpose from t591_new.market_community FORCE INDEX(idx_region_section) where status = ? and deleted = ? and checkst —— 1,508 次 × 2.26s = 56.7min

• 代表性 SQL：

select `id`, `name`, `checkstatus`, `deleted`, `build_purpose` from t591_new.market_community FORCE INDEX(`idx_region_section`) where `status` = '1' and `deleted` = '0' and `checkstatus` = '1' and `type` = '1' and `regionid` = '6' and `sectionid` = '67' /* ms:tw591ms-cdc */;

• 库表：t591_new.market_community；实例 alias：prod-591/master
• explain SQL：

select `id`, `name`, `checkstatus`, `deleted`, `build_purpose` from t591_new.market_community FORCE INDEX(`idx_region_section`) where `status` = '1' and `deleted` = '0' and `checkstatus` = '1' and `type` = '1' and `regionid` = '6' and `sectionid` = '67' /* ms:tw591ms-cdc */;

• 执行计划（EXPLAIN 表节点，按 JOIN 顺序）：

• 慢因：扫描行数远大于返回行数(105,747/1,472)、索引选择性差(market_community: key=idx_region_section 扫 117,616 行回表后仅剩 0.01%，建议把其余 WHERE 等值列并入复合索引)
• 建议：补索引（按 WHERE 等值列在前、范围列收尾建复合索引）; 用 EXPLAIN 验证 key 命中; 扩复合索引: 把其余 WHERE 等值列追加到现有索引尾部, 避免 10 万+ 行回表
• 可执行 DDL（建议先在低峰期 EXPLAIN 验证再执行）：

ALTER TABLE `t591_new`.`market_community` ADD INDEX `idx_status_deleted_checkstatu_type_regionid` (`status`, `deleted`, `checkstatus`, `type`, `regionid`);

逐条优化建议汇总

P 行 = 深析模式（指纹聚合，按全天累计耗时降序 P1 最大，是优化主战场）；T 行 = 单条耗时 Top3 的一次性慢 SQL（多为 bi/导出查询，治理手段通常是限流/降频/移到从库，而非建索引）。

*采集脚本 .agents/scripts/mysql_slow_prod_report.py，中间数据 outputs/slow_report_prod591_20260908.json；全程只读。*