什么情况下会放弃索引，直接进行全表扫描查询？
-
索引选择性低
- 索引选择性：选择性是指索引列中不同值的数量与总行数的比率。选择性高的索引（即索引列中的值分布较广）通常更有效。
- 全表扫描更高效：如果索引列的选择性很低（即大多数行具有相同或相似的值），全表扫描可能比使用该索引更高效。
-
查询条件不适用索引
- 查询条件复杂：某些查询条件可能使得索引无法有效使用。
- 示例：使用LIKE子句进行模糊查询时，特别是在模式以通配符开头的情况下（如LIKE '%example'），索引可能无法使用。
- 示例：使用NOT、<>、!=等操作符的查询条件可能无法使用索引。
- 示例：使用函数或表达式对列进行操作的查询条件可能无法使用索引。
- SELECT * FROM Users WHERE UPPER(Name) = 'JOHN'; -- UPPER函数可能导致索引无法使用
-
查询涉及大量数据
- 数据量大：如果查询涉及的数据量非常大，全表扫描可能比使用索引更快，尤其是在索引列的选择性很低的情况下。
- I/O开销：索引的使用可能会增加I/O开销，特别是在索引文件和数据文件都很大的情况下。
-
索引维护开销
- 索引维护：在某些情况下，索引的维护开销（如插入、更新和删除操作时更新索引）可能大于使用索引的性能收益。
- 临时表：在某些情况下，数据库可能会选择使用临时表来存储中间结果，而不是使用索引。
-
查询涉及多个表
- 多表连接：在复杂的多表连接查询中，数据库优化器可能会选择全表扫描而不是使用索引。
- JOIN操作：某些JOIN操作可能使得索引无法有效使用，直接进行全表扫描可能更高效。
-
统计信息不准确
- 统计信息：数据库优化器依赖于统计信息来决定最佳的执行计划。
- 不准确的统计信息：如果统计信息不准确，优化器可能会选择错误的执行计划，比如选择全表扫描。
-
索引损坏或未更新
- 索引损坏：如果索引损坏或未更新，优化器可能无法正确使用索引。
- 未更新的统计信息：过时的统计信息可能导致优化器选择不合适的执行计划。
-
查询涉及排序和分组
- 排序和分组：某些排序和分组操作可能使得索引无法有效使用。
- 临时排序：数据库可能会选择使用临时表或临时文件来进行排序和分组操作，而不是使用索引。
-
查询涉及范围查询和顺序访问
- 范围查询：如果查询涉及范围查询（如BETWEEN、<、>等），并且数据访问是顺序的，全表扫描可能比使用索引更快。
- 顺序访问：顺序访问数据通常比随机访问更快，因为数据可能已经缓存或在磁盘上是连续存储的。
-
查询涉及大量临时数据
- 临时数据：如果查询涉及大量临时数据（如使用子查询生成临时结果集），全表扫描可能比使用索引更高效。
- 临时表：数据库可能会选择使用临时表来存储中间结果，而不是使用索引。
-
查询条件使用了索引列的非前缀部分
- 非前缀部分：如果查询条件使用了索引列的非前缀部分，索引可能无法使用。
- 前缀索引：某些数据库支持前缀索引，如果查询条件使用了非前缀部分，优化器可能选择全表扫描。
-
查询条件涉及多个索引列
- 多个索引列：如果查询条件涉及多个索引列，但这些列没有被组合在一起索引（即没有创建覆盖索引），优化器可能选择全表扫描。
- 覆盖索引：确保查询涉及的所有列都在同一个索引中，以避免全表扫描。
