面试题答案
一键面试1. 全表扫描更优场景
- 原因分析：当表数据量较小，或者索引统计信息不准确，导致查询优化器认为全表扫描成本低于使用索引时，索引会失效。例如，小表中数据量可能只有几十条，全表扫描速度很快，而使用索引还需额外的索引查找开销。
- 提升策略：更新索引统计信息，使用
ANALYZE TABLE语句，让查询优化器能更准确评估执行计划。对于小表，可以考虑不使用索引，减少索引维护开销。 - 引擎差异：InnoDB和MyISAM在这种场景下处理方式类似，都依赖查询优化器对执行计划的评估，但InnoDB的统计信息更新相对更实时，MyISAM可能需要手动更频繁更新。
2. 不符合最左前缀原则（针对联合索引）
- 原因分析：如果联合索引为
(a, b, c)，查询条件中如果没有最左边的a字段，索引将部分或完全失效。例如WHERE b = 'value'，优化器无法利用该联合索引。 - 提升策略：调整查询语句，确保查询条件包含联合索引的最左前缀。或者根据实际查询需求，重新设计联合索引顺序，使其符合常见查询模式。
- 引擎差异：InnoDB和MyISAM在联合索引使用上遵循相同的最左前缀原则，没有本质差异。
3. 索引列上使用函数
- 原因分析：在索引列上使用函数，如
WHERE UPPER(column_name) = 'VALUE'，MySQL无法直接使用索引，因为函数改变了索引列的值，需要对每一行数据进行函数运算后再匹配，导致索引失效。 - 提升策略：避免在索引列上使用函数，可将函数操作移到查询条件右边，如
WHERE column_name = UPPER('value')（前提是数据类型匹配）。或者创建基于函数的索引，但要注意函数索引维护成本较高。 - 引擎差异：InnoDB和MyISAM都不支持在普通索引列上使用函数时直接利用索引，但InnoDB支持创建基于函数的索引，MyISAM在MySQL 5.7及之前版本不支持基于函数的索引。
4. 使用OR连接条件
- 原因分析：当
OR两边的条件字段只有部分有索引，或者都有索引但不是联合索引时，索引可能失效。因为OR操作需要分别对两边条件进行扫描，若不能使用同一个索引，就可能导致全表扫描。例如WHERE a = 'value1' OR b = 'value2'，若a、b不是联合索引，就可能无法有效使用索引。 - 提升策略：如果可能，将
OR条件改写成UNION，UNION会分别对每个子查询使用索引。或者创建联合索引，使OR两边条件能使用同一个索引。 - 引擎差异：InnoDB和MyISAM在处理
OR条件导致索引失效问题上类似，但InnoDB在处理复杂查询时对索引的利用可能更灵活，因为其有更复杂的锁机制和查询优化策略。
5. LIKE以通配符开头
- 原因分析：
LIKE '%value'这种以通配符开头的查询，MySQL无法利用索引进行快速定位，因为索引是有序的，从通配符开头无法确定索引查找的起始位置，只能进行全表扫描。 - 提升策略：尽量避免以通配符开头的
LIKE查询。如果必须使用，可以考虑使用全文索引（FULLTEXT），全文索引更适合模糊匹配场景。或者在应用层进行处理，如先通过其他条件缩小范围，再进行LIKE查询。 - 引擎差异：InnoDB和MyISAM都不支持以通配符开头的
LIKE直接使用普通索引。但InnoDB对全文索引的支持更完善，MyISAM在MySQL 5.6之后全文索引功能也有所增强，但在一些高级特性上不如InnoDB。
6. 数据类型不匹配
- 原因分析：当查询条件中的数据类型与索引列的数据类型不一致时，MySQL可能无法使用索引。例如，索引列是
INT类型，而查询条件写成WHERE column_name = '123'（字符串形式），MySQL会进行隐式类型转换，这可能导致索引失效。 - 提升策略：确保查询条件的数据类型与索引列的数据类型一致。在编写查询时，注意数据类型的匹配，避免隐式类型转换。
- 引擎差异：InnoDB和MyISAM在数据类型不匹配导致索引失效方面表现一致，都依赖于查询优化器对数据类型转换的处理，都建议避免这种情况以保证索引正常使用。