场景一：最左前缀原则
当查询条件不符合索引的最左前缀原则时，索引将失效。例如，联合索引为 (a, b, c)，但查询条件只使用 b 或 c 字段，则该索引无法被有效利用。
解决方案
调整查询条件顺序或创建新的索引，确保查询条件能够匹配索引的最左前缀。例如，针对上述情况，可以为 b 字段或 (b, c) 字段创建单独的索引。
场景二：联合索引顺序不当
联合索引的列顺序至关重要。如果顺序安排不合理，可能导致索引选择性差或无法覆盖查询。
解决方案
遵循高选择性列优先、等值查询列优先、范围查询列靠后的原则来设计联合索引顺序。使用 EXPLAIN 分析查询执行计划，验证索引使用情况。
场景三：使用函数或表达式
在索引列上使用函数、数学运算或类型转换，会导致 MySQL 无法使用该列索引。
解决方案
尽量避免在索引列上使用函数或运算。如果必须使用，考虑创建函数索引（MySQL 8.0+ 支持）或调整查询逻辑，将运算转移到常量端。
场景四：范围查询后的索引失效
在联合索引中，如果某一列使用了范围查询（如 >, <, BETWEEN），则其后面的索引列将无法被用于索引查找。
解决方案
将等值查询的列放在联合索引的前面，范围查询的列放在后面。如果查询中同时有多个范围条件，可能需要创建多个索引或考虑其他优化策略。
场景五：LIKE 查询以通配符开头
当 LIKE 查询的模式以通配符（如 %）开头时（例如 `LIKE '%abc'`），索引将失效。
解决方案
尽量避免前缀模糊查询。如果业务必须，可以考虑使用全文索引（FULLTEXT INDEX）或搜索引擎（如 Elasticsearch）来优化此类查询。
场景六：OR 条件使用不当
当 WHERE 子句中包含 OR 条件，并且 OR 的各个条件字段并非都有索引时，可能导致全表扫描。
解决方案
确保 OR 连接的每个条件字段都有合适的索引。有时，将 OR 查询改写为 UNION 查询可以更好地利用索引。
场景七：索引列数据分布不均匀
当索引列的数据区分度很低（例如，性别字段只有两种值），或者存在大量 NULL 值时，优化器可能认为全表扫描比使用索引更高效。
解决方案
对于低区分度的列，通常不建议单独建立索引。可以考虑将其作为联合索引的一部分。对于 NULL 值，可以根据业务情况设置默认值或使用复合条件。
场景八：优化器选择错误
有时，统计信息不准确或成本估算错误，可能导致优化器放弃使用更优的索引。
解决方案
定期使用 ANALYZE TABLE 更新表的统计信息。对于复杂查询，可以使用 FORCE INDEX 提示强制使用特定索引，但需谨慎使用并充分测试。