最近，业务方觉得业务表int字段的精度不足，需要转移到decimal。 的数据库版本为2014，包含30多个表。 其中有9千万级的小馒头，不仅仅是一个场地。 这里有注意事项和遇到的问题
隐式转换问题：代码感知变量的类型必须改变。 关联表中字段的类型必须更改。 否则，这就是为性能炸弹编制索引的问题。 如果字段中有索引，则必须先删除。 更改类型时，必须记住性能问题。 删除索引之前必须停止对应业务sql。 否则，高同时全表扫描可瞬间因资源不足而屏蔽对应表的读写。 alter进程锁定表。 所有对该表的读写操作都将被阻止-- 2016年支持在线更改并从库日志应用进程将被阻止。 如果先前已对库进行了适当的较大查询，则会阻止日志应用进程，并逐渐发生主从延迟。 alter过程有大量的更新，小型小馒头非常费时间。 大量update会导致事务日志激增，并频繁扩展生产库的日志(注意磁盘空间) :每次利用率接近100%时，事务日志都会自动增加设置的量。 例如每次100M )。 如果在不更改此参数的情况下缺省设置为1M，则会等待较长的latch_ex(log_manager )，从而导致性能进一步下降。 阻止对系统表的读/写：在大量alter操作期间，也阻止对系统表的读/写。 如果在alter过程中注意到事务日志的自动增长设置为1M，则您可能会注意到此时不显示数据库选项，并且自动增长已被修改，因此建议您事先进行调整。 主从延迟：在从库中使用大量生成的事务日志。 如果主从库的性能存在差异，或者异地发生灾难，主从库的延迟可能会很明显，很难在短时间内实现均衡
暂时只想到了这些，如果有错误或者更好类型的修正方法，欢迎您的指正和补充。