MySQL多账号安全设计需从权限最小化、数据库/表级隔离、网络与连接控制三方面实现真正隔离：按业务建独立库并绑定专属账号，显式收回高危权限，限制主机白名单；业务账号仅限CRUD且禁用DDL与权限管理；利用角色分层复用权限；强制SSL、限连数、启审计日志。
MySQL 多账号安全设计的核心，是通过权限最小化、数据库/表级隔离、网络与连接控制三方面实现业务账号间真正隔离。不能只靠“不同用户名”就认为安全了。
按业务划分独立数据库 + 账号绑定
每个业务系统（如订单服务、用户中心、报表平台）应使用专属数据库，而非共用一个库再靠表前缀区分。创建账号时直接限定其只能访问对应库：
- CREATE DATABASE order_db CHARACTER SET utf8mb4;
- CREATE USER 'order_app'@'10.20.30.%' IDENTIFIED BY 'strong_pass_2025';
- GRANT
SELECT,INSERT,UPDATE ON order_db.* TO 'order_app'@'10.20.30.%';
- REVOKE DROP,ALTER,CREATE,INDEX,GRANT OPTION ON *.* FROM 'order_app'@'10.20.30.%';
注意：显式收回高危权限比依赖默认更可靠；主机白名单（如'10.20.30.%'）比'%'大幅降低横向渗透风险。
敏感操作必须走专用运维账号，业务账号禁用 DDL 和权限管理
业务账号只应具备 CRUD（不含 DROP/ALTER/TRUNCATE）和 EXECUTE（仅限授权的存储过程）。结构变更、索引优化、账号增删等，必须由 DBA 使用带双因素认证的专用账号操作：
- 业务账号不赋予 CREATE VIEW、SHOW VIEW、PROCESS、SUPER 权限；
- 避免使用 DEFINER = CURRENT_USER 的存储过程，防止权限提升；
- 定期用 SELECT user,host,Select_priv,Insert_priv,Grant_priv FROM mysql.user WHERE user NOT IN ('root','dba_admin'); 检查异常权限配置。
利用 MySQL 8.0+ 的角色（ROLE）做权限分层复用
当业务线增多、权限组合变复杂时，用角色替代重复授权可降低出错率：
- CREATE ROLE 'order_reader', 'order_writer';
- GRANT SELECT ON order_db.* TO 'order_reader';
- GRANT INSERT,UPDATE ON order_db.* TO 'order_writer';
- GRANT 'order_reader', 'order_writer' TO 'order_app'@'10.20.30.%';
- SET DEFAULT ROLE ALL TO 'order_app'@'10.20.30.%';
后续只需调整角色权限，所有绑定该角色的账号自动同步，无需逐个修改。
连接层加固：强制 SSL + 连接限制 + 审计日志
账号隔离不只是 SQL 权限，还要堵住连接入口：
- 在 my.cnf 中启用 require_secure_transport=ON，并为每个业务账号指定 REQUIRE SSL；
- 用 MAX_USER_CONNECTIONS 限制单账号并发连接数（如 ORDER_APP 最多 50 个连接），防误写死循环打爆实例；
- 开启 general_log 或使用 MySQL Enterprise Audit（或 Percona Audit Plugin）记录所有业务账号的登录与查询行为，重点监控非工作时间、非常规 IP 的访问。
不复杂但容易忽略。
