error 1396 表明 rename user 失败主因是目标用户已存在、原用户被 definer 引用或会话处于未提交事务中，需依次检查 mysql.user 中新旧账号冲突、information_schema 中 definer 关联对象及当前事务状态。
RENAME USER报ERROR 1396：不是权限不够，是语法或状态不合法
执行 RENAME USER 'old'@'host' TO 'new'@'host' 却收到 ERROR 1396 (HY000): Operation ALTER USER failed for 'old'@'host'，基本可以排除“没给CREATE USER权限”这种表层原因。MySQL 8.0 内部把用户名+主机名当作复合主键，RENAME USER 实际是原子性删旧插新，失败往往卡在三类硬性校验上：
- 目标用户名
'new'@'host'已存在（哪怕只是 Host 不同，比如'new'@'127.0.0.1'和'new'@'localhost'算两个） - 原用户被任何存储过程、函数、视图、事件的
DEFINER字段引用，且你没开SET_USER_ID权限（MySQL 8.0.22+ 默认拒绝） - 当前会话处于未提交事务中（哪怕只执行了
BEGIN没COMMIT），RENAME USER会被阻塞并最终超时报错
检查当前会话是否卡在事务里
很多人忽略这点：RENAME USER 是 DDL，要求会话必须处于自动提交模式或显式提交了所有事务。一个 BEGIN 后忘了 COMMIT，就会让后续所有 DDL 失败。
- 用
SELECT @@autocommit;确认是否为1；如果不是，先COMMIT;或ROLLBACK; - 查当前会话事务状态：
SELECT trx_state, trx_started FROM information_schema.INNODB_TRX WHERE trx_mysql_thread_id = CONNECTION_ID();，结果非空就说明有活跃事务 - 别依赖客户端 UI 的“事务图标”——有些工具（如 DBeaver）会静默开启事务，得手动关掉或切到新连接重试
验证用户是否存在及 DEFINER 关联对象
报 1396 时，先确认两边账户都“干净”：
- 查原用户是否存在：
SELECT User, Host FROM mysql.user WHERE User = 'old' AND Host = 'host'; - 查目标用户是否已存在：
SELECT User, Host FROM mysql.user WHERE User = 'new' AND Host = 'host'; - 找所有以该用户为 DEFINER 的对象：
SELECT routine_schema, routine_name, routine_type FROM information_schema.routines WHERE definer = 'old@host';（同样查views,events,triggers表） - 如果发现 DEFINER 引用，又不想升级权限开
SET_USER_ID，只能先ALTER PROCEDURE xxx SQL SECURITY DEFINER改掉定义者，或临时DROP再重建
权限检查不能只看 GRANT，要看系统表访问能力
RENAME USER 要求的不是普通数据库权限，而是对 mysql 系统库的写能力。即使你有 GRANT OPTION，也可能缺关键权限：
- 必须有全局
CREATE USER权限，或对mysql库的UPDATE权限（注意不是mysql.user表，是整个mysqlschema） - 若启用了
read_only=ON，还需CONNECTION_ADMIN（或旧版SUPER） - 验证方式：
SHOW GRANTS FOR CURRENT_USER;，重点看有没有GRANT CREATE USER ON *.*或GRANT UPDATE ON mysql.* - 别信
root就一定行——某些云托管 MySQL（如阿里云 RDS）会阉割CREATE USER权限，此时只能走新建用户+迁移权限路线
真正容易被绕开的点是 DEFINER 引用和隐式事务。这两个问题不会在错误信息里明说，但只要存在，RENAME USER 就必然失败，且重试无意义。动手前务必先扫一遍 information_schema 里的关联对象，再确认会话干净。
