MySQL数据库基本概念详解：命名空间、权限控制与多用户隔离应用-mysql教程-PHP中文网

MySQL无命名空间但以database实现逻辑隔离，权限分账户层与业务层双轨控制，通过user@host细粒度管控访问。

mysql数据库基本概念详解：命名空间、权限控制与多用户隔离应用

MySQL 不支持像编程语言那样的命名空间（namespace），它的逻辑隔离单位是 database。每个 database 是独立的表集合容器，不同 database 下可以存在同名表而互不干扰——这本质上就是命名空间要解决的问题。

常见误区是以为建个 schema 就等于有了命名空间，其实 CREATE SCHEMA 只是 CREATE DATABASE 的同义词，不引入额外抽象层。真正要注意的是：

database 名必须全局唯一，不能重复；跨库查询需显式写成 db_name.table_name
用户对某个 database 的权限默认不自动延伸到新创建的同名库（哪怕删了重建）
用 mysqldump --databases 备份时，若漏掉 --databases 参数，会丢失 CREATE DATABASE 语句，导致恢复后无库结构

很多人一上来就在 users 表里加 is_admin 字段，结果权限改一次就得改代码、发版、重启服务——这是把应用层 RBAC 塞进了数据库账户体系，违背分层原则。

正确的做法是双轨并行：

MySQL 账户权限：只管“能不能连、能看哪些库”，用 GRANT SELECT ON app_db.* TO 'app_user'@'10.0.2.%' 这类语句配置，最小化授予（比如生产环境绝不给 DROP 或 ALTER）
业务角色权限：用 users、roles、permissions、user_roles、role_permissions 五张表实现，登录后查 JOIN 结果缓存到 session，校验逻辑全在应用层

混淆两者的典型后果：开发用 root 连库调试，上线后忘了切账号，导致任意 SQL 都能执行；或者给测试用户开了 mysql.user 表读权限，结果暴露所有账号密码哈希。

看到“多用户隔离”，第一反应建一堆 database 并分配不同用户？太重了。实际更轻量、更安全的做法是利用 MySQL 的 user@host 二元标识和细粒度权限。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

例如，让前端服务、数据分析组、DBA 同时访问同一个 sales_db，但权限完全不同：

web_app@'10.0.1.%'：只允许 SELECT, INSERT, UPDATE on sales_db.orders，禁止 DELETE
analyst@'10.0.2.%'：允许 SELECT on sales_db.*，但禁止访问 sales_db.users 表
dba@'127.0.0.1'：仅限本地登录，拥有 ALL PRIVILEGES on sales_db，且密码强制 90 天过期

这种方案避免了库级冗余，也防止误操作波及其它环境；关键点在于：主机地址（host）不是可有可无的字段，它是权限生效的前提条件，'user'@'%' 和 'user'@'localhost' 是两个完全独立的账户。

执行完 GRANT 或 REVOKE 后，立刻用新用户连不上？不是语法错，大概率是这两件事没做：

MySQL 5.7+ 默认不需要 FLUSH PRIVILEGES，但如果你手动改过 mysql.user 表（比如用 UPDATE 直接更新密码字段），就必须执行它，否则权限缓存不会刷新
应用使用连接池（如 HikariCP、PooledConnection）时，旧连接仍持有原权限上下文，新权限只对新建连接生效；需重启应用或等待连接自动回收（取决于 idle timeout 设置）
注意 SHOW GRANTS FOR 'user'@'host' 查的是当前生效权限，但 SELECT * FROM mysql.user 显示的是磁盘存储值，二者可能因未 flush 而不一致

最容易被忽略的是：权限判断发生在连接建立阶段，而不是 SQL 执行时。所以即使你 GRANT 成功了，正在运行的长连接依然按老权限跑，直到断开重连。