ERROR 1044本质是权限校验短路，因user表中对应权限字段（如Select_priv）为'N'，导致MySQL在首层检查即拒绝，后续db表等权限不生效；需同步检查并修正user表与db表权限，且GRANT后须FLUSH PRIVILEGES。
ERROR 1044 本质是权限校验中途被拒绝，不是“冲突”而是“短路”
ERROR 1044 Access denied for user ... when using database 不代表权限叠加出错，而是 MySQL 在权限检查链中某一层明确返回了拒绝（'N'），后续层级压根不看了。最常见的情况是：user 表里该用户的 Select_priv 是 'N'，哪怕 db 表里对目标库设了 'Y'，也完全无效。
为什么 SHOW GRANTS 看不到 db 表权限？
SHOW GRANTS FOR 'u1'@'%'; 只显示与当前登录 Host 完全匹配的记录。比如用户从 '192.168.1.100' 登录，但 db 表里只有一条 Host = '192.168.%' 的记录，这条不会出现在 SHOW GRANTS 结果里——但它依然生效。排查时别只信这个命令：
- 直接查表更可靠：
SELECT Host, Db, Select_priv FROM mysql.db WHERE User='u1' AND Host LIKE '192.168.1.%'; - 同时查 user 表：
SELECT Host, User, Select_priv, Insert_priv FROM mysql.user WHERE User='u1' AND Host IN ('%', '192.168.1.100'); - 注意
localhost和127.0.0.1在 MySQL 中是两个不同 Host，不能混用
全局权限和 db 权限混用导致 DELETE 失败的典型场景
现象：给用户授了 GRANT DELETE ON *.* TO 'u1'@'%';，又单独给了 GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.t1 TO 'u1'@'%';，结果执行 DELETE FROM mydb.t1 报 ERROR 1044 —— 缺少 SELECT 权限。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
原因不是 bug，而是 MySQL 对 DML 操作的隐式依赖：DELETE 需先定位行，底层会触发一次隐式 SELECT（尤其带 WHERE 时）。而全局权限里没开 SELECT，user 表中 Select_priv 是 'N'，校验在 user 层就终止了。
- 临时解法：补上全局 SELECT：
GRANT SELECT ON *.* TO 'u1'@'%'; - 更稳妥做法：收回全局 DML 权限，只保留库级或表级授权，避免 user 表残留
'N' - 切记：用
REVOKE后必须FLUSH PRIVILEGES;（GRANT 自动刷新，REVOKE 不一定）
容易被忽略的权限“静默拒绝”点
user 表里权限字段为 'N' 就是明确拒绝，不是“未设置”。很多初始化脚本或 CREATE USER 语句会默认把所有权限设为 'N'，之后只改 db 表，却忘了 user 表这道关卡。
- 新建用户后，如果只走
GRANT ... ON db.*，务必确认 user 表对应行的Select_priv、Insert_priv等不是'N' -
max_questions=0或max_updates=0这类资源限制字段为 0，也会导致连接被拒，且错误码可能仍是 1044 - MySQL 8.0+ 的角色（ROLE）能绕过部分 user/db 冲突，但角色本身仍受 user 表基础权限约束
