延迟关联在存储过程中需确保子查询仅查主键、WHERE与ORDER BY共用联合索引（如(status,create_time)），外层用INNER JOIN主键匹配，禁用IN子查询和动态SQL，避免全表扫描与执行计划失效。
延迟关联在存储过程中怎么写才不翻车
直接把 LIMIT offset, size 塞进存储过程里，等于把性能炸弹包进业务逻辑。MySQL 存储过程本身不缓存执行计划，每次调用都重新解析 SQL，如果还带着大 OFFSET，查询会越跑越慢、越调越卡。关键不是“能不能写”，而是“怎么组织才能让优化器真正走索引+减少回表”。
- 子查询必须只查主键（如
id），且WHERE和ORDER BY字段要落在同一个联合索引里，比如(status, create_time)；否则子查询就退化成全表扫描 - 外层
JOIN必须用主键等值匹配，不能写成IN (SELECT ...)—— 后者在 MySQL 5.7+ 虽有优化，但面对千万级仍可能触发临时表或文件排序 - 避免在存储过程中拼接动态 SQL（如
CONCAT+EXECUTE），这会让预编译失效，也难以被监控工具识别慢查询来源
为什么存储过程里用游标分页比 LIMIT 更稳
存储过程天然适合维护状态，而游标分页（WHERE id ）不需要计算 <code>OFFSET，也就绕开了 MySQL 扫描前 N 行的硬伤。但要注意：这不是“换种写法就行”，而是整个分页语义的切换。
- 必须保证排序字段单调可比较：自增
id最安全；若用create_time，得组合(create_time, id)避免毫秒级重复导致漏/重数据 - 存储过程里建议用
INOUT参数接收上一页最后一条的游标值（如@last_id），再用它构造WHERE条件，而不是在应用层拼好 SQL 再传进来 - 无法支持“跳到第 1000 页”这种需求——如果业务强依赖跳页，说明游标模式不适用，别硬套
参数传入和索引失效的隐蔽坑
存储过程里看起来只是传了几个 IN 参数，但稍不注意就会让索引完全失效。常见错误不是语法错，而是执行计划悄悄变糟。
-
WHERE status = @status看似没问题，但如果@status是字符串类型而字段是TINYINT，MySQL 会隐式转换，导致idx_status_created索引失效 - 不要在
WHERE中对字段做函数操作，比如DATE(create_time) = @date，哪怕create_time有索引也没用 - 联合索引顺序必须匹配：如果建的是
(status, create_time)，那WHERE create_time > ? AND status = ?就只能用到status的等值部分，create_time的范围条件会被忽略
什么时候该放弃存储过程改用应用层分页
不是所有分页都适合塞进存储过程。当出现以下任一情况时，硬塞进去只会增加维护成本和故障点：
- 筛选条件超过 5 个，且来自多表 JOIN（比如订单列表要联查用户性别、地址、优惠券状态）—— 存储过程里写复杂 JOIN 容易锁表、难调试
- 需要对结果做聚合、去重或字段计算（如
IF(status=1, '已支付', '待付款')）—— 这些逻辑放应用层更灵活，也方便加缓存 - 分页接口要支持前端任意排序字段切换（
ORDER BY name/ORDER BY amount）—— 存储过程没法动态建索引，每换一个字段就得新建一套逻辑
真正容易被忽略的点是：延迟关联能提速，但前提是子查询返回的 ID 集合足够小。如果 WHERE 条件太宽（比如 status IN (1,2,3,4)），子查询仍可能扫几十万行 ID，这时候再快的 JOIN 也救不了。先收窄条件，再谈优化。
