tablesample 不适合审计抽样，因其不保证结果稳定可复现且无法前置过滤；审计需对满足条件的记录（如近30天支付失败订单）精确抽取固定百分比，应使用 row_number() + order by random() 实现可控等距随机抽样。
为什么 TABLESAMPLE 不适合审计抽样
SQL 标准里的 TABLESAMPLE（如 PostgreSQL 或 SQL Server 支持）是系统级随机采样，不保证结果集稳定可复现，且无法按业务条件过滤后再抽样——审计场景要求「对满足某条件的记录中抽取固定百分比」，比如「筛选出近30天所有支付失败订单，再随机取5%」。TABLESAMPLE 既不能前置过滤，也无法控制抽样基数，实际用起来容易漏掉关键子集或重复审计同一笔。
用 ROW_NUMBER() + ORDER BY RANDOM() 实现可控百分比抽样
核心思路：先对目标数据排序打序号，再用随机因子缩放序号范围，取模判定是否入选。关键是把「百分比」转成「每 N 行取 1 行」的等距逻辑，但用随机排序规避周期性偏差。
- PostgreSQL 示例：
SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY RANDOM()) AS rn FROM orders WHERE status = 'failed' AND created_at >= NOW() - INTERVAL '30 days' ) t WHERE t.rn % FLOOR(100.0 / 5) = 1;
这里5是目标百分比，FLOOR(100.0 / 5)得到20，即「每20行取第1行」 - MySQL 8.0+ 类似，但需用
RAND()替代RANDOM()，且注意ROW_NUMBER()必须配合窗口排序，否则序号不稳定 - SQLite 用
ORDER BY RANDOM()直接排序后加LIMIT只能控制总数，不能精确百分比；必须配合子查询算总数：SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY RANDOM()) AS rn FROM orders WHERE status = 'failed' ) t WHERE t.rn
抽样结果不可复现？加盐让 RANDOM() 变确定性
审计需要可回溯——同一查询在不同时间执行，必须返回相同样本集。直接用 ORDER BY RANDOM() 每次都变，解决办法是把业务字段哈希后作为随机种子。
- PostgreSQL 中可用
SETSEED()配合字段哈希：SELECT setseed(0.12345); -- 固定种子值 SELECT * FROM ( SELECT *, ROW_NUMBER() OVER (ORDER BY md5(id::text || 'audit_2024_q3')::uuid) AS rn FROM orders WHERE ... ) t WHERE t.rn % 20 = 1;
md5(id::text || 'audit_2024_q3')确保同一条记录每次哈希值不变，::uuid转成可排序格式 - 避免用时间戳、自增ID单独做盐——前者导致每天样本不同，后者导致新插入数据永远排在末尾，抽样倾斜
- MySQL 不支持
setseed()全局设置，得用ORDER BY CRC32(CONCAT(id, 'audit_2024_q3'))替代
大数据量下 ROW_NUMBER() 性能崩了怎么办
当筛选后仍剩百万行，ROW_NUMBER() OVER (ORDER BY ...) 会触发全排序，IO 和内存压力陡增。此时应换策略：用主键范围分段 + 概率过滤，牺牲一点均匀性换性能。
- 假设
orders.id是递增整型主键，且分布相对均匀：SELECT * FROM orders WHERE status = 'failed' AND created_at >= NOW() - INTERVAL '30 days' AND ABS(CRC32(id::text || 'audit_2024_q3')) % 100 这里 <code>% 100 等价于 5% 概率命中，无需排序，走索引快得多</code>
- 缺点：若 ID 存在大量空洞或集中写入（比如只写末尾），抽样会偏斜；此时可改用组合字段哈希，如
CRC32(CONCAT(user_id, created_at::date)) - 验证偏斜程度：跑一次抽样后查
SELECT COUNT(*), COUNT(*) * 100.0 / (SELECT COUNT(*) FROM ...) FROM (...) t，确认实际比例落在 ±0.3% 内即可接受
真正麻烦的是既要精确百分比、又要可复现、还要扛千万级数据——这时候就得放弃纯 SQL，把抽样逻辑下沉到应用层用 reservoir sampling 或分片哈希做，数据库只负责条件过滤和传输。
