SELECT command denied 错误未必是权限不足，可能因库名前缀指向已删除数据库、默认数据库拼写错误、未执行FLUSH PRIVILEGES且客户端未重连、cPanel/RDS环境未显式写完整库名、MySQL 8.0+系统库授权不精确等导致。
SELECT command denied to user 错误不一定是权限问题
看到这个报错，第一反应往往是“没授权”，但真实场景中，SELECT command denied to user 'xxx'@'localhost' for table 'users' 很可能根本和权限无关。MySQL 在遇到 SELECT * FROM old_db.users 这类带库名前缀的语句时，如果 old_db 已被删除，它不会报 Unknown database 'old_db'，而是直接降级为表级拒绝——误导性极强。
排查时优先确认两点：
- 执行的 SQL 里是否硬写了数据库名（如
`deleted_db`.`users`），而该库实际已不存在 - 连接字符串中指定的默认数据库（
database=xxx）是否拼写错误或已被删掉 - 用
SHOW DATABASES;和USE xxx;+SHOW TABLES;手动验证目标库表是否存在
GRANT 权限后必须 FLUSH PRIVILEGES
即使你用 GRANT SELECT ON mydb.users TO 'app_user'@'localhost'; 成功执行，权限也不会立刻生效。MySQL 权限缓存不会自动刷新，旧连接仍走旧规则。
关键动作只有两个：
- 执行
FLUSH PRIVILEGES;（注意分号不能漏） - 客户端必须断开重连——PDO 持久连接、MySQLi 长连接、CLI 历史会话都不会自动 reload
常见误区：以为执行完 GRANT 就万事大吉，结果测试脚本还在用老连接跑，一直报错。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
cPanel/RDS 环境下必须显式写数据库名前缀
在 cPanel（如 Namecheap）、阿里云 RDS 等托管环境中，用户权限是严格绑定到具体数据库的，不是全局生效。即使你在控制面板里给 incoktys_rig_vtu_admin 授了 incoktys_rig_vtu 的全部权限，PHP 脚本里写 SELECT * FROM users 依然会被拒。
正确写法只有一条路：
- 所有 SQL 必须显式带上完整数据库名：
SELECT id FROM `incoktys_rig_vtu`.`users` - 数据库名必须与 cPanel/RDS 控制台中显示的**完全一致**（含用户名前缀，如
incoktys_rig_vtu，不是rig_vtu） - 反引号不是可选的——当库名含下划线或与关键字冲突时，不加会直接语法报错
MySQL 8.0+ 对系统库权限限制更严
想查 mysql.user 或 sys_data_dictionary？别再试 GRANT SELECT ON mysql.*，MySQL 8.0+ 明确禁止通配系统库授权，必须精确到表：
GRANT SELECT ON mysql.user TO 'monitor'@'localhost';GRANT SELECT ON mysql.db TO 'monitor'@'localhost';-
GRANT SELECT ON sys.sys_data_dictionary TO 'reporter'@'%';（注意sys是 schema 名）
漏掉 FLUSH PRIVILEGES; 或连错 host（'user'@'localhost' ≠ 'user'@'127.0.0.1'）都会让这些授权失效——这两处细节，90% 的排查会跳过。
