ClickHouse中DateTime64类型在CSV导入时的精度问题解析

问题背景

在使用ClickHouse数据库时，开发人员发现当使用date_time_input_format=best_effort设置配合CSV格式导入数据时，DateTime64类型的时间戳会丢失毫秒精度。这是一个值得关注的数据精度问题，特别是在需要精确时间记录的金融、物联网等应用场景中。

问题复现

通过以下测试可以清晰地复现该问题：

1. 创建测试表：

CREATE TABLE ts_test(
    type String, 
    created_at DateTime64(6, 'UTC') DEFAULT now()
) ORDER BY created_at

2. 使用不同格式插入数据：

-- 使用VALUES格式插入，毫秒精度保留
INSERT INTO ts_test (type, created_at) 
SETTINGS date_time_input_format='basic' 
VALUES('basic', 1744042005.797)

-- 使用CSV格式插入，毫秒精度丢失
INSERT INTO ts_test (type, created_at) 
SETTINGS date_time_input_format='best_effort' 
FORMAT CSV
'best_effort-csv',1744042005.797

查询结果显示，通过CSV格式导入的时间戳丢失了毫秒部分，变成了.000000。

技术分析

这个问题实际上包含两个独立但相关的技术点：

1. 最佳解析模式(best_effort)对Unix时间戳的支持不足：

   • 当前实现中，parseDateTime64BestEffort函数无法正确处理带有小数部分的Unix时间戳
   • 当遇到类似"1744042005.797"的输入时，解析会在小数点处失败
   • 这是一个可以改进的功能限制，而非严格意义上的bug

2. CSV格式解析中的错误处理问题：

   • 当使用best_effort模式解析CSV中的时间戳时
   • 解析器在遇到Unix时间戳的小数部分后没有正确报错
   • 而是静默地忽略了剩余部分继续解析
   • 这属于需要修复的bug行为

深入理解

值得注意的是，当使用VALUES格式而非CSV格式插入数据时，即使使用best_effort模式，时间戳的毫秒精度也能正确保留。这是因为VALUES格式具有特殊的处理逻辑：

1. VALUES格式会先尝试将输入作为表达式解析
2. 如果解析失败，才会尝试作为文本反序列化
3. 在表达式解析阶段，字符串字面量"1744042005.797"会被直接转换为数值
4. 然后通过CAST操作转换为DateTime64类型

这种"fallback"机制解释了为何VALUES格式下精度得以保留，而严格的CSV格式解析则没有这种备用路径。

最佳实践建议

对于需要处理高精度时间戳的场景，建议：

1. 优先使用basic模式而非best_effort模式
2. 考虑使用ISO格式的时间字符串而非Unix时间戳
3. 对于CSV导入，可以先检查数据精度是否被正确保留
4. 在关键业务场景中，增加数据验证步骤确保时间精度符合要求

总结

ClickHouse中DateTime64类型的时间精度处理在不同输入格式下表现不一致，这反映了底层解析逻辑的差异。开发人员在使用时应当了解这些差异，根据实际需求选择合适的输入格式和解析模式。对于需要毫秒级精度的应用场景，建议采用basic模式或确保输入格式的一致性。