MariaDB数据库持久化补丁设计咨询：防止同步脚本覆盖修改

1. 同步脚本内置补丁校验逻辑 #

修改现有同步脚本，在执行数据更新前，先查询专门的补丁元数据表（类似思路1的patch表，需给table_name+primary_key+column建立联合索引），针对每一行的每个字段：

• 如果补丁表存在对应记录，就用补丁值覆盖源库同步过来的值；
• 不存在则正常使用源库值执行更新。

优点：

• 应用层查询无需关联补丁表，数据直接落地为最终状态，不影响查询性能；
• 补丁管理集中，便于维护和追溯。
  缺点：
• 需要修改同步脚本的更新逻辑，增加了脚本复杂度；
• 每次同步都要做补丁校验，补丁量虽小但会略微增加同步耗时。

2. 利用MariaDB触发器拦截非法覆盖 #

创建BEFORE UPDATE触发器，针对需要保护的业务表，在同步脚本执行更新操作时，自动校验补丁表中的记录，将被修改的补丁字段值强制恢复为补丁值。示例代码：

DELIMITER //
CREATE TRIGGER protect_user_patched_cols BEFORE UPDATE ON `user`
FOR EACH ROW
BEGIN
    -- 校验并恢复name字段的补丁值
    DECLARE patched_name VARCHAR(100);
    SELECT patched_value INTO patched_name 
    FROM patch 
    WHERE table_name = 'user' AND primary_key = OLD.id AND column = 'name';
    
    IF FOUND_ROWS() > 0 THEN
        SET NEW.name = patched_name;
    END IF;
END //
DELIMITER ;

同时可以给同步脚本添加会话标记（比如SET @sync_running = 1;），触发器中仅当@sync_running为1时执行校验，避免手动更新时触发逻辑冲突。

优点：

• 应用层和查询逻辑完全无需修改，对业务透明；
• 精准保护指定字段，不会像思路2那样锁定整行。
  缺点：
• 每个业务表都需要单独创建触发器，维护成本随表数量增加而上升；
• 触发器会增加数据库的行级更新开销，高并发场景下需评估性能影响。

3. 行级版本化补丁标记 #

给每个业务表新增patch_version字段（INT类型，默认值为0）：

• 手动打补丁时，将目标行的patch_version设为一个极大值（如999999）；
• 修改同步脚本，仅更新源库中last_updated晚于上次同步时间，且目标表中对应行patch_version = 0的记录；
• 当源库中被补丁标记的行发生更新时，同步脚本触发告警（如邮件、企业微信通知），由管理员评估是否保留补丁或更新补丁内容。

优点：

• 无需额外维护补丁表，补丁标记直接存在业务行中；
• 能智能区分需同步和需保护的行，减少不必要的同步操作。
  缺点：
• 依赖源库提供增量同步能力（如带有last_updated时间戳字段）；
• 源库更新补丁行时需要人工介入，无法完全自动化。

4. 用视图封装补丁合并逻辑 #

创建业务视图，将原表与补丁表做关联，查询时优先返回补丁表中的值，原表值作为兜底。示例视图SQL：

CREATE VIEW v_user AS
SELECT
    u.id,
    COALESCE(p1.patched_value, u.name) AS name,
    COALESCE(p2.patched_value, u.age) AS age,
    u.create_time
FROM user u
LEFT JOIN patch p1 ON u.id = p1.primary_key AND p1.table_name = 'user' AND p1.column = 'name'
LEFT JOIN patch p2 ON u.id = p2.primary_key AND p2.table_name = 'user' AND p2.column = 'age';

应用层统一查询视图而非原表，同步脚本仍直接操作原表。

优点：

• 同步逻辑完全无需修改，补丁与原数据分离存储；
• 应用层只需切换查询对象为视图，改动极小。
  缺点：
• 视图关联会带来一定的查询性能损耗，字段越多关联逻辑越复杂；
• 若业务表有大量字段，视图的SQL编写和维护会比较繁琐。

内容的提问来源于stack exchange，提问作者Se7enDays