当数据库查询变慢时，数据库索引往往是第一优化手段，但索引并非万能：错误的索引反而拖慢写入。本文直接给出判断路径：先看查询模式，再选索引类型，最后评估代价。下面从原理到类型展开。
索引原理：为什么能加速查询
索引的本质是数据结构，它让数据库无需全表扫描即可定位数据。以最常见的B+树为例，数据按顺序存储，查询时从根节点到叶子节点，复杂度从O(n)降到O(log n)。但索引也有代价：每次插入、更新、删除都要维护索引结构，因此索引并非越多越好。
常见索引类型及适用场景
B+树索引
B+树是关系型数据库的默认索引，如MySQL的InnoDB。它支持范围查询和排序，适合大多数OLTP场景。判断是否使用：如果查询涉及WHERE、ORDER BY、GROUP BY，B+树通常是首选。
哈希索引
哈希索引基于哈希表，精确匹配（=或IN）极快，但不支持范围查询。内存数据库如Redis常用，MySQL的Memory引擎也支持。若查询全是等值匹配，哈希索引可考虑。
全文索引
全文索引用于文本搜索，如LIKE '%关键词%'在全文索引下可优化。MySQL的FULLTEXT、Elasticsearch的倒排索引都属于此类。适合内容管理系统、搜索引擎。
空间索引
空间索引处理地理数据，如GIS查询。MySQL的SPATIAL索引基于R树，适合“附近的人”等场景。
如何选择索引类型：决策路径
- 明确查询模式：列出高频查询的WHERE条件、排序字段。
- 匹配索引类型：范围查询选B+树，等值查询可考虑哈希，文本搜索选全文。
- 评估维护成本：写入频繁的表，索引过多会降低性能。
- 测试验证：使用
EXPLAIN分析执行计划，观察是否命中索引。
常见误区与失败条件
误区1：索引越多越好。实际上，每个索引都占用磁盘空间，并增加写操作开销。
误区2：在低选择性列上建索引，如性别字段，区分度低，索引效果差。
误区3：忽略联合索引的最左前缀原则，导致索引失效。
失败条件：查询条件使用了函数或隐式类型转换，会使索引失效。
索引与其他技术的配合
索引并非孤立存在。在日志和可观测性系统中，索引同样关键。例如，OWASP日志安全速查表强调日志记录对安全事件的重要性，而日志数据的高效查询同样依赖索引。OpenTelemetry的日志规范也提到，日志数据需要与追踪、指标关联，索引设计需考虑关联查询。Python的logging模块支持分层日志，便于采集，但日志分析时索引设计仍需谨慎。
索引设计是权衡的艺术，没有银弹。先分析查询，再选类型，最后验证。
结论
数据库索引能大幅提升查询性能，但需根据场景选择类型并控制数量。B+树是默认选择，哈希适合等值查询，全文索引用于文本。设计时遵循“查询驱动”原则，避免常见误区。
参考资料
延伸阅读