NTILE()和WIDTH_BUCKET()不是脱敏工具，仅用于分布分析；批量脱敏必须用字符串函数组合（如CONCAT+LEFT+REPEAT）实现前缀+掩码+后缀逻辑，并通过自定义函数封装校验与复用。
NTILE() 和 WIDTH_BUCKET() 不适合直接做脱敏，它们是分布分析工具，不是脱敏手段。真正在 SQL 中对大批量数据做脱敏，靠的是字符串函数组合 + UPDATE 或 SELECT 表达式，窗口函数只在极少数特定场景下辅助脱敏逻辑（比如按用户分组后统一生成伪ID），但绝不能替代脱敏本身。
别指望 NTILE() 或 RANK() 做脱敏
常见误解：用 NTILE(100) OVER (ORDER BY user_id) 把用户分 100 组，再用组号代替原始 ID——这根本不是脱敏，只是简单分桶，组内仍可逆推排序关系，且无法控制输出格式（如固定长度、字母数字混合）。更危险的是，一旦原始字段有 NULL 或重复值，NTILE() 分组会偏移，导致相同用户在不同批次中被分到不同“桶”，破坏一致性。
-
NTILE()输出的是整数序号，不是掩码字符串，不能直接用于展示或导出 - 它不处理字符替换、截断、哈希等脱敏必需操作
- 若脱敏目标是手机号或身份证，强行套窗口函数只会让 SQL 变复杂、执行变慢、结果不可控
真正批量脱敏靠 CONCAT() + LEFT() + REPEAT()
MySQL 8.0+ 没有 MASK() 函数，也不存在所谓“内置脱敏窗口函数”。所有稳定、可复用的批量脱敏，都基于标准字符串函数拼装。核心逻辑是：取前缀 + 生成掩码 + 取后缀。
- 手机号（11位）：用
CONCAT(LEFT(phone, 3), REPEAT('*', 4), RIGHT(phone, 4))→138****5678 - 身份证（18位）：用
CONCAT(LEFT(id_card, 6), REPEAT('*', 8), RIGHT(id_card, 4))→110101********5678 - 必须加
WHERE CHAR_LENGTH(phone) = 11过滤异常数据，否则RIGHT(phone, 4)对短字段返回空，导致脱敏后全星或截断错位 - 字段含分隔符（如
138-1234-5678）要先REPLACE(phone, '-', '')，再脱敏
想复用？建自定义函数，别硬写表达式
每次 UPDATE 都复制一长串 CONCAT 很容易出错，也难维护。直接建函数，把规则收口：
- 创建函数时加长度校验：
IF LENGTH(phone) != 11 THEN RETURN phone;，避免脏数据污染结果 - 函数名明确用途，比如
mobile_mask()、idcard_mask()，别用泛义名如mask_data() - 函数体内避免嵌套过深，
SUBSTRING()和LEFT()在 MySQL 中行为一致，但SUBSTRING(str, -4)比RIGHT(str, 4)更易理解边界 - 注意字符集：函数声明里加
CHARSET utf8mb4，防止中文或 emoji 导致长度计算偏差
窗口函数唯一能帮上脱敏的点：生成一致性伪ID
只有当你要为每个用户分配一个稳定、不可逆、跨表一致的伪标识（比如做联邦分析或去标识化关联），才可能用到窗口函数配合哈希。例如：
SELECT
user_id,
CONCAT('U', LPAD(MD5(user_id) % 1000000, 6, '0')) AS pseudonym
FROM users;
但这本质是哈希派生，MD5() 才是核心，LPAD() 只是格式化；窗口函数在这里毫无用武之地。真要用窗口，最多是 DENSE_RANK() OVER (ORDER BY MD5(user_id)) 强制整数映射，但会丢失哈希抗碰撞能力，且无法保证不同批次结果一致——所以生产环境几乎不用。
真正容易被忽略的点：脱敏后字段若参与后续 PARTITION BY 或 GROUP BY，必须确认脱敏值的基数是否合理。比如用 SHA2(user_id, 256) 当伪ID，那它就是高基数列，窗口函数开窗效率会断崖下降；而用 CASE WHEN age BETWEEN 20 AND 29 THEN '20s' 这种低基数脱敏，则完全没问题。
