MySQL账户切换本质是权限重映射与连接控制，需用SHOW GRANTS+GRANT逐条复制权限、显式处理WITH GRANT OPTION及角色、主动KILL旧连接，并验证DEFINER、FILE、REPLICATION CLIENT等边界权限。
MySQL 账户切换本质是权限重映射，不是“登录态迁移”
MySQL 没有类似操作系统用户 session 切换的概念，所谓“平滑切换”实际是指：在不中断应用连接的前提下，让新账户拥有旧账户的全部权限，并逐步将流量/连接导向新账户。核心动作是权限复制 + 连接回收控制，而非某种内置的 SWITCH USER 命令。
用 SHOW GRANTS FOR + GRANT 复制权限最可靠
直接导出旧账户权限语句再执行到新账户，比手动比对更少出错。注意权限粒度差异和隐式继承问题：
-
SHOW GRANTS FOR 'old_user'@'host'输出的每条GRANT语句必须逐条执行到新账户，不能只复制ON *.*级别就认为覆盖全部——比如mysql.db表级权限不会出现在全局语句里 - 若旧账户有
WITH GRANT OPTION，新账户是否需要继承？需显式加上该选项，否则无法转授 - MySQL 8.0+ 的角色（
CREATE ROLE）不能用SHOW GRANTS直接还原，得先查mysql.role_edges表或用SELECT * FROM performance_schema.role_table_grants - 示例：复制库级权限
SHOW GRANTS FOR 'old_user'@'192.168.%';<br>-- 输出可能含：<br>GRANT SELECT, INSERT ON `app_db`.* TO 'old_user'@'192.168.%'<br>-- 执行时替换为：<br>GRANT SELECT, INSERT ON `app_db`.* TO 'new_user'@'192.168.%';
连接不中断的关键是控制 wait_timeout 和主动踢掉旧连接
权限生效后，旧连接仍持有原账户身份，直到超时或断开。不能依赖“等它自己死”，得主动干预：
- 查旧账户活跃连接：
SELECT ID, USER, HOST, DB, COMMAND, TIME FROM information_schema.PROCESSLIST WHERE USER = 'old_user'; - 逐个
KILL前先确认无事务中操作（看COMMAND是否为Query、TIME是否过长） - 避免批量
KILL导致瞬时负载激增：可用脚本分批，每次最多 5 个，间隔 1 秒 - 应用侧应配置合理的
wait_timeout（如 60–300 秒），确保空闲连接自动释放，减少人工干预量
权限更替后必须验证三类边界场景
容易漏检的不是主流程，而是边缘权限行为：
- 触发器/存储过程内是否用到
DEFINER？若定义者是旧账户，执行时会报Access denied; you need (at least one of) the SUPER privilege(s)—— 得用ALTER DEFINER改为新账户或CURRENT_USER - 是否通过
LOAD DATA INFILE或SELECT ... INTO OUTFILE读写文件？这类操作依赖FILE权限，且受secure_file_priv限制，新账户必须单独授权且路径匹配 - 使用
mysqldump备份时是否加了--single-transaction？这需要REPLICATION CLIENT权限，常被忽略 - 代理用户（
PROXY）机制下，若旧账户是代理者，新账户必须显式GRANT PROXY ON 'target'@'%' TO 'new_user'@'%';
权限复制和连接切换本身不难，难的是旧账户散落在各种对象定义、备份脚本、监控配置里的隐式依赖。切完立刻查 information_schema.SCHEMATA_PRIVILEGES 和 TABLE_PRIVILEGES，比靠记忆更稳。
