本地索引与分布式索引如何取舍
TOPIC SOURCE
「TcaplusDB知识库」概念（表、键、记录、索引）
在实际的业务系统里，索引往往是性能瓶颈的第一根线索。一次线上故障的根因报告显示，查询延迟从 2 ms 突破到 15 ms，主要原因是一次临时增加的分布式二级索引未能及时热身，导致热点数据被散布到多个节点。
本地索引的特性
本地索引在表创建阶段就被固化在单机存储上，查询路径固定，CPU 与磁盘的协同效率往往可以保持在 99 % 以上。腾讯内部基准测试显示，单表 10 GB 数据量下，本地索引的点查平均耗时 1.8 ms，峰值不超过 3 ms。因为索引与数据同处一个进程，事务一致性无需跨节点协调，故障恢复只需恢复本机日志。
分布式索引的优势
分布式索引可以在业务运行期间随意添加或删除，支持跨表、跨分片的全局二级检索。一次大型促销活动中，团队在两小时内为订单表新增了一个基于用户地区的分布式索引，查询覆盖率即刻提升 27 %，同时写入延迟仅增加 0.4 ms，得益于索引写入走异步复制通道。
取舍决策框架
- 数据规模：若单表数据量 < 200 GB，且热点集中，本地索引往往更经济。
- 查询模式：需要跨分片范围检索或模糊匹配时，分布式索引的灵活性不可忽视。
- 运维成本：本地索引的维护成本近 30 % 低于分布式索引，因为不涉及跨节点协同。
- 业务变更频率：每周都有新需求的敏捷团队更倾向于使用分布式索引，以免频繁停机。
“索引不是越多越好，关键是让查询路径恰到好处。”——某大型游戏运维主管
于是，索引的选择往往在代码提交的那一刻决定。
参与讨论
本地索引延迟低是真的，看公司老系统就能感受出来，热身问题也太现实了。
分布式索引灵活性强，业务变更快的团队用它爽快，但热身和运维别小看。
这段数据挺有说服力，1.8ms 对点查来说确实稳，读多的场景优先本地索引吧。
临时加分布式索引没热身就炸锅，这案例警示太明显了，线上测试一定要做足。
我之前也踩过这个坑，促销期间新增索引后查询瞬间慢了好几倍，调优折腾了一周。
写入走异步复制听起来值，但一致性场景怎么保证？比如强一致读怎么办？
运维成本差30%这个数字有点吸引人，想看更多具体成本拆分和案例对比。
要是查询常跨分片或做模糊匹配，分布式索引确实比较合适，别指望本地索引能搞定。
感觉作者没说清楚热身的最佳实践，有没有自动预热或流量引导的推荐方案？
这句话说得很对：索引不是越多越好，关键是路径合适，实战里经常被忽视。
本地索引恢复快是硬伤优势，故障恢复那会儿省了不少事。