MySQL如何创建仅可访问指定数据库的用户

在 MySQL 中，CREATE USER 这条语句里的 host 必须明确指定；如果省略不写，系统通常会默认创建为 'username'@'%'。这样一来，后续如果在 GRANT 里写的是 'username'@'host'，两边用户标识就无法匹配，授权自然不会生效。若是本地连接，应写成 'username'@'localhost'；到了生产环境，IP 范围也应尽量收紧，例如使用 '192.168.1.%' 这样的网段限制，尽量避免直接使用 '%'。另外，只要数据库名称中包含特殊字符，就必须使用反引号包裹。

CREATE USER 语句必须指定 host，否则 MySQL 权限可能无法生效

在 MySQL 里，用户名从来不是单独存在的字符串，它真正对应的是 'username'@'host' 这一完整身份标识。如果把 @'host' 省略，或者只写成 'username' 这种没有 host 的形式，后面的 GRANT 授权就很容易出问题：要么直接报错，要么权限根本匹配不到正确用户。举一个很典型的例子，执行 CREATE USER 'reporter' 时，实际创建出来的往往是 'reporter'@'%'；但如果后面又执行 GRANT SELECT ON `sales_db`.* TO 'reporter'@'192.168.1.%'，这两个对象实际上并不是同一个 MySQL 用户，所以权限当然不会生效。

常见报错现象是：Access denied for user 'reporter'@'192.168.1.5'。即使你确认已经执行过授权，大概率也是因为 CREATE USER 和 GRANT 使用的 host 不一致，导致 MySQL 用户权限没有正确匹配。

• 本地连接应使用 'reporter'@'localhost'
• 固定内网网段可使用 'reporter'@'192.168.1.%'（注意点号是地址的一部分，% 为通配符）
• 生产环境尽量不要使用 'reporter'@'%'，除非已经做好严格的网络隔离
• host 部分区分大小写，'localhost' 和 'LOCALHOST' 在 MySQL 中属于两个不同用户

GRANT SELECT ON database_name.* 是最小可行授权，避免使用 *.*

创建 MySQL 只读账号的核心原则，就是只授予 SELECT 权限，并且将授权范围精确限制到指定数据库。使用 GRANT SELECT ON `sales_db`.* TO 'reporter'@'192.168.1.%' 是比较标准且安全的做法；而数据库名外层的反引号并不是可有可无——如果库名包含横线、以数字开头，或者使用了关键字（例如 order），不加反引号就可能触发 ERROR 1064 (42000) 语法错误。

不要直接使用 GRANT SELECT ON *.*，即使是在测试环境中也不推荐。因为这样的授权会让用户看到所有数据库名称，包括 mysql、information_schema 等系统库，既可能暴露数据库结构信息，也明显违背最小权限原则，不利于 MySQL 安全管理。

• 如果需要访问多个数据库，应分别逐条授权：GRANT SELECT ON `reports_db`.* TO ... 和 GRANT SELECT ON `analytics_db`.* TO ...
• 如果要把权限进一步限制到单表，可使用 GRANT SELECT ON `sales_db`.`orders` TO ...
• 授权完成后建议执行 FLUSH PRIVILEGES，确保新权限及时生效（尤其是在旧版本或某些容器环境中）

登录后看不到其他数据库，是正常表现，不是 MySQL 配置失败

MySQL 中“只能看到指定数据库”并不是通过隐藏机制实现的，而是数据库权限控制的自然结果。当你使用只读用户登录后执行 SHOW DATABASES，系统只会展示你至少拥有一个权限（哪怕只是 USAGE）的数据库。而 SELECT 权限会自动赋予目标库对应的 USAGE，因此 sales_db 会显示出来，而其他无权限的数据库不会显示——这属于正常现象，并不是配置错误或程序 bug。

如果想验证该用户是否真的被限制，可以尝试执行 USE other_db 或 SELECT * FROM other_db.table1，通常会直接报错 ERROR 1044 (42000): Access denied for database。

• Navicat / DBeaver 等 GUI 工具通常只显示当前用户有权访问的数据库，所以界面看起来会更“干净”，但本质上仍然是服务端根据权限返回结果
• 如果某个用户可以列出所有数据库名称，说明你很可能误授了 SHOW DATABASES 权限（这个权限独立于 SELECT）
• 在 MySQL 8.0+ 中，INFORMATION_SCHEMA 默认对所有用户可见，但如果没有对应权限，仍然无法查看其他数据库的表结构详情

密码强度与连接限制，是创建 MySQL 只读用户时最容易忽略的安全细节

创建只读用户时，很多人只关注数据库权限本身，却忽略了账户安全基线。弱密码再加上宽泛的 host 范围（例如 @'%'），等于给数据库安全留下明显漏洞。

• 密码应同时包含大小写字母、数字和特殊字符，长度建议 ≥12；MySQL 8.0 默认启用 validate_password 插件，弱密码通常会被直接拒绝
• host 应尽量写得更具体：使用 'reporter'@'10.0.2.0/24'（MySQL 8.0.20+ 支持 CIDR）比 'reporter'@'%' 更安全、更可控
• 不要复用已有账号：为报表、BI、监控等不同用途分别创建独立 MySQL 用户，便于后续审计、停用和权限回收
• 定期检查账户状态：SELECT User, Host, authentication_string FROM mysql.user WHERE User = 'reporter';，确认密码哈希和 host 设置是否符合预期

真正麻烦的往往不是创建 MySQL 用户本身，而是某天才发现这个只读账号可以连接生产数据库，却没有设置 IP 限制，或者密码居然还是 123456，甚至已经出现在 Git 提交历史中。数据库权限粒度后续还可以调整，但账户基础配置一旦过于宽松，补救成本通常远远高于初始化时多花的那两分钟。