创建 MySQL 新用户必须用 CREATE USER
，不能只靠 GRANT
很多操作失败是因为误以为执行
GRANT就自动建用户。MySQL 8.0+ 默认严格模式下，
GRANT遇到不存在的用户会直接报错：
ERROR 1410 (42000): You are not allowed to create a user with GRANT。
正确顺序是先建用户，再赋权：
CREATE USER 'app_user'@'192.168.1.%' IDENTIFIED BY 'StrongPass123!';
'app_user'@'192.168.1.%'中的主机部分别写成
%（全网可连）除非真有需要，生产环境应限制 IP 段或具体 IP 密码必须满足当前 validate_password 策略，例如默认策略可能要求至少 8 位、含大小写字母+数字+特殊字符 MySQL 8.0+ 默认认证插件是
caching_sha2_password，旧客户端（如某些 Python 2.x pymysql 版本）可能不兼容，必要时加
IDENTIFIED WITH mysql_native_password
分配权限要用 GRANT
，且需显式指定数据库和表范围
权限不是“给完就生效”，必须搭配
FLUSH PRIVILEGES或重启服务——但更推荐用
GRANT后直接
FLUSH PRIVILEGES，因为
GRANT本身在多数版本中已自动重载权限缓存，但保险起见仍建议手动刷一次。
常见权限组合示例：
GRANT SELECT, INSERT, UPDATE ON myapp.* TO 'app_user'@'192.168.1.%';
myapp.*表示只对
myapp库下所有表授权；若写成
*.*是全局权限，DBA 才该用 不推荐直接给
ALL PRIVILEGES，尤其避免
DROP、
CREATE USER、
GRANT OPTION这类高危权限 如果应用只需要读，就只给
SELECT；如果用到存储过程，还得额外
EXECUTEMySQL 8.0+ 支持角色（
CREATE ROLE），适合多用户统一权限管理，但小项目直接
GRANT更直观
删除用户或回收权限要小心 DROP USER
和 REVOKE
的行为差异
DROP USER会彻底删除账号及其所有权限记录；而
REVOKE只撤权限，用户还存在。
典型误操作：
REVOKE ALL PRIVILEGES ON *.* FROM 'app_user'@'192.168.1.%';这条命令不会删用户，但也不会清空其历史权限缓存——有些旧连接可能仍保持权限，建议随后执行
FLUSH PRIVILEGES想彻底清除，用
DROP USER 'app_user'@'192.168.1.%'；注意：MySQL 8.0+ 不支持
DROP USER IF EXISTS语法，得先查
mysql.user表判断 回收权限后，用户当前活跃连接不会立即失效，新连接才受限制
验证权限是否生效，别只靠 SHOW GRANTS
SHOW GRANTS FOR 'app_user'@'192.168.1.%'显示的是“被授予的语句”，不代表实际生效效果。真正有效的权限是服务器根据
user、
db、
tables_priv等系统表逐层匹配的结果。
快速验证方式：
用新用户登录：mysql -u app_user -p -h 192.168.1.100，看能否连上 连上后执行
SELECT USER(), CURRENT_USER();——前者是登录身份（带 host），后者是服务器匹配到的实际账户，两者不一致说明 host 匹配有歧义 尝试执行被授权的操作（如
INSERT INTO myapp.log_table VALUES (...)），比看权限列表更可靠
权限问题最难 debug 的地方在于 host 匹配优先级：MySQL 按
user@specific_ip→
user@ip_wildcard→
user@%顺序匹配，哪怕你建了两个同名用户，也可能调用错的那个。
