在 MySQL 升级和迁移过程中，表锁问题可能影响服务可用性。关键在于减少锁表时间、避免长时间阻塞读写操作，并确保数据一致性。以下是具体处理方式。
理解表锁的触发场景
MySQL 在某些 DDL 操作或存储引擎不兼容时会引发表级锁。例如：
MyISAM 引擎执行 ALTER TABLE 会锁整张表 旧版本 InnoDB 对部分 DDL 不支持在线操作 跨版本升级时元数据变更可能导致短暂锁表明确当前使用的存储引擎和 MySQL 版本是否支持 Online DDL 是前提。
使用支持在线 DDL 的版本和配置
MySQL 5.6 及以上版本对 InnoDB 支持多数 Online DDL 操作。升级前确认目标版本支持 inplace 修改，避免 copy 表导致长时间锁。
设置 innodb_online_alter_log_max_size 防止大表变更时日志溢出 使用 ALGORITHM=INPLACE, LOCK=NONE 显式控制锁级别 例如：修改列可加默认值而不重build表检查语句是否真正“无锁”可通过 SHOW PROCESSLIST 观察是否有 Waiting for table metadata lock 的线程堆积。
分阶段迁移减少锁影响
对于不能热更新的场景，采用影子表或双写策略降低风险：
创建新结构的影子表，在后台同步旧表数据 通过触发器或应用层双写保障一致性 切换时用短时间 RENAME 原子操作替换原表（仅需短暂元数据锁）此方法适用于主从架构中的从库先行测试，再逐步切流。
选择维护窗口与监控锁状态
即便使用在线 DDL，复杂操作仍可能引起短时锁。建议：
在低峰期执行关键变更 提前设置 lock_wait_timeout 合理值防止长时间等待 实时监控 performance_schema.metadata_locks 表，发现阻塞及时干预迁移后验证表状态和索引完整性，防止因中断导致结构异常。
基本上就这些。核心是利用现代 MySQL 的在线能力，结合业务节奏规划操作时机，避免一刀切式的停机升级。
