# 1. ClickHouse 列存（Column-Oriented）原理，每列独立文件存储，查询仅读取所需列，配合 LZ4/ZSTD 压缩与 SIMD 向量化执行实现高吞吐分析？ A 数据按行存储 B 列存无法压缩 C 每列独立文件存储，查询只读所需列，配合 LZ4/ZSTD 压缩与 SIMD 向量化实现高吞吐分析 ✓ 正确答案 D 列存适合点查
# 2. ClickHouse 写入路径，INSERT 先写内存 buffer → 生成 part 目录 → 后台 merge 合并小 part；为何单次 INSERT 建议 ≥1000 行、避免逐行写入？ A 逐行写入效率最高 B INSERT 直接更新已有 part C INSERT 生成 part 目录，后台 merge 合并小 part；单次插入 ≥1000 行可减少 part 数量、提升性能 ✓ 正确答案 D part 数量与查询性能无关
# 3. ClickHouse 复制机制，ReplicatedMergeTree 通过 ZooKeeper/ClickHouse Keeper 协调副本间的 part 日志与 mutation，多副本写入如何保证最终一致？ A 各副本独立写入，无需协调 B 通过 ZooKeeper/Keeper 协调 part 日志与 mutation，多副本异步同步达到最终一致，ZooKeeper 可用性影响复制 ✓ 正确答案 C 副本间无去重 D 复制是同步实时的
# 4. ClickHouse 的 MergeTree 写入路径，插入→临时分区→后台 merge 的全过程？ A INSERT 直接写入最终分区，无临时阶段 B INSERT 先写临时 part，再后台 merge 合并到最终分区，part 不可变、异步合并保证高吞吐 ✓ 正确答案 C merge 是同步的 D part 可以原地修改
# 5. ClickHouse 的分区（PARTITION BY）与分区裁剪、part 生命周期（detach/attach、DROP PARTITION）管理 A 分区不影响查询 B DETACH 会物理删除数据 C 分区裁剪跳过无关分区提升效率，DETACH 分离数据、DROP PARTITION 物理删除分区 ✓ 正确答案 D 无法按分区管理数据
# 6. ClickHouse 的编码压缩，LowCardinality、Delta、DoubleDelta、Gorilla 分别适合什么数据分布？与 LZ4/ZSTD 如何配合？ A LowCardinality 适合低基数重复值，Delta/DoubleDelta 适合有序时序，Gorilla 适合浮点时序，再配合 LZ4/ZSTD 块压缩 ✓ 正确答案 B Delta 适合随机数据 C LowCardinality 适合高基数数据 D 编码与块压缩互斥
# 7. async_insert 与 Buffer 引擎如何缓冲小批量写入以减少 part 数量？缓冲带来的可见性延迟与丢数据风险如何取舍？ A 它们缓冲小写入合并成批量以减少 part、提升吞吐，但带来可见性延迟与崩溃丢数据风险 ✓ 正确答案 B 它们立即落盘无延迟 C 缓冲不增加吞吐 D 它们直接写入小 part
# 8. ClickHouse 的稀疏主键索引（每 8192 行一个 mark）与跳数索引（minmax/set/bloom_filter）如何协同加速查询？ A 主键索引处理主键裁剪，跳数索引（minmax/set/bloom_filter）处理非主键列裁剪，多级过滤减少扫描 ✓ 正确答案 B 两者都只能过滤主键 C 跳数索引取代主键索引 D 跳数索引无构建开销
# 9. ClickHouse 与 Kafka 集成（Kafka 引擎表 + Materialized View）实现实时摄入的架构与延迟特征？ A 数据是毫秒级精确实时 B Kafka 引擎表消费，物化视图把数据写入目标表，延迟通常为秒级/亚秒级 ✓ 正确答案 C 物化视图不参与写入 D 目标表只能是普通表
# 10. ClickHouse 的 Projection 与物化视图在预聚合加速上的差异与适用场景？ A 两者完全相同 B Projection 需要改查询 C 物化视图对查询透明 D Projection 是表内物理预聚合，查询透明自动使用；物化视图是独立目标表，需显式管理 ✓ 正确答案
# 11. ClickHouse 副本机制（ReplicatedMergeTree/ZooKeeper）的同步与冲突解决？ A 副本各自独立不同步 B 冲突无法解决 C 副本无去重机制 D 副本通过 ZooKeeper 协调 part 日志同步，用块校验和与日志去重解决冲突，最终一致 ✓ 正确答案
# 12. ClickHouse 查询的向量化执行与列裁剪、分区裁剪如何协同？ A 分区裁剪定范围、列裁剪定列、向量化执行批量计算，协同减少 IO 与计算 ✓ 正确答案 B 三者互不相关 C 向量化取代裁剪 D 列裁剪增加 IO
# 13. ClickHouse 的 Part 与索引，primary.idx、skip index 与 merge？ A 索引是全局唯一的 B part 无索引 C merge 不重建索引 D 每个 part 含 primary.idx 主键索引与跳数索引，merge 合并 part 并重建索引 ✓ 正确答案
# 14. ClickHouse 的插入去重（块校验和）机制与幂等写入 A 每次插入都会重复 B 幂等只对单副本有效 C 校验和与去重无关 D 通过块校验和登记到 ZooKeeper 识别重复插入，实现幂等写入，防止重试导致重复数据 ✓ 正确答案
# 15. ClickHouse 的轻量级删除（lightweight delete，23.3+）与 ALTER TABLE ... DELETE 在实现机制上有何差异？为什么轻量删除只标记行（内部 _row_exists 掩码列）并在查询时过滤、由后台 merge 物理清理，而普通 mutation 要重写整个 part，二者在删除量级与实时可见性上如何取舍？ A 两者机制相同 B 轻量删除立即物理删除 C mutation 不重写 part D 轻量删除标记行（_row_exists 掩码）由后台 merge 清理，适合大量小删除；mutation 重写 part 实时可见但开销大，适合大批量删除 ✓ 正确答案
# 16. Distributed 表如何把 INSERT 分发与缓冲到本地表？节点故障或重试时如何保证不重不丢？ A 无缓冲机制 B INSERT 一次性同步到所有分片 C 按 sharding_key 分发到本地表，支持异步缓冲，故障时通过重试与块去重保证不重不丢 ✓ 正确答案 D 故障导致必然丢数据
# 17. ReplicatedMergeTree 读副本时如何避免读到未同步的 part？replica 延迟与 load_balancing 配置如何影响读一致性？ A 副本延迟不影响读取 B 查询优先选择 parts 完整/健康的副本，load_balancing 控制副本选择策略，replica 延迟影响读一致性 ✓ 正确答案 C load_balancing 与读取无关 D 查询随机读任意副本
# 18. ClickHouse 的 Mutation（ALTER UPDATE/DELETE）为何是异步重写 part 而非原地更新？对写入吞吐与查询一致性有何影响？ A Mutation 原地立即更新 B Mutation 不影响写入 C part 不可变，Mutation 异步重写 part 执行，会占用后台资源、影响写入吞吐，期间查询可能新旧混合 ✓ 正确答案 D Mutation 是同步的
# 19. ClickHouse 的 JOIN 与子查询在分布式下的性能风险与优化手段？ A 分布式 JOIN 可能数据重分布产生开销，可用 GLOBAL JOIN、字典替代小表、利用本地性等手段优化 ✓ 正确答案 B 子查询不会重复执行 C 字典无法替代 JOIN D 分布式 JOIN 无性能风险
# 20. ClickHouse 的查询缓存（Query Cache）与结果复用 A 任何查询都能被缓存 B 缓存结果永不失效 C 相同 SQL 且数据未变时复用缓存结果，降低延迟，适合重复执行查询，但数据更新后需失效 ✓ 正确答案 D 缓存增加计算量
