本篇主要讲解一下使用 doris 的主键模型时，需要指定 sequence_col ，如何选择合适的字段是值得思考的
文章内容主要来源于生产环境实践，仅将脱敏部分放出来供大家参考
Doris 的主键模型表需要指定 sequence_col 列来去重数据，在通过 mysql -> binlog -> flink -> doris 链路处理 MySQL 数据同步时需要自行处理这个字段
sequence_col 用来指定 sequence 列到表中某一列的映射，该列可以为整型和时间类型（DATE、DATETIME），创建后不能更改该列的类型。
有以下几种方案来做 sequence_col，需要各位根据自身业务情况选择，没有银弹呦~
注：以下方案均是在没有版本号字段的情况下的选择，如果您的业务有版本号字段，那么可以考虑版本号字段（注意更新要符合预期）
| 方案 | 更新不冲突 | 全量流多次处理 | 主库迁移 | 不受时钟回拨影响 | 不受offset重复消费影响 | 支持非顺序消费 | 不漏更新 | 说明 |
|---|---|---|---|---|---|---|---|---|
| update_time | ❌ | ✅ | ✅ | ❌ | ✅ | ✅ | ❌ | 毫秒级时间戳存在较低的冲突可能 时钟回拨时会导致丢失数据 update_time 可能漏更新 |
| binlog_time | ❌ | ✅ | ✅ | ❌ | ✅ | ✅ | ✅ | 秒级时间戳存在较高的冲突可能 时钟回拨时会导致丢失数据 |
| GTID | ✅ | ❌ | ❌ | ✅ | ✅ | ✅ | ✅ | 主库迁移 GTID 会重置，需人工介入 无法通过 Task 或重复消费全量流做数据刷新 如果是单主，在检测到主库变更时可以通过计算修正 seq 的偏移，解决不能应对迁移的问题 |
| 逻辑时钟 + 顺序性消费 | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ✅ | 重复消费时会导致旧数据覆盖新数据但最终一致 多线程消费会乱序无法确保最终为最新版本 |
| binlog_time + 逻辑时钟 + 顺序性消费 | ✅ | ✅ | ✅ | ❌ | ✅ | ❌ | ✅ | 在顺序性消费的情况下，使用缓存存储2秒的数据，遇到相同时间就+1（本地缓存在重启时可能出现版本号回拨，存到 redis 可以避免该问题，但性能会差一点并依赖了额外中间件） 时钟回拨时会导致丢失数据 |