开发环境账号只给 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”更决定系统实际防线厚度。
