解读

面试官问的是“列式引擎”在 OLAP 场景下的真实加速比，而不是“列存比行存好”这种口号。国内云厂商（含 Google Cloud 在国内的机房）做 POC 时，客户往往要求给出可量化的倍数，例如 TPC-H 1 TB 数据集下 Q1、Q5、Q9 的耗时对比。因此，回答必须给出区间值+前提条件，并说明为什么 Cloud SQL 目前仍以行存为主、列式能力靠外挂或导出到 BigQuery 实现。

知识点

1. 列式存储核心原理：只解压、只读取查询需要的列，CPU 缓存命中率高；同一列数据相似度高，压缩比可达 3×–10×，减少 I/O。
2. 向量化执行：一次处理 1000–10000 行同列数据，CPU SIMD 利用率提升 4×–8×。
3. 延迟物化：过滤完再拼行，减少中间结果 10× 以上。
4. Cloud SQL 现状：InnoDB/PostgreSQL 原生仍是行存；列式加速靠 Cloud SQL Enterprise Plus 的“列式索引”预览功能，或导出到 BigQuery 做纯列存。
5. 国内 POC 基准：1 TB TPC-H，22 条查询，列式引擎平均加速 5×–15×，峰值 Q1 扫描 6 亿行可加速 25×；但点查或小表加速比接近 1×，甚至略慢。

答案

在 1 TB TPC-H 标准数据集、22 条典型 OLAP 查询、Cloud SQL Enterprise Plus 列式索引预览版环境下，列式引擎对 OLAP 查询的平均加速比为 5×–15×；其中大表全表扫描加重聚合的查询（如 Q1、Q5、Q9）最高可达 20×–25×；对于仅返回几十行的小表点查，加速比接近 1×，列式优势不明显。该倍数的前提包括：

1. 查询列数不超过总列数的 30%，
2. 数据已按列存格式预热，
3. 并发度控制在 20 线程以内，
4. 网络带宽 10 Gbps 以上，避免 I/O 回包成为瓶颈。
   若数据仍留在原生 InnoDB 行存，仅通过并行查询加速，OLAP 加速比通常只有 1.5×–2.5×，无法达到列式引擎的量级。

拓展思考

国内金融客户常把 Cloud SQL 当作 OLTP 主库，又希望“一套库”同时跑日报、月报。此时可给出混合架构：

1. 实时库：Cloud SQL 行存，保证事务。
2. 列式副本：通过 Cloud SQL 的“列式索引”或逻辑复制到 BigQuery，月报走列式，加速 10× 以上，且不干扰主库。
3. 成本权衡：列式索引每 GB 额外存储费用约 0.17 元/月，若数据量超 5 TB，导出到 BigQuery 更划算；同时需提醒客户列式索引目前仅支持 PostgreSQL 15 及以上版本，MySQL 需等待后续 Roadmap。