权限管理本身不加密，但它是加密策略落地的前提
很多人误以为给用户加了密码就等于“加密保护”，其实密码存储只是起点。MySQL 的
password字段在 5.7+ 默认用
caching_sha2_password插件哈希存储（非对称加密），但这只防拖库，不防中间人窃听——如果用户权限过大、又走明文连接，攻击者拿到账号后直接连上就能查所有库。所以权限最小化不是“锦上添花”，而是让哪怕加密链路被绕过（比如应用层日志泄露凭证），攻击者也拿不到关键数据。
GRANT 语句里藏着加密连接的开关
MySQL 允许在创建用户或授权时强制要求 SSL/TLS，这不是可选配置项，而是权限语句的一部分。没写这句，用户就能用明文连；写了，客户端不支持 SSL 就直接拒绝登录。
CREATE USER 'api_user'@'%' IDENTIFIED BY 'P@ssw0rd' REQUIRE SSL;—— 强制加密传输
GRANT SELECT ON sales.* TO 'report_user'@'%' REQUIRE X509;—— 还要验证客户端证书 漏掉
REQUIRE子句？那
validate_password插件再强，数据在网线里也是裸奔
列级权限 + AES_DECRYPT 是敏感字段的兜底方案
当业务必须存身份证号、手机号这类字段，又无法全库启用 TDE（透明数据加密）时，就得靠权限+函数组合防御：把原始值用
AES_ENCRYPT()存进 BLOB 字段，再通过列级权限锁死访问路径。 只给应用账号
SELECT(id, name, AES_DECRYPT(phone_enc, 'key'))权限，不给
SELECT(phone_enc)直接读密文的权限 DBA 账号也不能绕过——因为
AES_DECRYPT需要密钥，而密钥不该存在 SQL 里，应由应用侧注入 注意坑：
AES_DECRYPT返回
NULL不报错，如果密钥错或字段为空，查出来就是空值，容易掩盖解密失败
角色（ROLE）是统一加密策略的杠杆支点
MySQL 8.0 的
ROLE不是权限分组工具，而是加密治理的执行单元。比如你上线了新合规要求：“所有访问用户表的连接必须启用 SSL 且禁止导出”。这时不用逐个改 20 个用户，只需：
CREATE ROLE 'pii_access';
GRANT SELECT (id, name, email) ON app.users TO 'pii_access' REQUIRE SSL;
GRANT 'pii_access' TO 'webapp'@'%', 'bi_tool'@'%';
之后只要调整角色定义，所有绑定用户自动继承新安全约束——这种集中管控能力，才是权限和加密真正咬合的关键位置。
权限体系越细，加密越有实际意义；反过来，没权限隔离的加密，只是给攻击者多加一道解密步骤。最常被忽略的，其实是
REQUIRE SSL和
REQUIRE X509在 GRANT 里的位置：它必须跟在权限目标后面、用户主体前面，顺序错了就无效。
