ROW_NUMBER() 做比例抽样易错，因其依赖确定性排序，而 NEWID() 在同一行多次调用值不一致导致排序不稳定；且窗口函数无法在同级查询中动态获取总行数以计算百分比阈值。
用 ROW_NUMBER() 做比例抽样为什么容易出错
直接对全表加 ROW_NUMBER() OVER (ORDER BY NEWID()) 再取前 N% 会失效——因为 ROW_NUMBER() 是确定性函数，而 NEWID() 在同一行中多次调用可能生成不同值，导致排序不稳定；更关键的是，百分比计算必须基于总行数，但窗口函数无法在同一个查询层级里动态获取总行数用于除法。
常见错误写法：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY NEWID()) AS rn FROM t) t2 WHERE rn —— 这条语句语法合法，但 <code>COUNT(*) OVER () 返回的是每行的相同总数，看似可行；问题在于：如果表很大，ORDER BY NEWID() 强制全局排序，性能极差，且 ROW_NUMBER() 本身不保证随机性（仅靠 ORDER BY NEWID() 模拟，但 SQL Server 中它确实常用）。
- 真正可靠的随机抽样应避免依赖
ROW_NUMBER()+ 全局排序 -
TABLESAMPLE更快，但不支持精确百分比（只接受页级或行级近似），且 PostgreSQL 不支持该语法 - 需要跨数据库兼容时，
ORDER BY RANDOM()（PostgreSQL）或ORDER BY NEWID()（SQL Server）+LIMIT / TOP是更直接的选择
SQL Server 中用 NEWID() 和 TOP 实现 10% 抽样
这是最常用、最高效的方式，不依赖窗口函数，也不需要预查总行数。
示例（抽取约 10% 行）：
SELECT TOP (10) PERCENT * FROM orders ORDER BY NEWID();
-
TOP (10) PERCENT是 SQL Server 特有语法，会向下取整到最近整数行（如 999 行表取 99 行） -
ORDER BY NEWID()为每行生成唯一 GUID，实现伪随机排序，开销比ROW_NUMBER()小得多 - 不能写成
TOP (0.1 * COUNT(*))——TOP后不接受表达式（除非用变量或动态 SQL） - 若需严格控制抽样比例（比如必须恰好 N 行），先算好
@n = CEILING(0.1 * @total)，再用TOP (@n)
PostgreSQL 中用 RANDOM() + LIMIT 替代 ROW_NUMBER()
PostgreSQL 没有 TOP PERCENT，但 RANDOM() 是稳定、可索引跳过的伪随机函数，配合 LIMIT 效率很高。
示例（抽取约 15%）：
SELECT * FROM logs ORDER BY RANDOM() LIMIT (SELECT CEILING(COUNT(*) * 0.15) FROM logs);
- 子查询
(SELECT CEILING(...))必须单独执行一次，不能写成LIMIT COUNT(*) * 0.15（语法错误） - 如果表极大，两次扫描（一次算总数、一次排序抽样）代价高；此时可用估算行数：
SELECT reltuples::BIGINT FROM pg_class WHERE relname = 'logs'，避免全表扫描 - 注意：不要用
WHERE RANDOM() ——这虽快，但不是“抽样”，而是概率过滤，实际返回行数方差大（尤其小表），不满足「固定比例」需求
为什么硬套 ROW_NUMBER() 做比例筛选是自找麻烦
有人试图写：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY NEWID()) AS rn, COUNT(*) OVER() AS cnt FROM t) t2 WHERE rn 。逻辑上没错，但实际问题很多：
- 强制对全表排序，
ORDER BY NEWID()在大数据集上极易内存溢出或超时 - 窗口函数
COUNT(*) OVER()虽然避免了自连接，但仍需缓存全部中间结果，内存占用翻倍 - MySQL 8.0+ 不支持
NEWID()，得改用RAND()，但RAND()在窗口函数中行为不可靠（可能被优化为常量） - 真正需要「按分组内比例抽样」时，
ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)才有意义；全局比例抽样，它只是绕远路
核心就一点：比例抽样本质是「选行」，不是「编号再筛号」。用排序+截断（TOP/LIMIT）或概率预过滤（慎用），比先编号再比较更贴近执行引擎的优化路径。
