mysqldump报Access denied主因是权限缺失而非密码错误，需授予SELECT、LOCK TABLES、SHOW VIEW、TRIGGER四类最小权限，全局PROCESS权限用于--single-transaction，且必须执行FLUSH PRIVILEGES生效。
mysqldump报Access denied：不是密码错，是权限缺
直接结论：mysqldump 报 Access denied for user 'xxx'@'localhost'，90% 以上不是输错密码，而是账号没被授予 SELECT、LOCK TABLES、SHOW VIEW、TRIGGER 这四类最小必要权限。哪怕你能用该账号登录并执行 SELECT * FROM t1，也不代表能跑 mysqldump——它会额外查 information_schema、尝试锁表、读视图定义、抓触发器元数据。
必须补全的四类基础权限（按库授予）
验证方式很简单：mysql -u root -p -e "SHOW GRANTS FOR 'backup_user'@'localhost';"。如果返回里只有 USAGE 或只含 SELECT，那就确认缺权限了。
-
SELECT：读取表数据（必需） -
LOCK TABLES：一致性导出（单库备份未加--single-transaction时必需） -
SHOW VIEW：库中有视图时必加，否则报SHOW VIEW command denied -
TRIGGER：表有触发器时必加，否则在SHOW CREATE TABLE阶段失败
授权命令示例（限定到具体库，不碰 *）：GRANT SELECT, LOCK TABLES, SHOW VIEW, TRIGGER ON `app_db`.* TO 'backup_user'@'localhost';
授完权后必须执行 FLUSH PRIVILEGES;，否则不生效。
--single-transaction 仍失败？可能缺 PROCESS 权限
当你加了 --single-transaction（InnoDB 推荐），却仍报类似 Access denied; you need (at least one of) the PROCESS privilege(s)，说明 mysqldump 正在尝试读取表空间或线程状态信息——这是默认行为，且 PROCESS 是全局权限，不能按库授予。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 典型触发场景：
--all-databases、未加--no-tablespaces、使用 GreatSQL/Percona 等变种 - 解决方法：
GRANT PROCESS ON *.* TO 'backup_user'@'localhost'; FLUSH PRIVILEGES; - 若安全要求极高，可用
--no-tablespaces绕过，但需确认目标库是否依赖表空间特性
恢复时权限不足的常见报错和对应权限
执行 mysql -u user -p mydb 时，常见报错不是备份问题，而是恢复权限缺失：
-
ERROR 1142 (42000) at line X: CREATE command denied→ 缺CREATE权限 -
ERROR 1044 (42000): Access denied for user @ to database→ 用户对目标库无任何权限（连USAGE都没） -
ERROR 1227 (42000): Access denied; you need ... SUPER privilege→ 备份含DEFINER，但用户没有SET_USER_ID（MySQL 5.7+）或SUPER（旧版）
恢复前应确保用户具备：CREATE、DROP、ALTER、INSERT、CREATE VIEW、CREATE ROUTINE 等——这些权限容易被当成“备份权限”忽略，其实完全独立。
最容易被忽略的是：权限名大小写不敏感，但 host 字符串（如 'backup_user'@'localhost' 和 'backup_user'@'127.0.0.1'）是严格区分的；FLUSH PRIVILEGES 不执行就等于没授权；PROCESS 必须全局授予，无法限定到库。
