必须先清空全局权限再分库授权，否则残留的SHOW DATABASES等权限会使用户可见所有库名；未限制information_schema.COLUMNS权限则可通过其窥探其他库结构；MySQL 8.0+需手动指定mysql_native_password插件避免认证失败。
不能靠“新建用户+勾选数据库”就完事，必须分库授权+禁用全局权限+验证连接上下文，否则团队之间仍可能互相看到库名甚至误操作。
为什么只在“Database-specific privileges”里勾选目标库还不够
phpMyAdmin 界面里选中某个数据库并授予权限后，如果没清理干净“Global privileges”区域的残留勾选（比如意外保留了 SHOW DATABASES 或 USAGE），用户登录后仍会看到所有数据库列表——只是点进去报错。更糟的是，某些 ORM 或 CLI 工具（如 Laravel 的 php artisan tinker）会尝试执行 SHOW DATABASES 或 USE information_schema，触发权限冲突导致连接直接中断。
- 进入该用户的「Edit privileges」→ 先滚动到「Global privileges」→ 取消所有勾选（包括看似无害的「Select all」）
- 再滚动到「Database-specific privileges」→ 点「Add privileges on the following database」→ 选 team_a_db → 勾 SELECT/INSERT/UPDATE/DELETE/ALTER/INDEX
- 保存后，立刻用新账号连一次：mysql -u team_a_user -p -h localhost，然后执行
SHOW DATABASES;，应只返回 team_a_db 和 information_schema（后者是 MySQL 内置库，无法隐藏）
如何防止开发团队通过information_schema窥探其他库结构
默认情况下，所有用户都能查 information_schema.TABLES，这意味着 team_a_user 执行 SELECT * FROM information_schema.TABLES WHERE TABLE_SCHEMA != 'team_a_db'; 就能列出其他团队的库名和表名。这不是漏洞，是 MySQL 设计如此——但对多团队协作属于信息泄露风险。
- 在 phpMyAdmin 中进入该用户的「Database-specific privileges」→ 选择
information_schema→ 只勾 SELECT（不要全选） - 再执行一条限制性 SQL：
REVOKE SELECT ON information_schema.COLUMNS FROM 'team_a_user'@'localhost';（需管理员账号在「SQL」标签页运行） - 验证：用 team_a_user 登录后执行
SELECT COLUMN_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'team_b_db';应报错 Access denied
MySQL 8.0+ 下团队用户创建失败的认证插件问题
如果你用的是 MySQL 8.0+，而 phpMyAdmin 版本低于 5.0（比如还在用 4.9.x），界面创建用户时默认用 caching_sha2_password 插件，但旧版 phpMyAdmin 不支持该协议，导致连接时报 Authentication plugin 'caching_sha2_password' cannot be loaded。
立即学习“PHP免费学习笔记（深入）”；
- 先确认当前默认插件：
SELECT @@default_authentication_plugin; - 别依赖界面建用户，切到「SQL」标签页手动执行：
CREATE USER 'team_a_user'@'192.168.10.%' IDENTIFIED WITH mysql_native_password BY 'strong_pass_2026'; - 再授予权限：
GRANT SELECT, INSERT, UPDATE, DELETE ON `team_a_db`.* TO 'team_a_user'@'192.168.10.%'; - 最后执行
FLUSH PRIVILEGES;（仅当直改 mysql.user 表时才必须；GRANT 后可不加）
团队共用一个数据库但要隔离表前缀时的权限陷阱
当多个团队共用 shared_db，靠不同表前缀（如 team_a_users、team_b_users）区分数据时，单纯授予 shared_db.* 权限等于把所有表都放开——team_a_user 能删 team_b_logs，也能读 team_b_config。
- 不要给团队用户授整个库的权限，而是按需授权具体表：
GRANT SELECT, INSERT, UPDATE ON shared_db.team_a_% TO 'team_a_user'@'192.168.10.%'; - 注意通配符语法：MySQL 支持
table_name_pattern，但必须用反引号包裹，且模式中不能含空格或特殊字符 - 验证权限是否生效：
SHOW GRANTS FOR 'team_a_user'@'192.168.10.%';，检查输出里是否出现ON `shared_db`.`team_a_%`
最易被忽略的是主机名匹配粒度——'team_a_user'@'%' 和 'team_a_user'@'192.168.10.%' 是两个完全不同的账号，权限互不影响；写错一个点，就可能导致应用连不上或者权限失控。
