MySQL 8.0+ 社区版不自带 data_masking 插件，仅企业版提供；社区版需用生成列、视图或应用层脱敏，且必须严格管控基表 SELECT 权限。
MySQL 8.0+ 自带 data masking 插件能直接启用吗？
不能直接用。MySQL 官方的 data_masking 插件（位于 lib/plugin/data_masking.so）仅在 MySQL Enterprise Edition 中提供，社区版默认不包含，强行 INSTALL PLUGIN 会报 Plugin 'data_masking' is not loaded 或找不到共享库。
- 确认版本和版本类型：运行
SELECT VERSION(), @@version_comment;，看到MySQL Community Server就说明没这个插件 - 企业版用户需先检查插件路径是否在
plugin_dir下，再执行INSTALL PLUGIN data_masking SONAME 'data_masking.so'; - 社区版别折腾插件名，它不存在——这不是配置问题，是功能缺失
社区版替代方案：用生成列 + 函数实现字段级脱敏
最轻量、可控性最强的做法是把脱敏逻辑写进查询或视图，配合生成列（Generated Column）固化规则。比如手机号只显示前3后4，用 CONCAT 和 SUBSTR 就够用，无需额外组件。
- 对已有表加虚拟生成列：
ALTER TABLE users ADD COLUMN phone_masked VARCHAR(13) AS (CONCAT(SUBSTR(phone,1,3), '****', SUBSTR(phone,-4))) STORED; - 查询时直接用：
SELECT name, phone_masked FROM users;，避免每次手写脱敏表达式 - 注意
STORED比VIRTUAL多一次计算但支持索引；若字段常更新，VIRTUAL更省空间 - 敏感字段如身份证号，别用
SUBSTR(id_card, 1, 6)这类简单截断——前6位是地区码，仍有泄露风险；应统一用REPEAT('*', LENGTH(id_card)-4)遮掩中间
应用层脱敏比数据库层更可靠吗？
是的，尤其在社区版环境下。数据库层脱敏容易绕过（比如用 SELECT *、导出全量、连接池直连），而应用层在 ORM 查询后、返回前做处理，控制粒度更细，也更容易审计和灰度。
- Spring Boot 可用
@JsonSerialize注解定制序列化逻辑，对phone字段自动转成138****1234 - Node.js 的
class-transformer支持@Transform装饰器，比 SQL 表达式更易测试和复用 - 警惕“伪脱敏”：比如前端 JS 做格式化，原始数据仍从 API 响应体明文返回，抓包即得——脱敏必须发生在服务端响应组装阶段
- 若用 MyBatis，别在
resultMap里写CONCAT(...)，那只是 SQL 层面的临时处理，下游拿到的仍是原始值
为什么不要依赖触发器或视图做脱敏？
因为它们无法阻止直接查基表，且维护成本高、性能影响隐蔽。一个 BEFORE UPDATE 触发器想自动清洗身份证号，反而会让 INSERT INTO ... SELECT 失效或报错。
- 视图可以封装脱敏逻辑，但用户只要知道基表名，
SELECT * FROM users就绕过了视图 - 触发器修改字段值会导致 binlog 内容与业务预期不符，主从同步或闪回时可能出问题
- MySQL 8.0 的角色权限（
CREATE VIEW,SHOW VIEW）不能限制对基表的 SELECT，权限模型本身不支持“只允许查视图” - 真正需要强隔离的场景（如多租户），应该用行级安全策略（RLS）——但 MySQL 目前不支持，得靠应用层 WHERE 条件或分库分表
脱敏不是加个插件就完事。社区版没有 magic plugin，所有“自动脱敏”本质都是显式表达式或代码逻辑。最容易被忽略的是权限链路：即使视图/生成列设好了，只要账号有基表 SELECT 权，脱敏就形同虚设。
