SQL Server分页首选OFFSET-FETCH，需配合ORDER BY且参数化传值；EF Core用Skip/Take自动翻译，避免内存分页；大数据量时应改用游标分页。

SQL Server 中用 OFFSET-FETCH 做分页最直接

说到在SQL Server里做分页，2012及以上版本提供的OFFSET-FETCH子句，无疑是那个最标准、最清晰的选项。它语义一目了然，写法也足够简洁，完全可以作为首选方案。比起依赖ROW_NUMBER()函数或者写复杂的嵌套子查询，它的执行计划通常也更优。

不过，这里有个常见的“坑”得留意：千万别把OFFSET和FETCH的顺序写反了，更别忘了ORDER BY子句——它是必须存在的，否则数据库会直接报错"The OFFSET clause is missing in the ORDER BY clause."。

• 标准写法是：OFFSET @skip ROWS FETCH NEXT @take ROWS ONLY。其中，@skip = (页码 - 1) * 每页大小，@take = 每页大小。
• 注意，OFFSET值为0是合法的，但不能为负数；FETCH则必须是个正整数。
• 如果排序字段存在重复值，分页结果可能会出现“漂移”，变得不稳定。一个稳妥的规避方法是：在ORDER BY子句末尾，追加一个唯一列（比如主键）。

Entity Framework Core 中用 Skip() 和 Take() 就够了

如果你在用Entity Framework Core，事情就简单多了。直接使用Skip()和Take()这两个方法，框架会自动帮你翻译成底层数据库对应的分页语法——SQL Server对应OFFSET-FETCH，MySQL对应LIMIT，PostgreSQL对应LIMIT-OFFSET。这意味着，你完全不必手动去拼接那些SQL字符串。

但这里有个性能“杀手”需要警惕：那就是在内存中进行分页。具体来说，就是先调用ToList()或ToListAsync()把所有数据拉到内存里，然后再进行Skip和Take操作。一旦数据量大了，这种操作会导致整个数据集被完整加载，响应速度会急剧下降。

• 务必确保Skip()和Take()是在IQueryable上调用，并且要在最终的ToListAsync()执行之前。
• 避免在Where条件筛选后，紧接着调用AsEnumerable()或ToList()，然后再分页。
• 如果需要动态构建查询条件，尽量保持IQueryable的链式传递，不要提前触发查询执行。

手写 ADO.NET 分页要防 SQL 注入和类型转换失败

当需要手写ADO.NET代码进行分页时，安全性和健壮性就成了首要考量。直接使用字符串拼接来构造SQL（比如"... LIMIT " + pageSize）是极不安全的做法，也为后期维护埋下隐患。正确的做法是：全部使用参数化查询，包括OFFSET和FETCH的数值。

一个常见的错误是把页码或页大小当作字符串类型的参数传递，这会导致SQL报错，例如"Incorrect syntax near '@offset'"。原因在于，SQL参数只能用于代表值，不能用于替代关键字或语法结构的位置。

• 在SQL Server中：使用OFFSET @skip ROWS FETCH NEXT @take ROWS ONLY，并确保参数类型为int。
• 在MySQL中：使用LIMIT @take OFFSET @skip，同样使用MySqlParameter，并且OFFSET参数必须为整数类型（不能是long或string）。
• 记住，永远不要试图用string.Format或者字符串插值（$""）来拼接分页参数，这是一个高危操作。

大数据量下 OFFSET 性能会明显下降

当数据量非常庞大时，OFFSET分页的短板就会暴露出来。想象一下，当OFFSET值变得很大（例如要查询第10000页，每页20条，那么OFFSET就是199980），数据库引擎仍然需要扫描并跳过前面所有的行，这会导致IO和CPU开销急剧上升。

这个问题在C#应用层是无法解决的，但开发者必须清楚何时应该切换策略。这时，“游标分页”（cursor-based pagination）就派上用场了。它的核心思路是：利用上一页最后一条记录的排序字段值，作为查询下一页的起点。

• 这种分页方式特别适合时间线类列表（按CreateTime DESC排序）或者ID有序增长的场景。
• 典型的写法是：WHERE CreateTime
• 它的局限性在于无法直接跳转到任意指定页，但对于大多数只需要“上一页”、“下一页”操作的前端分页控件来说，这恰恰是匹配的。其优势在于首屏加载快、翻页性能稳定，不会出现深度分页时的性能断崖。

话说回来，在实际项目中，90%的分页需求使用EF Core的Skip/Take组合就完全能够胜任。如果真的遇到了需要在百万级数据中深度翻页的场景，那么问题的关键可能不在于OFFSET怎么写更快，而是需要重新审视整个查询逻辑的设计了。