ntile函数需配合order by rand()等随机排序才能实现比例抽样，其本身仅等份切分已排序数据；直接ntile(10) over()因依赖物理顺序而不可控；ntile(n)不保证每桶严格1/n，存在分配偏差。
NTILE 函数本身不随机，必须配合 ORDER BY RAND() 才能实现比例抽样
NTILE 只负责把已排序的数据**等份切分**，它不关心顺序来源。如果你直接写 NTILE(10) OVER()，数据库会按物理存储或默认游标顺序分桶——这既不可控，也不随机。真正实现“按比例抽样”，关键在 ORDER BY RAND()（MySQL/PostgreSQL）或 ORDER BY NEWID()（SQL Server）先打乱行序。
- MySQL / PostgreSQL：必须写成
NTILE(10) OVER (ORDER BY RAND()) - SQL Server：用
NTILE(10) OVER (ORDER BY NEWID()) - BigQuery：
RAND()可直接用于ORDER BY，但注意NTILE在窗口函数中要求显式ORDER BY，缺了会报错"Window function NTILE requires an ORDER BY clause" - Oracle 不支持
RAND()，得用DBMS_RANDOM.VALUE，且需注意该函数在窗口中多次调用可能不一致，建议先用子查询生成随机值再分桶
抽 20% 样本？别直接用 NTILE(5) 然后取 bucket = 1
这么做看似合理，但实际有偏差：NTILE(n) 是「尽量均分」，不是「严格每份 1/n」。当总行数不能被 n 整除时，前面的桶会多 1 行。比如 103 行数据跑 NTILE(5)，结果是 21, 21, 21, 20, 20 —— 第一个桶占 20.4%，不是精确 20%。更严重的是，如果只取 bucket = 1，你拿到的是“被分配到第一个位置的那批”，它和随机性无关，只是排序后最靠前的一组。
- 要严格控制比例，优先考虑
WHERE RAND() （MySQL）或 <code>WHERE RANDOM() （PostgreSQL）这类过滤方式 - 若必须用
NTILE（例如需保证每个样本组大小相近），应接受其固有偏差，并用COUNT(*)校验各桶实际占比 - 避免对大表反复执行
ORDER BY RAND()—— 它会强制全表排序，性能极差；可先用主键采样（如WHERE id IN (SELECT id FROM t ORDER BY RAND() LIMIT 10000)）再分桶
NTILE 配合 RAND() 在不同数据库的写法差异很实在
同一逻辑，在不同系统里连函数名和行为都不同，硬套会报错。
- MySQL 8.0+：支持
NTILE(10) OVER (ORDER BY RAND())，但RAND()在窗口函数中是逐行求值，安全 - PostgreSQL：
RANDOM()是等价替代，写法同上；但注意它不能出现在GROUP BY或聚合上下文中 - SQL Server：
NEWID()每次调用返回唯一 GUID，天然适合打乱，但不能用NEWID()做计算字段后复用（比如先SELECT *, NEWID() AS r FROM t再OVER (ORDER BY r)），否则窗口函数可能因延迟计算导致结果不一致 - BigQuery：
RAND()可用，但NTILE必须带ORDER BY，且不支持ORDER BY RAND() OVER()这种错误语法；正确写法是NTILE(10) OVER (ORDER BY RAND())
真正需要“可复现的随机抽样”时，NTILE + RAND() 就不够用了
比如 A/B 测试要求每次跑 SQL 都抽到同一组用户，或者审计场景下需留痕。这时 RAND() 每次执行都变，无法回溯。
- MySQL 可用
RAND(种子值)，如RAND(42)，但注意：该种子只影响单条语句内调用，且不同 MySQL 版本对窗口中RAND(42)的行为不一致 - PostgreSQL 推荐用
setseed()配合random()，但必须在事务内设置，且NTILE窗口仍无法保证跨执行一致性 - 稳妥做法是加一列确定性哈希，例如
MOD(ABS(HASH(id)), 100) 来抽 20%，哈希函数选 <code>FARM_FINGERPRINT（BigQuery）、MD5（PostgreSQL）或CONV(SUBSTR(MD5(id), 1, 8), 16, 10)（MySQL）
用 NTILE 做比例抽样，本质是借它的“分组能力”，而不是“随机能力”。随机性完全依赖 ORDER BY 子句提供的顺序，这点容易被忽略，也最难调试。
