开发人员不能直接操作生产库,必须通过物理隔离、账号约束和连接校验三层叠加实现精确控制:强制使用不同库名(如myapp_dev与myapp)、开发账号仅限localhost且无生产库权限、应用启动时校验当前库名并拒绝异常配置。
开发人员不能直接操作生产库——这不是权限“怎么配”的问题,而是架构前提。真正可落地的精确控制,必须靠物理隔离 + 账号约束 + 连接校验三层叠加,缺一不可。
仅靠账号权限无法防止 dev 账号连错 host 后执行 DROP TABLE。最简单有效的防线是让开发和生产使用完全不同的库名:
myapp_dev、billing_dev 等带 _dev 后缀的库名myapp、billing 等无后缀库名SELECT DATABASE(),若当前库名含 _dev 但运行在生产配置下,立即退出USE `myapp` 出现在 dev 分支的初始化脚本里开发账号必须绑定 localhost,且不能被远程绕过:
CREATE USER 'dev_user'@'localhost' IDENTIFIED BY 'StrongPass2026!';
DROP USER IF EXISTS 'dev_user'@'%';
localhost(触发 Unix socket),不能写 127.0.0.1(走 TCP,可能匹配到其他 host 规则)bind-address = 127.0.0.1 或 bind-address = ::1,避免监听公网接口即使误连上生产实例,也要让它对生产库名“看不见、摸不着”:
GRANT ... ON `myapp`.* 权限SHOW GRANTS FOR 'dev_user'@'localhost';,确认输出中不含生产库名CREATE ROLE 'dev_role'; GRANT SELECT, INSERT ON `myapp_dev`.* TO 'dev_role'; GRANT 'dev_role' TO 'dev_user'@'localhost'; SET DEFAULT ROLE 'dev_role' TO 'dev_user'@'localhost';
SELECT user, host FROM mysql.user WHERE user = 'dev_user'; 和 SELECT * FROM mysql.db WHERE user = 'dev_user';
权限控制不能只依赖数据库层。很多误操作发生在应用已连上错误实例之后:
SELECT CASE WHEN DATABASE() LIKE '%_dev' THEN 1 ELSE SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Production config connected to dev DB name' END;
DATABASES 配置中用 OPTIONS['init_command'] 做同样判断mysql2 连接池启用 connectTimeout 并在 acquireConnection 钩子中查 SELECT DATABASE()
SELECT USER(), CURRENT_USER(), DATABASE() 三元组,便于事后追溯真正的精确控制不在 GRANT 语句有多细,而在于让开发人员根本没有路径触达生产库名——哪怕他手抖敲错了 IP、改了配置、甚至拿到了生产实例的账号密码。