NTILE在千万级表上直接使用易导致卡死，因其需全量排序+分桶计算，引发内存压力大、TempDB暴涨、执行时间不可控；应先查行数、建索引、避免大结果集，并慎用NULL及依赖ORDER BY的稳定性。
NTILE在千万级表上直接用会卡死？先看执行计划
NTILE本质是排序窗口函数，对千万行数据执行NTILE(100) OVER (ORDER BY id)时，SQL Server必须完成全量排序+分桶计算，内存压力大、TempDB暴涨、执行时间不可控。不是语法错，是设计使然——它没做任何采样优化，就是硬排。
实操建议：
- 先用
SELECT COUNT(*) FROM huge_table确认总行数，避免盲目开窗 - 在执行前加
SET STATISTICS IO ON，观察逻辑读是否突破百万级 - 如果
ORDER BY字段无索引，立刻建覆盖索引：CREATE INDEX IX_huge_table_id ON huge_table(id) - 别在SSMS里直接跑
SELECT *, NTILE(10) OVER (...) FROM huge_table——结果集太大可能让客户端崩溃
想抽1%样本？别用NTILE(100)，改用TABLESAMPLE
NTILE(100)不是“随机抽1%”，它是把有序数据切100份，每份大小取决于总行数和余数分配规则。比如999万行分100桶，第1桶有100,000行，第100桶只有99,900行——但你根本不知道哪桶对应哪段业务周期。
真正要近似随机抽样，优先用TABLESAMPLE：
SELECT TOP 10000 * FROM huge_table TABLESAMPLE (1 PERCENT)
注意点：
-
TABLESAMPLE基于数据页采样，不保证精确百分比，但速度是NTILE的百倍级 - 如果表有大量空页（比如频繁DELETE未收缩），实际返回行数可能偏少，可加
REPEATABLE确保可复现：TABLESAMPLE (1 PERCENT) REPEATABLE (42) - 它不能和
ORDER BY共存，如需后续排序，必须套子查询或CTE
需要稳定可复现的分桶？用哈希替代ORDER BY
业务常要求“同一用户每次查都在同一桶”，但NTILE(10) OVER (ORDER BY user_id)在数据增删后桶号会漂移——因为排序位置变了。更稳的方式是用哈希值构造伪序：
NTILE(10) OVER (ORDER BY ABS(CHECKSUM(user_id)) % 1000)
为什么有效：
-
CHECKSUM(user_id)把ID映射成整数，ABS(...)%1000生成0–999间稳定哈希值 - 只要
user_id不变，哈希值就不变，排序顺序就固定，NTILE分桶结果也就固定 - 比
ORDER BY NEWID()快得多，且不依赖随机种子 - 慎用
NEWID()哈希：它每次执行都不同，无法复现
抽样后还要统计？NTILE + 聚合容易踩NULL陷阱
当原始数据含大量NULL，NTILE(5) OVER (ORDER BY score)在SQL Server中会把NULL排最前，导致第一桶全是NULL行，后续桶分布失真。这不是bug，是ORDER BY默认行为。
安全写法只有两种：
- 显式过滤：
WHERE score IS NOT NULL再进NTILE，最干净 - 补值重排：
ORDER BY COALESCE(score, -999999)，但得确认-999999不会和真实数据冲突 - 绝对不要依赖
ISNULL(score, 0)——0可能是有效业务值，会污染分位统计
最后提醒一句：NTILE本身不校验数据分布。哪怕你分了10桶，如果90%的score集中在[0,10]区间，前9桶可能全空，最后一桶塞满——这种偏差得靠直方图或HISTOGRAM预分析，NTILE不管这个。
