答案：通过使用支持Online DDL的MySQL版本、显式控制锁级别、采用影子表分阶段迁移，并在低峰期执行变更，可有效减少表锁时间与阻塞，保障升级迁移过程中的服务可用性和数据一致性。
在 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 的在线能力，结合业务节奏规划操作时机，避免一刀切式的停机升级。
