1.2亿数据的表结构修改

tbl_order_detail 表目前存储1.2亿条数据，表中共56个字段。 字段pay_id采用tinyint数据结构，（带符号-128-127，无符号0-255）。随着业务的扩展，pay_id的字段需要扩充，修改为smallInt类型。

1. 新建tbl_order_detail_a表，与tbl_order_detail保持同样的数据结构（pay_id修改为smallInt类型）

2. 数据迁移，将tbl_order_tail中的数据迁移到tbl_order_detail_a表中

3. 后台线程跟踪binlog中tbl_order_detail表中数据的变更，并update到tbl_order_detail_a表中

4. 操作完成后， rename表名字，更改为tbl_order_tail为tbl_order_tail_b, tbl_order_detail_a更改为tbl_order_detail

注： 因数据量较大，步骤2&3 耗时约8个小时

1. 上午9点开始操作后，监控频繁报警。经追查，DB主从延迟，导致部分读操作无法读取新生成的订单。主要原因： 表数据迁移涉及到大量的insert操作，引发大量的主从复制，导致主从延迟超过1s，部分时间敏感的业务因查询不到订单数据而报错。（改为读主库？）

2. 考虑到白天业务调用频繁，改为晚上10点后执行操作，因夜间业务调用量减少，主从延迟导致的业务问题不存在了。但在执行上述第4步时，无法rename表tbl_order_detail为tbl_order_detail_b。 查找原因，重命名表时，需要获取表元数据锁（rename的内部执行逻辑），重试多次都无法获取元数据锁直接异常退出，操作失败。 为什么获取不到元数据锁？ 当表正在执行事务或查询数据时，无法获取到元数据锁，即sql执行期间，无法获取。所以rename时，mysql会重复多次，当某次成功时，则锁表重命名。当超过阈值时，则直接失败。 sql执行非常频繁会导致无法获取元数据锁，但凌晨5点多，业务调用量很低，不可能频繁到多次重试都拿不到元数据锁。 后来通过sql监控发现，在凌晨有一个定时任务在查询表数据，使用一个复杂sql，此sql执行时间接近50s,且定时任务重叠执行，即此sql永远在执行。导致永远无法获取到元数据锁，而无法重命名表。 DBA强制kill此条SQL，rename表成功。

1. 大规模的数据复制可能会引起主从延迟，风险需要规避

2. rename表名时，需要获取元数据锁。但大事务或者慢查询，可能会导致多次无法获取元数据锁，而rename失败。 所以需要及时清除慢查询和大事务。