核心手段是应用层加密、列级权限隔离与审计兜底三者缺一不可：应用层加密确保DBA查到也看不懂；列级权限和只读视图限制直接SELECT敏感字段；审计日志需捕获实际执行字段并设告警。
不能靠禁用 DBA 账号或限制登录来解决——DBA 本就该有元数据和结构访问权；真正要防的是 SELECT * FROM users 这类直接读取明文敏感字段的行为。核心手段是：应用层加密 + 列级权限隔离 + 审计兜底，三者缺一不可。
应用层加密敏感字段，让 DBA 查到也看不懂
MySQL 自带的 AES_ENCRYPT() 不适合生产：密钥容易硬编码进 SQL 或配置，且无法与应用密钥管理体系对齐。
- 手机号、身份证、邮箱等字段，必须在应用代码中用标准加密库（如 Python 的
cryptography、Java 的javax.crypto）加密后存入VARCHAR或BLOB - 加密前加随机 salt，避免相同值产生相同密文，防止彩虹表攻击
- 若需按手机号前缀查询，可额外存储脱敏哈希（如
SHA256(phone_prefix + salt)），原始值仍加密存储 - 禁止在数据库里建
UNIQUE约束或索引在加密字段上——密文无序，索引失效且暴露长度模式
列级权限 + 视图封装，堵住直接 SELECT 的路径
MySQL 5.7+ 支持列级权限，但仅限于 SELECT、INSERT、UPDATE，且必须配合显式字段列表生效。DBA 账号默认没有列级权限，不授就不会有。
- 对业务账号，用
GRANT SELECT (id, status, created_at) ON app_db.orders TO 'app_user'@'%';，明确排除card_number、cvv等列 - 为 DBA 创建只读视图，过滤掉敏感列：
CREATE VIEW orders_safe AS SELECT id, status, user_id, created_at FROM orders;，再授SELECT权限给视图而非基表 - 禁用
SELECT *在关键表上的隐式列暴露风险：检查sql_mode是否含STRICT_TRANS_TABLES，避免因缺失字段导致意外降级行为
审计日志必须捕获实际执行字段，不能只记语句模板
启用 audit_log 插件（企业版）或 Percona Audit Plugin（社区版）时，仅记录 SELECT * FROM users 没用——它看不出是否查了 password_hash 字段。必须开启 QUERY 日志级别并解析 AST，或依赖代理层（如 ProxySQL）做字段级行为识别。
- 在 MySQL 8.0+ 中，
performance_schema.events_statements_history_long可查最近执行的完整 SQL 文本，配合脚本定期扫描含SELECT.*FROM users或WHERE password的语句 - 设置告警规则：1 分钟内同一账号执行 >3 次含
SELECT敏感字段（如ssn,credit_card）的语句，立即通知安全团队 - 注意：
general_log生产环境必须关闭，性能损耗大；审计日志本身应写入独立服务器，防止 DBA 删除或覆盖
最易被忽略的一点：DBA 用 mysqldump --skip-triggers --no-create-info --where="1=1" 导出全量数据时，列级权限和视图完全失效——dump 工具直连引擎读取页数据。此时唯一防线只剩应用层加密。所以加密不是“可选项”，而是越权防护的最终锚点。
