generated column 不等于数据脱敏，因其仅固化脱敏逻辑，原始字段仍明文可查、权限未变、备份和慢日志中照常暴露；它适合索引加速或视图替代，但须配合字段拆分、视图封装和权限控制才真正保障安全。
直接用 GENERATED COLUMN 做脱敏，不能保障查询安全——它只是把脱敏逻辑固化到表结构里，原始字段依然明文可查，权限没变、备份没变、慢查询日志里照样暴露。
为什么 GENERATED COLUMN 不等于数据脱敏
很多人误以为定义一个虚拟生成列（VIRTUAL）就能“自动脱敏”，比如：
ALTER TABLE users ADD COLUMN phone_masked VARCHAR(13) AS (CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4))) STORED;
这看起来干净，但问题很实在：
-
phone字段本身仍完整存在，任何有SELECT权限的用户都能直接查出明文 -
STORED列会物理存储，占用空间且可能被mysqldump导出为真实值 -
VIRTUAL列虽不存盘，但执行SELECT phone FROM users时，原始值毫无遮挡 - 权限系统对生成列无特殊控制，
GRANT SELECT(phone_masked) ON ...不生效，MySQL 不支持按生成列授权
GENERATED COLUMN 的真实适用场景
它适合做「只读视图替代品」或「索引加速字段」，前提是原始字段已受控。例如：
- 已有严格行级权限（如通过
ROW POLICY或应用层拦截），仅需统一展示格式 - 想对脱敏后字符串建索引（如按前3位手机号分组统计），避免每次
CONCAT(LEFT(...))计算 - 配合
VIEW使用：建视图只暴露phone_masked，再给开发账号只授该视图权限
单独加一列，不改访问路径、不收权限、不删原字段，就谈不上“保障查询安全”。
真正能限制原始字段暴露的组合动作
如果坚持用 MySQL 原生能力最小化改造，必须叠加三层控制：
- 把敏感字段（如
phone）从公开表中移出，拆到独立表（如user_sensitive），主表只留user_id - 对敏感表启用
DEFINER视图或存储过程封装查询，禁止直接SELECT * FROM user_sensitive - 用
GENERATED COLUMN在主表上提供轻量掩码字段（如phone_hint），但它的值必须来自脱敏逻辑而非原始字段——比如存MD5(CONCAT(user_id, salt))做伪匿名标识，而非LEFT(phone,3)
否则，EXPLAIN FORMAT=TREE 一眼就能看出执行计划里是否真的避开了原始字段；而 SHOW CREATE TABLE 会直接暴露生成逻辑依赖了哪个明文列——这才是容易被忽略的硬伤。
