在什么情况下，不推荐为数据库建立索引？

虽然索引能显著提升查询速度，但它并非“万能药”。索引是有代价的。在以下情况下，不推荐或需要谨慎为数据库字段建立索引：

1.数据量极小（小表）

• 场景：表中的数据行数很少（例如少于几百行或几千行，具体取决于数据库优化器）。
• 原因：
  • 全表扫描（Full Table Scan）的成本非常低，数据库优化器可能直接选择全表扫描，因为读取整个数据页比“先查索引树再回表”更快。
  • 建立索引不仅浪费存储空间，还会增加写入开销，却几乎不带来查询性能的提升。

2.区分度极低（低基数列）

• 场景：字段中重复值非常多，唯一值（基数）很少。
• 例子：
  • 性别（只有“男”、“女”、“未知”）
  • 状态字段（如“启用”、“禁用”，且分布不均）
  • 布尔值（0/1）
• 原因：
  • 索引的筛选效率取决于区分度（Selectivity）。如果查询条件WHERE gender = '男'能匹配表中 50% 的数据，数据库优化器通常会放弃索引，直接全表扫描，因为回表（Random I/O）的开销比顺序扫描（Sequential I/O）更大。
  • 例外：如果该字段配合其他高区分度字段组成联合索引，且查询条件包含该联合索引的前缀，则可能有效。

3.频繁更新、插入或删除的列

• 场景：表是高频写入表（如日志表、订单流水表），且索引字段经常发生变动。
• 原因：
  • 写操作代价：每次INSERT、UPDATE或DELETE操作，数据库不仅要修改数据页，还要维护所有相关索引树（B+ Tree）。
  • 锁竞争：索引维护可能导致更多的页分裂（Page Split）和锁竞争，降低并发写入性能。
  • 权衡：如果写入性能是瓶颈，应尽量减少索引数量，甚至只保留主键索引。

4.字段本身包含大量重复数据或 NULL 值

• 场景：
  • 字段允许NULL且大部分值为NULL。
  • 字段值分布极度倾斜（如 99% 的数据都是同一个值）。
• 原因：
  • 大多数数据库（如 MySQL InnoDB）对NULL值的索引处理效率较低，或者优化器认为查询NULL不需要索引。
  • 对于极度倾斜的数据，索引无法有效过滤数据，优化器会直接选择全表扫描。

5.查询语句无法利用索引的情况

• 场景：即使建立了索引，但查询写法导致索引失效。
• 例子：
  • 对索引列进行函数运算：WHERE YEAR(create_time) = 2023（索引失效，需改为范围查询）。
  • 隐式类型转换：字段是字符串，查询时没加引号WHERE phone = 13800000000（导致全表扫描）。
  • 模糊查询以通配符开头：LIKE '%abc'（无法利用 B+ 树有序性）。
  • OR 条件：WHERE col1 = 'a' OR col2 = 'b'（如果col1和col2没有联合索引，可能导致全表扫描）。
• 建议：如果查询逻辑无法优化以利用索引，建立索引就是浪费。

6.存储空间受限或成本敏感

• 场景：
  • 表非常大（TB 级别），且磁盘空间紧张。
  • 云数据库按存储量计费，且索引占用了大量空间。
• 原因：
  • 索引本身需要占用磁盘空间（通常索引大小可达数据大小的 20%-50%）。
  • 如果索引带来的查询性能提升不明显，或者可以通过其他手段（如缓存、读写分离）解决，则应删除冗余索引以节省空间。

7.覆盖索引已满足需求，无需额外索引

• 场景：查询的字段已经包含在某个现有的联合索引中（覆盖索引）。
• 原因：
  • 如果SELECT col1, col2 FROM table WHERE col3 = 'x'已经有一个(col3, col1, col2)的联合索引，那么再单独为col1或col2建立索引就是多余的。

8.主键或唯一约束已隐含索引

• 场景：字段已经是主键（Primary Key）或唯一约束（Unique Key）。
• 原因：
  • 数据库会自动为这些字段创建索引。手动再建一个普通索引是重复劳动。

💡 总结与最佳实践

建立索引的黄金法则：

1. 查询频率高：该字段经常出现在WHERE、JOIN、ORDER BY、GROUP BY子句中。
2. 区分度高：字段值分布均匀，能有效过滤数据。
3. 读多写少：表的写入频率远低于读取频率。
4. 避免过度索引：索引不是越多越好。每个索引都会拖慢写入速度并占用空间。

建议操作：

• 定期使用EXPLAIN分析慢查询，确认索引是否真正生效。
• 监控数据库的写入性能，如果发现写入变慢，检查是否有不必要的索引。
• 对于低区分度字段，考虑使用位图索引（Bitmap Index，Oracle 支持，MySQL 不支持）或联合索引来优化。

一句话总结：
不要为了“可能有用”而建立索引，要基于实际的查询模式和数据分布，权衡“读取加速”与“写入损耗”及“存储成本”后，再决定是否建立索引。