Sequelize 分页性能检查清单

后台列表的分页性能，前期常常给人一种“问题不大”的错觉。因为数据量小时，任何写法都像能跑。一旦线上数据变多，再叠加排序、过滤和关联，分页接口很快就会成为慢查询集中地。

我比较常用的检查清单大概有这几项：

• 排序字段是否命中了索引。
• offset 是否已经大到不适合继续深分页。
• 明细是否只选择了页面真正需要的字段。
• 关联关系是否能改成延迟查询或预聚合。

如果接口已经开始出现抖动，我通常先把 SQL 打出来看，而不是盲目在应用层做缓存。因为分页慢的核心，往往还是查询结构本身不够克制。

Sequelize 不会自动给你性能，真正稳的分页接口，都是靠字段裁剪、索引意识和分层查询一起守出来的。

为什么这类问题总会在线上阶段突然变贵

围绕「Sequelize 分页性能检查清单」这类判断，最容易被低估的地方，是大家前期总把它当成 ORM 写法偏好，而不是数据契约和查询边界。数据量小、调用方少的时候，字段命名、关联深度、分页方式、迁移顺序都像只是风格问题；一旦接口被更多页面复用，筛选、排序、统计和审计需求一起叠上来，之前没收住的边界就会同时在性能、排障和协作成本上爆出来。

落地时我会先卡住的检查项

• 先把输入 DTO、模型字段和最终 SQL 这三层对应关系看清，避免“接口语义已经变了，ORM 代码却还在偷偷兜底”。
• 把统计、明细、写操作和回滚路径拆开看，别让一个方便的查询顺手背上太多职责。
• 一旦这篇文章讨论的点已经影响到索引、事务或迁移顺序，就说明它不是微调，而是该补正式约束了。