背景

在一次数据排查时，无意间发现数据对不齐。结合代码及日志分析发现都没问题，且有插入操作，但是 Clickhouse 却查不到改条记录。匪夷所思....

排查过程

最后断定大概率是 Clickhouse 的问题，难道 Clickhouse 存在数据丢失的情况？进一步分析丢失数据部分时间分布发现并无任何规律，排除 Clickhouse 可能出现的定时故障问题。

无奈只能找公司 DBA 寻求帮助，得出大概率是 Clickhouse 的 ReplicatedReplacingMergeTree 问题。该业务表结构大致如下

-- auto-generated definition
create table t_product_request_log_local
(
    id                      String,
    merchant_id             String,
    product_code            String,
    order_no                String,
    spend_time              UInt16,
    create_time             DateTime default toDateTime(now())
)
    engine = ReplicatedReplacingMergeTree('/***/{shard}',
                                          '{replica}')
        ORDER BY (create_time, merchant_id, product_code, order_no)
        SETTINGS index_granularity = 8192;

其中若是高并发场景 ORDER BY 相当于主键，使用该存储引擎的话聚合的字段可能一致，而 order_no 字段由于历史设计问题部分数据该字段存储和的为外部时间戳，因为导致多条数据被聚合为一条数据插入。

为了验证这一猜想，编写了一个批量插入的 SQL 发现，虽然 SQL 执行成功但是确实无重复的数据，而修改变更其中某个字段值即又能正常插入得出数据。

解决

因此需在 ORDER BY 中新增一个唯一字段，使得后期插入数据唯一即可。因此在 ORDER BY 新增 ID 列得解。