在卓创源码网接触到的二次开发项目里，改代码往往不费事，费事的是数据。一条改表语句下去，线上几十万行数据一起动，出了状况回退比改回来难得多。二次开发中的数据库变更 看着是一行 SQL 的事，实际牵动的是整张表的读写节奏，还有所有依赖这张表的旧功能。源码二次开发数据库变更 这一环，处理的其实是数据的退路问题。卓创源码网在整理这类改造记录时，最看重的就是这条退路。
一、先问一句：旧数据怎么办
动手前第一个问题不是”怎么改”，而是”改完旧数据还在不在原来的位置上”。新加字段在旧记录里是空的，旧功能读不到值，靠默认值兜住；但要改已有字段的类型或含义，就得考虑怎么把旧值搬过去。
搬的方式三种：写脚本逐条更新、在查询层兼容、或者放弃旧值重新灌。选哪种取决于旧数据的价值——还在用就走脚本，没人看就重新灌。
在卓创源码网整理源码说明时，字段含义这一项我们都会单独标注，改结构之前不看清楚，很容易把旧数据当成新结构写。
二、加字段优先”只加不改”
最省心的做法是只加不改：新字段在表末尾追加，带上默认值，旧代码看不到这个字段也不受影响。二次开发加字段要不要改旧数据，很多时候答案是不动。
为什么不动更有价值？表结构越接近原地改写，历史数据波及范围越大。改字段类型可能触发整表重写，改字段含义则可能让依赖它的旧功能静默出错——不报错，但算出来的数不对。
经验是：新需求优先用新字段承载，实在要复用旧字段再单独安排迁移。软件二次开发 里牵动表结构的活儿，先把这句话摆在桌面上。
三、变更脚本怎么管理
数据库变更脚本怎么管理？三条规矩：一，脚本放独立目录，按时间顺序命名；二，每个脚本只做一类事，别把加字段和建索引混在一起；三，已经执行过的脚本不要改，要调整就再补一个脚本。
第二条尤其重要。混在一起的脚本一旦执行到一半失败，很难判断哪部分已经生效。
脚本还要写清用途，一行注释说明这次变更对应哪个需求。三个月后有人问这张表为什么多一列，答案就在那行注释里。卓创源码网在整理改造建议时，也常提到把变更脚本单独归拢。
四、备份先行，但不是随手拷一份
二次开发改表结构怎么备份？拷一份文件比不拷强，但更稳妥的是两种一起做：一次完整的库导出，再加一个结构单独导出。结构文件小，存进版本库，出问题时一眼能看出改了什么。
备份本地一份、服务器一份，两边都确认能解开。
发布前把备份做完并验证一遍，比发布后再补要省事得多。验证的做法很直白：解开看看表数量对不对。
五、索引和查询跟着一起看
字段一多，查询就容易变慢。二次开发索引怎么调整？先看新加的字段有没有参与查询条件，没有参与就不必急着建索引；参与了，再看这张表的读取量决定要不要建。
索引不是越多越好。每个索引都会让写入变慢一点，写入频繁的表尤其明显。
另一点常被忽略：查询语句里字段的写法要和索引对得上。加了索引但查询时把字段套了函数或做了类型转换，索引就用不上。卓创源码网整理改造说明时，通常会连着查询写法一起标出来。
六、改错了怎么退
数据库变更是有退路才敢动手的。退路分两层：结构退回去靠脚本逆向执行，数据退回去靠备份还原。两者配合，才算完整。
二次开发改表结构怎么回退？顺序很关键：先把代码退回去，再退结构。反过来做，新代码遇到旧结构可能直接报错，问题现场就没了。删字段这类不可逆的动作，尽量别和发布混在一起。卓创源码网整理这类改造记录时，也会把回退顺序写在前面。
如果这次变更还没上线，那就更省事——本地的库直接重来一遍，事后再按干净的方式重做一遍脚本。
七、几个容易忽略的地方
二次开发中的数据库变更 有哪些坑？一是字符集变更，导入的旧数据可能带着原来的编码，改完表字符集要顺手核对；二是时区字段，前后不一致会让记录时间整体偏移；三是自增主键的起点，改表时可能被重置，接着插入的数据就会撞上已有记录。
这三条都属于不改代码、只改结构就能引出的问题，也是最难在测试阶段发现的。
数据库变更有哪些坑，再补一条：表里有历史遗留的重复数据时，脚本更新可能只改到其中一条，剩下的就漏了。卓创源码网核对源码结构时，遇到这类遗留问题会单独标出来。
数据库变更要注意什么，还有一条：脚本要在测试库上跑一遍。大表上耗时长的操作，在小表上试不出来。
八、可以对照参考的几类源码
源码二次开发怎么迁移数据，说到底取决于原表的结构设计。字段命名统一、主键清晰、索引到位的老项目，迁移起来顺；字段含义靠猜的项目，动一次要翻半天注释。
下面几类源码在数据结构说明和改造提示上比较有代表性，适合动手前先评估：
加字段怎么写默认值，我的做法是：新字段给一个业务上说得通的默认值，而不是随手填个零；涉及状态和金额的字段，宁可留空配合代码里的空值判断。卓创源码网在整理改造说明时，也会把字段含义和默认值一起标出来，动手前看一遍能省不少事。
请登录后查看评论内容