在 SAP HANA 中创建与管理索引：从列存访问路径到 INVERTED 系列索引的实战指南

在很多传统数据库里，索引几乎等同于性能：没有索引就全表扫，有索引就走树结构，差距肉眼可见。到了 SAP HANA，情况变得更有意思——它默认采用列式存储，数据常驻内存，压缩与向量化执行让全表扫描也可能非常快。可一旦业务进入高并发的 OLTP 模式，或者存在大量“点查、精确匹配、超高选择性过滤”的语句，索引结构依旧能把执行时间从“秒级的扫描”拉回“毫秒级的命中”，甚至决定系统峰值时段能否扛住压力。

这篇文章围绕Creating Indexes这一主题，把 HANA 的访问路径、列存索引类型、创建与运维要点串起来，并结合本地部署的 SAP HANA 与 HANA Cloud 的共同点与差异点，给出可以直接落地的设计与排障思路。

为什么在列存为主的 SAP HANA 里，索引仍然重要

很多同学听过一句话：SAP HANA 里不需要二级索引。这句话在“典型分析型扫描 + 合理建模”的前提下往往成立，但它不是铁律。原因在于同一张表会被不同的访问模式触发：

• 报表类查询喜欢扫大量行，聚合、分组、过滤后返回少量结果，列存的向量化执行非常擅长这类负载。
• 业务事务类查询喜欢按键值精确命中，典型语句像“按订单号查一条、按业务对象 ID 查一条、按唯一组合键判断是否存在”，这种负载更需要“快速定位到极少量行”的访问路径。

当一次查询只需要返回 0 或 1 行时，最坏情况下的全表扫描需要触达表中的 n 条记录；而合适的索引能够把定位复杂度下降到与不同取值数量 k 相关的对数级，比如 log k。对于大表来说，这个量级差异非常夸张：从几秒缩短到几毫秒