MySQL 运维恢复与排错：备份、执行计划和锁等待
本轮仅全文静态审计，未安装依赖、启动服务、连接数据库或执行任何示例。下文实测、RED/GREEN及平台结果均为此前历史证据；本轮修改后的脚本未运行，命令与输出作为学习步骤和预期保留。
逻辑备份与独立恢复
前置：完整CLI验收。备份文件存在不等于能恢复；应在独立目标导入并查询确认表结构、行数、关键值和编码。本项目已在同一Linux MySQL服务的新库inventory_restore中恢复，逐行比较商品和预留，明确核对中文数据库📘，不只比ASCII数量。
仓库根目录运行（Bash改用.venv/bin/python）：
examples/mysql/inventory/.venv/Scripts/python.exe -X utf8 examples/mysql/inventory/backup_restore.py脚本源码见同一份完整文件。输出dumpBytes、SHA256、restored和equal=true，备份生成examples/mysql/inventory/inventory-backup.sql。目标已存在时CREATE DATABASE失败并非零退出，先人工检查该库是否确实只是自己的旧实验，再决定如何处理，不添加自动全局清理。Windows和Linux均通过字节流传递SQL，mysqldump与mysql明确--default-character-set=utf8mb4。
等价Linux命令形态如下，仅对新空恢复库执行。root权限只限教学容器；生产用备份专用最小权限账号和选项文件，不把密码写入Shell历史：
mysqldump --single-transaction --no-tablespaces --set-gtid-purged=OFF --default-character-set=utf8mb4 -u backup -p inventory_lab > inventory.sql
mysql -u restore -p -e 'CREATE DATABASE inventory_restore CHARACTER SET utf8mb4'
mysql --default-character-set=utf8mb4 -u restore -p inventory_restore < inventory.sql
mysql --default-character-set=utf8mb4 -u restore -p inventory_restore -e 'SELECT sku,name,stock FROM products ORDER BY sku'--single-transaction为InnoDB读取一致性视图，备份期间避免并发DDL；它不保证MyISAM等非事务表的一致性。--no-tablespaces省略表空间语句，--set-gtid-purged=OFF适合本课程独立逻辑导入，不构成主从恢复方案。未指定--databases，因此dump不应自行USE覆盖源库；导入指定inventory_restore。生产还需用户/授权、触发器/事件/例程选项、加密、备份异地保留及定期恢复演练。完整时间点恢复依赖有效全备与连续binlog，本批没有验收binlog回放或主从切换，不能承诺任意时间点零丢失。
恢复期间暂停本实验CLI写入：导出后的源库比较不与导出共享快照，并发写入可能使正确恢复也比较不等。脚本统一UTC读取created_at并比较全部存储列；它不是表结构逐项比较工具，还应核对SHOW CREATE TABLE与DDL。本地inventory-backup.sql会先被覆盖，即使目标库已存在；旧备份需先另存。
连接和认证故障
按“客户端版本→地址端口→服务状态→凭据来源→库和权限→SQL”逐层定位，不先降低安全设置。
| 现象 | 先检查 | 本课程的处理 |
|---|---|---|
| 2003 Can't connect / Connection refused | docker ps、端口映射、mysqladmin ping | 宿主连127.0.0.1:23306，容器内服务是3306 |
| 1045 Access denied | MYSQL_USER、MYSQL_PASSWORD、Host授权、旧volume初始化 | 使用lab实验账号，重设-e不改已有密码 |
| 1049 Unknown database | MYSQL_DATABASE及首次初始化日志 | 必须是inventory_lab，恢复用inventory_restore |
| 2059 caching_sha2_password无法加载 | 实际客户端/驱动版本和插件支持 | 升级兼容客户端，8.4默认禁用mysql_native_password，不能照搬旧文ALTER降级 |
| 1062 Duplicate entry | 唯一键及请求业务意图 | 核对原幂等键参数，不删除旧记录后盲重试 |
| 3819 CHECK constraint violated | 负库存、数量及SQL参数 | 回滚事务；修正调用输入，不能关闭约束 |
| 1205 Lock wait timeout | 持锁连接、事务时长与索引 | 回滚整笔业务后决定有限重试 |
| 1213 Deadlock found | 锁顺序、最近死锁、访问范围 | 统一锁顺序；从完整事务起点有界重试 |
本批实际触发3819与1205，1213给出诊断知识而未声称运行了死锁复现。旧版密码重置涉及停服与跳过授权表，属于受控恢复流程，不是普通连接排错的下一步；此处不提供可误用的通用停服命令。
锁等待与长事务诊断
在隔离实验容器中用root查看；应用账号不应为看监控被授全局管理权限：
SHOW PROCESSLIST;
SHOW ENGINE INNODB STATUS;
SELECT trx_id,trx_started,trx_mysql_thread_id FROM information_schema.innodb_trx;
SELECT REQUESTING_ENGINE_TRANSACTION_ID,BLOCKING_ENGINE_TRANSACTION_ID
FROM performance_schema.data_lock_waits;PROCESSLIST看会话状态，INNODB STATUS包含最近死锁与引擎信息，innodb_trx帮助找长事务，data_lock_waits关联请求者与阻塞者。只看一个时间点可能错过瞬时等待，应结合应用请求ID、时间与慢日志。KILL前先识别事务归属和回滚代价，不能把所有Sleep连接都当坏连接：Sleep也可能有未提交事务。
慢查询、容量和维护
MySQL 慢查询诊断先记录查询文本的脱敏形态、参数分布、实际耗时与扫描行数，再查看EXPLAIN。容量判断还需结合并发请求、数据增长和缓存命中，不能只从单次慢SQL推断。全表扫描不自动等于错误，低选择性查询可能值得全扫；索引越多也会增加磁盘、缓存和写入成本。EXPLAIN估算偏差大时考虑统计信息、数据倾斜和条件相关性，而不是只调整一个全局buffer参数。
mysqldump耗时和恢复耗时决定恢复目标能否满足；本课程小数据恢复成功不证明TB级恢复速度。监控至少关注连接数、事务/锁等待、慢SQL、磁盘空间、复制延迟（若有复制）和备份新鲜度；告警阈值必须匹配负载基线。旧Prometheus/Grafana面板仍是特定部署资料，不与此通用诊断合并为已验证监控平台。
实验资源的检查和退出
docker inspect showdocs-m4-mysql-server检查映射、挂载与镜像，docker logs showdocs-m4-mysql-server看初始化/启动错误。停止可用docker stop showdocs-m4-mysql-server；容器停止后专用volume仍保留数据。需要重做空库初始化时，应先确认无需要保留的数据，再只针对本任务命名资源操作；不要运行docker system prune或删除所有volume。
旧管理员密码恢复记录的适用边界
MySQL 管理员密码恢复为什么不能当普通连接排错？连接拒绝先查服务、地址和端口；Access denied 要核对凭据、来源 Host 与 User、目标库和授权。管理员失去有效凭据的恢复是另一个受控维护场景，要先确认版本、实例、备份、维护窗口与网络隔离，不应从普通登录失败直接进入跳过授权表。
MySQL 账号由 Host 与 User 共同识别，不能只按 user='root' 更新所有同名行。原记录来自5.7.29，直接修改 mysql.user.authentication_string、调用 PASSWORD() 以及停服/重启顺序不作为8.4恢复命令。认证插件、系统表和账号管理机制有版本差异，应采用目标版本明确支持的恢复流程，不能跨版本复制系统表更新。
旧 user 表中的权限列 N 改为 Y 并非修复登录的通用办法：认证成功与具体授权是不同问题；批量提升权限会改变账号安全边界。原文 N→Y 建议、直接mysql.user更新和把旧工具去密码作为恢复步骤均明确撤回。需要的授权由实际职责决定，不能为了连上而授予全部权限。
本节没有提供或执行恢复CLI，未验证MySQL8.4管理员恢复，也不承诺旧日志中的“修改成功”可在其他环境复现。恢复结束还需按真实流程撤销临时配置、恢复访问控制、验证目标账号及保留审计证据；这是一份场景边界说明，不能替代经授权的版本专用操作方案。
继续阅读
- 知识专题
- 应用实践
- 知识专题