开发环境账号仅授SELECT/INSERT/UPDATE/DELETE权限，禁用DDL；生产环境按最小权限拆分账号，严格管控information_schema与performance_schema访问，权限变更须走SQL流程并版本化管理。
开发环境账号只给 SELECT、INSERT、UPDATE、DELETE，禁用 DROP、CREATE、ALTER
开发环境不是沙盒，但必须当作沙盒用。很多团队误以为“本地连的是测试库就随便操作”，结果 mysql -u dev -p -h test-db 登进去随手 DROP TABLE user_log_2023，第二天发现日志归档脚本崩了——因为表结构被删了，而下游服务没做兜底。
实操建议：
- 建库时统一用
CREATE DATABASE dev_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，之后只授权给开发账号GRANT SELECT, INSERT, UPDATE, DELETE ON dev_db.* TO 'dev'@'%'; - 禁止授予
GRANT OPTION，避免开发账号再转授权限 - 开发账号密码不存入项目配置文件，改用环境变量或密钥管理工具注入，防止误提交到 Git
- 如果用 Docker 启动 MySQL，可在
docker-compose.yml的command里加--skip-grant-tables仅限本地调试（切记不可用于任何网络可访问的容器）
生产环境账号按最小权限原则拆分，严禁使用 root 或 super 权限应用连接
线上 application.properties 里写 spring.datasource.username=root 是高危行为。哪怕密码再强，一旦应用层有 SQL 注入或日志泄露，攻击者就能直接 SHOW MASTER STATUS 拿到 binlog 位置，甚至 SET GLOBAL read_only=OFF 开启写权限。
实操建议：
- 读写分离场景下，应用连接至少两个账号：
app_rw（仅业务库INSERT/UPDATE/DELETE/SELECT）和app_ro（只读从库，SELECT+SHOW类元数据查询） - 备份账号单独建，只赋予
RELOAD、LOCK TABLES、REPLICATION CLIENT，且限制来源 IP（如'backup'@'10.10.20.5'） - DBA 管理账号用
mysql_native_password插件认证，禁用caching_sha2_password（老版本客户端兼容问题多，反而导致临时改密失败） - 检查现有账号权限：执行
SELECT User, Host, authentication_string FROM mysql.user WHERE User NOT IN ('mysql.session', 'mysql.sys', 'root');，确认无明文密码字段残留
information_schema 和 performance_schema 的访问需显式控制
默认情况下，普通账号能查 information_schema.TABLES，这会暴露所有库名、表名、行数估算值。在金融或 SaaS 多租户场景中，一个租户可能通过 SELECT table_name FROM information_schema.TABLES WHERE table_schema = 'tenant_123' 推断出其他租户存在，构成信息泄露。
实操建议：
- MySQL 8.0+ 可用
CREATE ROLE 'schema_reader'; GRANT SELECT ON information_schema.TABLES TO 'schema_reader';，再把该 role 授予必要人员，而非开放全局 SELECT - 若用 MySQL 5.7，只能靠应用层拦截关键词（如禁止 SQL 中含
information_schema），但更稳妥的做法是代理层（如 ProxySQL）重写或拒绝这类查询 -
performance_schema默认对所有用户只读，但某些表（如events_statements_history_long）可能暴露完整 SQL 文本，建议用SET GLOBAL performance_schema = OFF;关闭，除非真有性能诊断需求
权限变更必须走 SQL 变更流程，禁止手工 GRANT / REVOKE
有人在凌晨两点紧急修复 bug，顺手 GRANT ALTER ON prod_db.order TO 'dev'@'%';，忘了回收——三个月后安全审计扫出该账号仍有 DDL 权限，而当时那个临时需求早已下线。
实操建议：
- 所有权限变更必须提交 SQL 文件到版本库，命名如
20240521_add_alter_to_dev.sql，内容包含GRANT和对应的REVOKE回滚语句，并注明有效期（如“仅限 2024-05-21 至 2024-05-23”） - 用
mysqldump --no-data --routines --triggers mysql定期导出权限快照，与 Git 历史比对，发现未走流程的权限漂移 - 在 CI 流程中加入检查：扫描提交的 SQL 文件是否含
GRANT ALL PRIVILEGES、WITH GRANT OPTION，自动阻断合并
权限不是设一次就完事的事。最常被忽略的是账号生命周期管理——开发离职后，其账号是否还在 mysql.user 表里？有没有人悄悄用 % 通配符建过 'admin'@'%' 这种高危账号？这些细节比“要不要开 audit log”更决定系统实际防线厚度。
