MySQL临时账号须用CREATE USER显式创建并设密码过期，再GRANT最小库表级权限，配FLUSH PRIVILEGES；USAGE非无权，禁用WITH GRANT OPTION；连不上先查mysql.user中account_locked和password_expired状态。
MySQL 临时账号必须用 CREATE USER 显式创建，不能靠修改现有用户
直接 GRANT 给一个不存在的用户（比如 'temp123'@'%' ），MySQL 会静默失败或报错 ERROR 1133 (HY000): Can't find any matching row in the user table。5.7+ 默认 strict mode 下尤其明显。
临时账号不是“加个权限就行”，它本质是独立用户实体，得先落地再授权：
-
CREATE USER 'temp_qa'@'192.168.1.%' IDENTIFIED BY 'p@ss4temp' PASSWORD EXPIRE INTERVAL 1 DAY;—— 强制密码过期，避免遗忘清理 - 紧接着用
GRANT SELECT ON `app_db`.* TO 'temp_qa'@'192.168.1.%';授予最小必要权限 - 别漏
FLUSH PRIVILEGES;—— 虽然 8.0+ 多数情况自动刷新，但跨版本/配置时仍建议显式执行
权限范围要卡死到库表级，USAGE 不等于“没权限”
USAGE 是 MySQL 的“空权限占位符”，只表示能连上，不控制后续操作。给临时账号配 GRANT USAGE ON *.* 等于白忙活。
真实场景中常见误操作：
- 用
GRANT SELECT ON *.*—— 会暴露information_schema、系统表，甚至其他业务库 - 忘记
WITH GRANT OPTION的传染风险 —— 临时账号绝不能带这个选项 - 用
localhost测试没问题，上线却连不上 —— 检查 host 是否匹配客户端真实 IP，别硬写127.0.0.1或::1
推荐写法：GRANT SELECT (id, name, created_at) ON `reporting`.`orders_2024` TO 'temp_qa'@'192.168.1.%'; —— 字段级限制进一步收口
自动失效靠 PASSWORD EXPIRE，别依赖定时任务删账号
MySQL 5.7+ 支持原生命令级过期控制，比写 shell 脚本或 cron 更可靠。设了 PASSWORD EXPIRE 后，用户首次登录就会被强制改密；若配合 FAILED_LOGIN_ATTEMPTS 3 和 PASSWORD_LOCK_TIME 1，还能防暴力试探。
但要注意兼容性陷阱：
- MySQL 5.6 及更早版本不支持
PASSWORD EXPIRE，必须降级用SET PASSWORD+ 外部调度 - 客户端驱动（如 Python 的
pymysql）遇到密码过期会抛ER_MUST_CHANGE_PASSWORD，需在连接逻辑里捕获处理，否则服务直接崩 - 如果用了 ProxySQL 或中间件，它们可能缓存认证结果，导致过期后仍能通行一段时间
临时账号连不上？先查 mysql.user 里的 account_locked 和 password_expired
权限都给了，host 也对，还是连不上，大概率是状态字段卡住了。直接查表比翻日志快得多：
SELECT user, host, account_locked, password_expired, password_last_changed FROM mysql.user WHERE user = 'temp_qa';
常见组合问题：
-
account_locked='Y'：说明之前输错密码太多次，需ALTER USER 'temp_qa'@'%' ACCOUNT UNLOCK; -
password_expired='Y'且客户端不支持改密流程 —— 换成ALTER USER 'temp_qa'@'%' PASSWORD EXPIRE NEVER;应急 -
password_last_changed是 NULL：说明账号创建时没设密码，或者用了空密码（不安全，且 8.0+ 默认禁用）
真正麻烦的是权限生效延迟：MySQL 权限变更在服务端立即生效，但某些连接池（如 HikariCP）会复用旧连接，得重启应用或清空连接池
