索引不适合哪些场景呢？
索引在数据库优化中是一把双刃剑。虽然它能极大提升查询速度，但在某些场景下反而会降低性能、增加资源消耗或失去意义。以下是不适合或需要谨慎使用索引的主要场景：
一、高频写入/更新的表
写入性能瓶颈：
每次INSERT、UPDATE、DELETE操作都需要更新所有相关的索引。
索引越多，写操作的负担越重，速度越慢。
场景举例： 高并发的日志记录表、实时交易流水表、频繁更新的状态表。
索引碎片化：
频繁更新会导致索引页分裂和碎片化，降低索引效率，需要定期维护（如重建索引），这本身也是开销。
二、数据量非常小的表
全表扫描更快： 如果一张表只有几十条或几百条记录，数据库优化器可能会认为直接读取整个表（全表扫描）比先查索引再根据索引指针去取数据（回表）更快、开销更小。
维护成本不划算： 为小表创建索引带来的维护开销（存储空间、写操作延迟）可能超过它带来的潜在查询收益。
三、数据分布极不均匀或区分度极低的列
区分度低（基数低）：
如果某个列的值几乎都一样（例如一个
性别列，99%是男），或者只有少数几个值（例如一个状态列只有有效/无效），索引的效果微乎其微。优化器很可能忽略这个索引，因为即使用了索引，也需要回表访问表中绝大部分数据页，不如直接全表扫描。
查询很少使用特定值：
即使有索引，但查询条件很少命中索引列，或者总是查询那些占比极高的值，索引效果也不好。
四、频繁进行大批量数据加载
初始加载或批量导入（如ETL）：
在导入大量数据（例如百万、千万级）之前，先删除索引，导入完成后再重建索引，通常比带着索引导入要快得多。
因为带着索引导入，每插入一条数据都需要更新索引，产生巨大的I/O开销和日志量。
五、查询需要返回表中很大比例的行
全表扫描更优： 当你的查询条件（即使使用了索引列）最终会筛选出表中超过大约15%-30%的数据行时，优化器通常会选择放弃索引，进行全表扫描。
原因： 使用索引需要先查索引树，然后根据索引指针（RowID/聚簇索引键）去表中逐行获取数据（回表）。这个“回表”操作是随机I/O（可能涉及多次磁盘寻道）。而全表扫描是顺序I/O，当需要读取的数据量很大时，顺序I/O的效率远高于大量的随机I/O。
六、查询仅使用索引中排在后面的列（针对复合索引）
复合索引的最左前缀原则：
复合索引
(A, B, C)对WHERE A=...、WHERE A=... AND B=...、WHERE A=... AND B=... AND C=...有效。但对
WHERE B=...、WHERE C=...、WHERE B=... AND C=...无效或效率极低（除非是覆盖索引）。优化器通常不会选择使用这个复合索引。场景： 如果查询条件无法利用复合索引的最左前缀，为该查询单独创建一个单列索引或调整复合索引顺序可能更好，但需权衡索引总数。
七、数据类型不匹配或使用函数/表达式
隐式类型转换： 如果查询条件中的值与索引列的数据类型不匹配，导致数据库需要做隐式转换（例如索引是
VARCHAR，查询用WHERE id = 123，数字123被转成字符串），索引通常会失效。在索引列上使用函数或运算：
WHERE UPPER(name) = 'JOHN'(对name列索引无效)WHERE price * 1.1 > 100(对price列索引无效)需要在表达式上创建函数索引才能生效（如果数据库支持）。
八、存储空间极其紧张
索引占用额外空间： 每个索引都需要占用独立的存储空间（通常接近甚至超过原表数据大小）。在存储成本极其敏感或空间严重不足的环境（如嵌入式设备、特定IoT场景），需要严格控制索引数量。
九、LOB类型数据（如TEXT, BLOB）
直接索引不现实： 非常大的文本或二进制字段本身就不适合直接创建常规索引（B-Tree）。索引项大小有限制。
解决方案： 通常使用前缀索引（MySQL）、全文索引（Full-Text Search）、或专门的搜索引擎（如Elasticsearch）来处理大文本搜索。
十、需要精确的COUNT(*)
场景：
SELECT COUNT(*) FROM large_table;问题： 如果表非常大，某些数据库（如MySQL InnoDB）的全表扫描可能比使用二级索引更快（因为二级索引可能不包含所有行信息，且需要扫描整个索引树）。有些数据库有专门优化的计数机制（如元数据估算、维护计数器），但精确COUNT(*)在大表上始终是昂贵的，索引通常帮不上大忙。
总结与建议
权衡利弊： 创建索引前务必考虑“查询性能提升收益”与“写性能下降和维护成本”之间的权衡。
分析查询模式： 只为最频繁、最关键且能显著受益的查询创建合适的索引。使用数据库提供的查询执行计划工具（如
EXPLAIN）进行分析。关注区分度： 优先为区分度高（基数大）的列创建索引。
复合索引设计： 精心设计复合索引，考虑列顺序和最左前缀原则。
监控与维护： 定期监控索引使用情况（哪些索引从未被使用？），删除无效或低效索引。对碎片化的索引进行重建或重组。
考虑替代方案： 对于不适合索引的场景，考虑其他优化手段：分区表、物化视图/汇总表、查询重写、使用更适合的存储引擎或专用数据库（如OLAP列存、Elasticsearch等）。
简单来说，当写操作成本、维护开销或索引自身的局限性超过了它带来的读性能提升时，索引就不再适合。明智地选择何时何地使用索引，是数据库性能调优的关键。