TOP是SQL Server专用的行数限制子句，语法为SELECT TOP n|n PERCENT，必须位于SELECT后、WHERE前；不支持偏移，需用OFFSET-FETCH或ROW_NUMBER()实现分页；依赖执行计划与索引设计，无序或无索引排序时性能不可控。
TOP 是 SQL Server 专用的行数限制关键字，不能直接替换为 LIMIT 或 ROWNUM。它必须出现在 SELECT 语句开头，且语法和行为与 MySQL、Oracle 等数据库有本质差异。
TOP 后面跟数字还是 PERCENT？
两者都合法，但语义不同，选错会导致结果意外截断或膨胀：
-
TOP 10：固定取前 10 行（实际返回行数 ≤ 10） -
TOP 10 PERCENT：取结果集总行数的向上取整值（比如查出 95 行，10 PERCENT就是 10 行；查出 96 行，就是 10 行；查出 97 行，仍是 10 行；到 100 行才变成 10 行——等等，不对：10% of 100 = 10，10% of 101 = 11 —— 所以它是按实际执行时的估算行数向上取整，不是四舍五入） - 没有
ORDER BY时，TOP返回顺序不确定，哪怕表有聚集索引也不保证稳定 -
PERCENT模式下，若查询无结果（0 行），TOP 10 PERCENT仍返回 0 行；但若中间某步估算为 1 行，10% 就是 1 行——所以它依赖优化器的基数估算，生产环境慎用于分页逻辑
为什么 TOP 不能直接做“跳过 N 行”？
SQL Server 原生不支持 OFFSET 语法（直到 SQL Server 2012 才引入 OFFSET-FETCH，但 TOP 本身不带偏移能力）。直接写 SELECT TOP 10 * FROM t ORDER BY id 只能拿头 10 条；想取第 11–20 条，必须绕路：
- 老办法（兼容 SQL Server 2005+）：
ROW_NUMBER()+ CTE - 新办法（SQL Server 2012+ 推荐）：
OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY - 误用
TOP拼接子查询（如SELECT TOP 10 * FROM (SELECT TOP 20 ... ORDER BY x) t ORDER BY x DESC）在数据重复、排序字段非唯一时极易翻车
TOP 和 WHERE 能否共存？顺序怎么写？
可以共存，但 TOP 必须紧贴 SELECT，WHERE 在它之后。常见错误是把 TOP 当成函数或后缀写错位置：
- ✅ 正确：
SELECT TOP 5 name FROM users WHERE status = 'active' ORDER BY created_at DESC - ❌ 错误：
SELECT name FROM users WHERE status = 'active' TOP 5 ORDER BY created_at DESC（语法报错） - ❌ 错误：
SELECT name, TOP 5 created_at FROM users（TOP不是列修饰符） - 注意：
TOP作用于最终结果集，WHERE先过滤，再取前 N 行；如果希望“先取前 N 再过滤”，得用派生表或 CTE 包一层
性能陷阱：TOP 配合无序查询真的快吗？
很多人以为 SELECT TOP 1 一定极快，其实不然：
- 没
ORDER BY时，SQL Server 可能走堆扫描或任意索引，但无法提前终止——它仍需确认“是否真只有一行满足条件”，尤其当WHERE条件选择率低时 - 有
ORDER BY但排序字段无索引：必须先排序全部数据，再取头 N 行，TOP不减少排序开销 - 真正高效的
TOP查询，必须满足：有覆盖索引 +WHERE过滤高效 +ORDER BY字段在索引中前置且有序 - 例如：
SELECT TOP 1 id FROM orders WHERE customer_id = 123 ORDER BY order_date DESC，若索引是(customer_id, order_date DESC, id)，就能索引 Seek + 最多读 1 行
TOP 看似简单，但它的执行计划依赖性极强，同一语句在不同数据分布、统计信息、索引状态下可能产生完全不同的 IO 和 CPU 消耗。别只看语法对不对，一定要看实际执行计划里的“实际行数”和“预估行数”是否接近，否则很容易在线上突然变慢。
