数据库查询优化：解析不使用索引的场景及对策

数据库索引的目的是为了加快查询速度，但在某些情况下，查询可能不会使用索引，即所谓的“不走索引”。以下是一些可能导致数据库查询不使用索引的情况：

全表扫描：当查询条件中的字段没有建立索引，或者查询的条件是对整个表进行范围查询（如使用 BETWEEN），数据库可能会选择全表扫描而不是使用索引。
低选择性索引：如果索引列的值非常密集，即大部分行的索引值相同或相似，这种索引称为低选择性索引。数据库查询优化器可能会判断使用索引不会比全表扫描更快，因此不会使用索引。
隐式类型转换：当查询条件中的字段类型与比较值的类型不一致，数据库会自动进行类型转换，这可能导致索引失效。
使用函数或表达式：如果查询条件中对索引列使用了函数或表达式，这会阻止数据库利用索引来加速查询。。
索引列参与计算：如果在查询条件中对索引列进行了计算，如 WHERE a + b = 10，这将导致无法使用索引。
索引列被包含在函数内部：如果查询条件中的索引列被包含在函数内部，如 WHERE UPPER(column_name) = 'VALUE'，这同样会导致索引失效。
使用 OR 连接多个条件：当使用 OR 连接多个条件时，如果这些条件中的任何一个不能使用索引，那么整个查询可能不会使用索引。
数据库中索引字段存在Null 可能不会触发索引使用或者降低索引的使用效率。
对索引列使用 IS NULL 或 IS NOT NULL 可能不会触发索引使用或者降低索引的使用效率。
复合索引未正确使用：如果查询条件没有匹配复合索引的最左前缀原则（即查询条件必须从复合索引的第一个字段开始），索引可能不会被使用。
```
 1 假设我们有一个名为employees的表，它有一个复合索引idx_name_dept，这个索引包含了name和department两个字段。
 2 
 3 正确使用复合索引的查询
 4 
 5 SELECT * FROM employees WHERE name = 'John' AND department = 'IT';
 6 在这个查询中，我们同时指定了name和department两个条件，并且这两个条件都出现在了复合索引idx_name_dept中，因此数据库可以利用这个索引来快速检索符合条件的记录。
 7 
 8 错误使用复合索引的查询
 9 
10 SELECT * FROM employees WHERE department = 'IT' AND name = 'John';
11 在这个查询中，虽然department和name都出现在了复合索引idx_name_dept中，但是我们先指定了department，后指定了name，这与复合索引的定义顺序不一致。在这种情况下，数据库不能直接使用索引来执行查询，因为它不能按照索引的顺序访问数据。
12 
13 优化策略
14 
15 在编写查询时，始终确保查询条件按照复合索引的定义顺序排列。
```
索引跳跃式扫描（Index Skip Scan）是一种特殊类型的索引扫描，适用于所有类型的复合B树索引（包括唯一性索引和非唯一性索引）。在这种扫描过程中，数据库会在索引中跳过某些列，直接从其他列开始扫描。

具体来说，如果查询条件中没有对目标索引的前导列指定查询条件，但同时又对该索引的非前导列指定了查询条件，那么数据库仍然可以使用该索引。这就像是扫描该索引时跳过了它的前导列，直接从该索引的非前导列开始扫描一样。

例如，假设我们有一个复合索引idx_name_dept，它包含了name和department两个字段。现在我们要执行一个查询，条件是department = 'IT'和name = 'John'，但是查询条件首先指定了department，然后才是name。在这种情况下，数据库不能直接使用索引来执行查询，因为它不能按照索引的顺序访问数据。然而，如果department列上的唯一值非常少，并且name列上的可选择性非常好，那么数据库可能会选择使用索引跳跃式扫描。

索引跳跃式扫描并不总是比全表扫描或普通索引扫描更快，但它通常比全表扫描更快，尤其是在处理大型表时。然而，由于其复杂性和可能的性能问题，它通常只在特定情况下使用，如处理具有大量唯一值的列或处理具有高度选择性的列。
查询优化器的错误判断：有时候，即使存在合适的索引，查询优化器可能由于统计信息不准确或其他原因，错误地判断不使用索引。
锁竞争：在高并发的情况下，如果索引列上的数据频繁被锁定，数据库可能会选择避免使用索引以降低锁竞争。
索引损坏：如果索引损坏或不完整，数据库将无法使用该索引进行查询。
查询中使用了外部连接：在某些情况下，如果查询中使用了外部连接，并且连接条件不能有效利用索引，那么索引可能不会被使用。
查询优化器的成本估算：数据库查询优化器会根据统计信息和成本模型来决定是否使用索引。如果优化器认为不使用索引的成本低于使用索引的成本，它可能会选择不使用索引。
<> 运算符

<> 运算符是 MySQL 中用于表示不等于的运算符。它与 != 运算符具有相同的功能。然而，使用 <> 运算符可能会导致索引失效。这是因为 <> 运算符在某些情况下可能会导致类型不匹配，从而导致索引失效。例如，如果索引列是整数类型，而在查询中使用 <> 运算符与字符串进行比较，索引将不会被使用。
like、not like 运算符
- 当使用 LIKE 运算符时，如果通配符 % 放在模式的开始处，比如 '%value'，数据库通常不会使用索引，因为它需要从字符串的开头开始搜索，这种搜索方式不能有效利用索引来加速查找过程。
- 如果 % 放在模式的结尾，比如 'value%'，大多数数据库管理系统（如 MySQL）可以利用索引，因为它们可以从索引的末尾开始搜索，这种方式可以高效地找到所有以特定值开始的行。
- 如果 _ 通配符被用来代替单个字符，如 'val_ue'，索引通常会被使用，因为索引可以定位到以 "val" 开头后跟任意单个字符的位置，然后进行匹配。
对于 NOT LIKE 运算符，情况类似。如果模式以 % 开头，索引不会被使用，因为这要求数据库检查每一行以确定它是否不匹配。如果模式不以 % 开头，索引通常可以被使用，因为数据库可以利用索引快速排除那些匹配模式的行。

因此，关键因素是 % 通配符的位置。如果它在模式的开始，索引通常不会被使用；如果它在模式的其他位置或不存在，索引可能会被使用。
not in 和 not exists 运算符

NOT IN 和 NOT EXISTS 运算符都用于排除查询结果中满足特定条件的记录。然而，这两个运算符在某些情况下可能会导致索引失效。
- NOT IN：如果 NOT IN 运算符的右侧是一个子查询，并且这个子查询返回的结果集非常大，那么数据库查询优化器可能会选择执行全表扫描而不是使用索引。这是因为在这种情况下，使用索引可能不如全表扫描高效。
- NOT EXISTS：NOT EXISTS 运算符通常不会导致索引失效，因为它会在子查询中使用索引。但是，如果子查询返回的结果集非常大，那么查询优化器可能会选择执行全表扫描而不是使用索引。
请注意，上述情况并不是绝对的，具体取决于查询的具体情况和数据库系统的实现。在实际使用中，建议通过查询执行计划查看索引的使用情况，并根据需要进行优化。
数据库配置：某些数据库配置可能会影响索引的使用。例如，在某些情况下，数据库配置可能会导致查询优化器更倾向于使用全表扫描而不是索引。
查询缓存：如果查询结果被缓存，那么即使查询条件发生变化，数据库也可能返回缓存的结果，而不是重新执行查询并使用索引。
统计信息不准确：数据库查询优化器依赖统计信息来决定是否使用索引。如果统计信息不准确或过时，那么优化器可能会做出错误的决策。