在实际客户场景中，遇到了一个表字段精度修改的问题。客户想将一个 number 类型字段的小数精度从 12 提升到 13（即由原来支持 2 位小数，提升为 3 位小数），但在执行时数据库却报错：这是很多人在数据库操作中容易踩到的坑 —— 不能直接修改有数据的字段精度。
图4:案例二背景
现场应对方案
一线同事第一时间提出的解决思路是：“既然不能直接改，那我就加一个新列，把老列的值复制进去，再删掉老列。尽管并行加速能解决部分性能问题，但是：运行这种方式其实不是较优方案，并没有解决所有的问题。”
图5:前期四种方案对比
后来，我们对这个问题进行了深入分析，逐步还原了背后的技术根因，发现主要问题在于以下几点：
新增字段并灌入数据，会导致每行记录的长度增加；
原表数据已经接近满页，此时一旦数据变长，原有位置放不下，就会引发 行迁移（row migration）；
行迁移会带来显著的性能问题，特别是后续的查询、更新操作可能明显变慢；
此外，删除列的操作本身也潜藏高风险，比如可能涉及元数据修改、对象锁定等，稍有不慎就会影响线上业务。
二线优化建议
针对这个场景，二线提出了几条实用的优化建议，希望为大家后续处理类似问题提供参考：
优先评估是否可以采用在线重定义（Online Redefinition）或其他更平滑的方式替代直接操作原表，从而降低对生产系统的冲击；
尽量避免大范围的 UPDATE操作，可以考虑分批、按条件进行更新，降低资源消耗；
如果确实需要新增列并更新数据，应事先评估表空间使用情况，防止触发大规模行迁移；
在删除列之前，务必要做好备份和演练，确保不会对元数据造成不可逆的破坏。
图6:优化方案：在线重定义
图7:优化方案：在线修改
