MySQL 8.0 表级权限必须显式指定 db_name.table_name 格式，不支持省略数据库名或通配符缩写；授权需先 CREATE USER 再 GRANT；权限存于 mysql.tables_priv，SHOW GRANTS 不显示表级权限。
MySQL 8.0 表级权限必须带数据库名前缀
直接写 GRANT SELECT ON orders 会报错 ERROR 1144 (42000): Wildcard denied for table。MySQL 不会自动推导当前数据库上下文，表权限必须显式指定 db_name.table_name 格式。
常见错误写法：GRANT SELECT ON logs TO 'app'@'192.168.1.%' → 失败
正确写法：GRANT SELECT ON myapp.logs TO 'app'@'192.168.1.%'
- 如果要授权多张表，每张都得单独写一条
GRANT，不能用通配符缩写 - 库名含短横或关键字（如
order_db）必须用反引号包裹：GRANT SELECT ON `order_db`.`orders` - 跨库访问（比如从
report库查core.user）需分别授权：GRANT SELECT ON core.user TO 'reporter'@'%'
CREATE USER 和 GRANT 必须分两步执行
MySQL 8.0 强制要求先创建用户，再授予权限。合并在一条语句里（如 GRANT ... IDENTIFIED BY）会直接报错 ERROR 1064 (42000)。
标准流程：
- 创建用户（推荐指定认证插件，避免客户端兼容问题）：
CREATE USER 'app_writer'@'192.168.10.%' IDENTIFIED WITH mysql_native_password BY 'StrongPass!2026'; - 再授表级读写权限：
GRANT SELECT, INSERT, UPDATE ON billing.invoices TO 'app_writer'@'192.168.10.%'; - 若还需操作另一张表：
GRANT DELETE ON billing.archived_invoices TO 'app_writer'@'192.168.10.%';
注意：GRANT 本身已立即生效，FLUSH PRIVILEGES 不必要，且可能掩盖配置问题。
验证表权限是否真正写入 mysql.tables_priv
SHOW GRANTS FOR 'user'@'host' 默认不显示表级权限——这不是 bug，是 MySQL 的设计行为。哪怕你刚执行了 GRANT UPDATE ON app.config TO 'user'@'localhost'，结果里也不会出现这行。
要确认权限是否落库，必须查系统表：
- 运行：
SELECT * FROM mysql.tables_priv WHERE User='app_writer' AND Host='192.168.10.%' AND Db='billing' AND Table_name='invoices'\G - 检查
Table_priv字段值是否为Select,Insert,Update（逗号分隔） - 如果查不到记录，说明
GRANT没成功：可能是用户不存在、主机名拼错、或当前会话没GRANT OPTION
撤销权限必须严格匹配原 GRANT 语句
REVOKE 不是模糊撤销，它要求数据库名、表名、用户、主机名四者完全一致。漏一个字符就会失败，且不会报错，只是“没撤成”。
例如你用这条授权：GRANT SELECT, INSERT ON billing.invoices TO 'app_writer'@'192.168.10.%'
那么撤销必须写成：REVOKE SELECT, INSERT ON billing.invoices FROM 'app_writer'@'192.168.10.%'
- 不能省略
INSERT—— 只写REVOKE SELECT不会影响INSERT权限 - 不能把
192.168.10.%写成%或localhost，否则匹配不到 - 撤销后建议再查一次
mysql.tables_priv，确认记录已被删除
表级权限容易被忽略的细节是：它不继承新创建的表，也不随库名变更自动更新；每次加表、改名、换库，都得手动补 GRANT。
