不能只靠账号权限做敏感数据隔离，因为MySQL的GRANT/REVOKE仅控制逻辑访问，无法防止物理层面的数据共存与泄露，如共享datadir、ibdata1或备份导出导致敏感数据暴露。
为什么不能只靠账号权限做敏感数据隔离
MySQL 的 GRANT 和 REVOKE 只控制逻辑访问，不阻止物理层面的数据共存。同一实例里，哪怕用户 A 根本看不到表 B，其数据文件（如 ibd 文件）仍和用户 C 的数据混在同一个 datadir 下，备份、磁盘快照、误删恢复、甚至崩溃修复时都可能意外暴露。
- 权限控制失效场景常见于：DBA 临时提权排查、SQL 注入绕过应用层鉴权、mysqldump 全库导出后被误传
- InnoDB 表空间共享（
innodb_file_per_table=OFF）时，所有表数据挤在ibdata1里，物理隔离彻底无从谈起 - 即使开启
innodb_file_per_table=ON，文件仍在同一文件系统路径下，OS 层无隔离能力
专用服务器 ≠ 换个 IP 就行，关键看进程与存储根路径
部署“专用数据库服务器”，本质是让敏感库独占一个 mysqld 进程 + 独立 datadir + 独立操作系统用户 + 独立网络端口。不是把新库建在旧实例里换个库名，也不是仅用 Docker 跑个容器却不隔离存储路径。
- 必须修改配置文件中的
datadir，指向专有路径（如/data/sensitive-mysql/），且该路径由独立系统用户（如mysql-sensitive）拥有 - 必须指定独立
port（如3307），避免和主实例冲突；同时禁用skip-networking，否则应用连不上 - systemd 服务文件需单独定义（如
mysqld-sensitive.service），不能复用原服务单元，否则systemctl restart mysqld会误杀敏感库进程 - 不建议用
mysqld --defaults-file=xxx.cnf手动启动：缺乏进程管理、日志轮转、开机自启保障，线上环境极易失管
跨服务器同步敏感数据？别用 mysqldump 或 GTID 复制
一旦敏感库部署到专用服务器，就应切断与非敏感系统的直接数据链路。常见错误是为“保持一致性”而启用主从复制或定时 dump 导入——这等于在物理隔离的墙上凿了条暗道。
-
mysqldump导出再导入：dump 文件本身含明文敏感数据，传输过程、临时目录、shell 历史记录都成泄露点 - 基于 binlog 的复制（包括
GTID）：从库必须能解析主库 binlog，意味着主库需开启log_bin，且从库账号需有REPLICATION SLAVE权限——这权限足以读取所有变更，违背最小权限原则 - 正确做法是业务层驱动单向、字段级、脱敏后的数据推送：比如用 Kafka 吐出加工后的订单摘要（不含身份证、银行卡），由专用服务消费写入敏感库；原始敏感字段绝不跨网络明文流动
真正难的是运维边界和日志生命周期
物理隔离之后，最易被忽略的是“人”和“日志”带来的穿透风险。
- DBA 登录专用服务器后，若用同一 ssh 密钥、同一跳板机、同一堡垒机账号，审计日志无法区分操作归属；应为敏感库运维分配独立系统账号+独立密钥+独立审计策略
-
slow_query_log、general_log若开启，日志文件（如/var/log/mysql-sensitive/slow.log）可能含 SQL 中的敏感值，必须关闭或配置log_output='TABLE'并限制查询权限 - 备份脚本若用
mysqldump --all-databases，会一并导出敏感库——必须显式指定--databases db1 db2排除敏感库名，且备份文件加密存储，密钥不与备份同机存放
物理隔离不是部署完就一劳永逸的事。每次权限调整、日志开关、备份策略变更，都要反问一句：这个操作会不会让敏感数据在磁盘、内存、网络或日志里留下未受控的副本。
