SQL Server 中 TOP 必须紧跟 SELECT 关键字，不可置于 WHERE 或 ORDER BY 后；支持常量、变量（需括号）及表达式；无 ORDER BY 时结果无序；TOP PERCENT 按 FLOOR(总行数×百分比) 取整，小数据集易返回空集。
TOP 在 SELECT 语句中必须紧跟 SELECT 关键字
SQL Server 的 TOP 不是独立子句，也不能放在 WHERE 或 ORDER BY 后面。它必须紧接在 SELECT 之后，否则会报错 Incorrect syntax near 'TOP'。
常见错误写法：SELECT * FROM users WHERE age > 25 TOP 10 —— 这会直接语法报错。
正确写法示例：
SELECT TOP 10 * FROM users WHERE age > 25 ORDER BY created_at DESC
-
TOP后可跟常量（如10）、变量（需用括号包裹，如TOP (@n)）或表达式 - 若未加
ORDER BY，返回的“前 N 条”是无序的，实际取决于数据页物理顺序，每次执行结果可能不同 - 使用变量时，必须先声明并赋值，且该变量作用域需覆盖整个查询
TOP PERCENT：按比例取数时要注意向下取整
TOP 10 PERCENT 看似直观，但 SQL Server 会对计算结果向下取整——比如表有 13 行，10 PERCENT 是 1.3，最终只返回 1 行，不是 2 行。
这在小数据集上容易引发预期外的空结果或过少数据。
- 实际取数行数 =
FLOOR(总行数 × 百分比)，结果为 0 时返回空集 - 若需“至少 1 行”，建议改用
TOP (CASE WHEN COUNT(*) * 0.1 （需配合窗口函数或子查询） -
TOP PERCENT不能与变量混用，即不支持TOP @pct PERCENT，会报错Incorrect syntax near '@pct'
带 ORDER BY 的 TOP 查询可能影响执行计划选择
看似只是加个排序，但 SQL Server 优化器看到 TOP + ORDER BY 时，往往会优先尝试索引排序（Index Seek + Top N Sort），而非全表扫描后排序。这意味着：如果 ORDER BY 字段没有索引，性能反而可能更差。
- 检查执行计划中是否出现
Top N Sort算子，以及其预估开销占比 - 若经常按
created_at DESC取最新 N 条，应在该列建降序索引：CREATE INDEX IX_users_created_at_desc ON users(created_at DESC) - 注意：含
TOP的查询在视图或内联表值函数中默认不可更新（UPDATE/DELETE 会报错View or function is not updatable）
替代方案：OFFSET-FETCH 更适合分页，但 TOP 仍更适合简单取头
SQL Server 2012+ 支持 OFFSET-FETCH，但它本质是“跳过 M 行再取 N 行”，而 TOP N 是最轻量的“取头 N 行”。两者适用场景不同，别为了“新”而强行替换。
- 只要需求是“取最新 5 条公告”，用
TOP 5 ... ORDER BY publish_time DESC就够了，别写OFFSET 0 ROWS FETCH NEXT 5 ROWS ONLY -
OFFSET-FETCH在大偏移量（如OFFSET 100000）时性能明显下降，而TOP始终稳定 -
TOP支持在 INSERT/UPDATE/DELETE 中使用（如DELETE TOP (100) FROM logs），OFFSET-FETCH不支持
真正容易被忽略的是：当查询涉及 JOIN 且未明确指定 TOP 作用范围时，它限制的是最终结果集行数，不是某张表的行数——这点在多对多关联或存在重复匹配时，会导致意料之外的数据截断。
