一条容易误解的结论

阅读 TiDB 索引实现时，有一个结论初看会让人意外：TiDB 的 index 不像 MySQL 那样承担查询加速的核心职责。理解这一点，需要先理解分布式数据库的存储模型。

关键差异：数据获取全是 KV 操作

在 TiDB 这类架构中，对于 value 的获取全是 KV 操作。也就是说，无论走不走索引，底层访问数据的方式都是对键值存储的读写。

这带来一个结果：不需要有实质的查询优化来依赖索引选择，因为数据的物理寻址方式已经由 KV 层的键设计决定了。索引在这里的作用发生了偏移。

那索引的作用是什么

既然主要不是为了加速查询，索引存在的意义就落在兼容性上：它只需要用来保证相应的 unique 等特性跟 MySQL 表现一致即可。

换句话说，TiDB 的 index 更多像是一种兼容的方式。业务系统在 MySQL 上依赖的语义——比如唯一约束会在插入重复值时失败、外键依赖的唯一索引必须存在——在迁移到分布式数据库后依然要被满足，否则应用逻辑就会出错。

这个定位很重要：它解释了为什么在分布式数据库中，索引的语义正确性比「让某条查询更快」更被优先保证。

对使用者的实际影响

理解这个定位差异，能避免几个常见的误区：

  • 不要假设加索引就一定有 MySQL 那样立竿见影的提速效果，实际效果取决于数据分布与查询模式；
  • 唯一索引等约束语义仍应保留，它们承担的是数据正确性职责，不能因为「不影响性能」而省略；
  • 查询性能的优化重点不同，在分布式环境下，数据分布的均匀性、访问路径是否命中单分片，往往比索引本身更关键；
  • 迁移评估要单独验证索引行为，确认唯一性冲突、索引统计等行为与预期一致。

延伸思考

这个例子很好地说明了「同名概念在不同架构下含义可能不同」。在单机数据库中，索引是性能优化的主要手段；在计算存储分离的分布式数据库中，它首先是一个约束语义的载体。

做技术选型或迁移时，最有价值的工作之一就是把这类同名但含义发生偏移的概念逐个梳理清楚。否则很容易带着旧架构的直觉去评判新架构的表现，得出错误结论。

小结

  • TiDB 中数据的获取都基于 KV 操作，物理寻址由键设计决定；
  • 索引的核心职责是保持 unique 等约束语义与 MySQL 一致；
  • 不要把索引等同于性能优化的全部，数据分布与访问路径同样关键；
  • 迁移前应单独验证索引相关的行为差异。
索引定位对比
KV 存储模型数据的获取全部以 KV 操作实现，物理寻址由键设计决定
索引主要职责保证 unique 等约束特性与 MySQL 行为一致
与 MySQL 差异单机库中索引承担主要查询加速职责，分布式库中定位发生偏移
迁移注意唯一性冲突、索引统计等行为需要单独回归验证
性能重点数据分布均匀性与访问路径是否命中单分片往往更为关键