对索引列使用函数或表达式会导致索引失效，如YEAR(create_time)或id+1；应改写为直接范围查询。2. 类型不匹配如字符串与数字比较，会触发隐式类型转换，使索引失效；需确保数据类型一致。3. 使用OR连接条件且部分字段无索引时，可能导致全表扫描；建议用UNION替代。4. 模糊查询以%开头如LIKE '%abc'无法利用索引；应避免前导通配符。5. 联合索引未遵循最左前缀原则，如跳过首列则索引失效；应按定义顺序使用。6. 索引列参与计算或比较时被隐式转换，如salary*1.1>10000；应将计算移至常量侧。7. 数据量小或查询结果占比高时，优化器可能选择全表扫描；属正常现象。8. 使用NOT、!=、NOT IN等否定操作通常无法有效利用索引；可考虑改写为IN或EXISTS。理解索引机制并结合EXPLAIN分析执行计划，可有效避免索引失效问题。
在MySQL中，即使表上建了索引，某些SQL语句也可能导致索引失效，从而进行全表扫描。这会影响查询性能。以下是一些常见的不走索引的情况及其原因和解决建议。
1. 使用函数或表达式操作索引列
如果在WHERE条件中对索引列使用函数或表达式，MySQL无法直接使用索引查找。
示例：- SELECT * FROM user WHERE YEAR(create_time) = 2023; —— 对日期字段使用YEAR()函数，索引失效。
- SELECT * FROM user WHERE id + 1 = 10; —— 对索引列做数学运算。
建议：重写查询避免对索引列进行计算。例如改写为：
SELECT * FROM user WHERE create_time >= '2023-01-01' AND create_time
2. 隐式类型转换
当索引列是数值类型，但查询时传入字符串，MySQL会进行隐式类型转换，导致索引失效。
示例：- SELECT * FROM user WHERE id = '123'; —— id是INT类型，用字符串比较。
说明：虽然某些情况下优化器能处理，但复杂场景下可能导致索引失效。应确保数据类型一致。
3. 使用LIKE以通配符开头
前导通配符（%在前面）会使索引无法使用。
示例：- SELECT * FROM user WHERE name LIKE '%张三';
建议：尽量避免前模糊匹配。可考虑使用全文索引或反向索引等替代方案。
4. OR条件导致索引失效
当OR连接的条件中，部分列无索引或涉及多个不同列，可能导致索引无法使用。
示例：- SELECT * FROM user WHERE name = '张三' OR age = 25; —— name有索引，age无索引。
建议：使用UNION ALL拆分查询，确保每部分都能走索引。
KGOGOMall 是一套采用 Php + MySql 开发的基于 WEB 应用的 B/S 架构的B2C网上商店系统。具有完善的商品管理、订单管理、销售统计、新闻管理、结算系统、税率系统、模板系统、搜索引擎优化，数据备份恢复，会员积分折扣功能，不同的会员有不同的折扣，支持多语言，模板和代码分离等，轻松创建属于自己的个性化用户界面。主要面向企业和大中型网商提供最佳保障，最大化满足客户目前及今后的独立
5. 最左前缀原则未遵守（复合索引）
复合索引(a,b,c)，只有满足最左前缀的查询才能使用索引。
示例：- SELECT * FROM user WHERE b = 2 AND c = 3; —— 跳过a，索引不生效。
说明：必须从索引最左列开始使用。有效查询如：
WHERE a = 1 AND b = 2; 或 WHERE a = 1;
6. 索引列参与计算或拼接
示例：- SELECT * FROM user WHERE salary * 1.1 > 10000;
这种表达式会让优化器放弃使用索引。
改写建议：
SELECT * FROM user WHERE salary > 10000 / 1.1;
7. 数据量小或选择性差
MySQL优化器可能判断全表扫描比走索引更快，特别是当：
- 表数据很少（如几百行）。
- 查询结果占全表比例高（如 >20%）。
这时即使有索引，执行计划也可能不使用。
8. 使用NOT、!=、NOT IN等否定操作
示例：- SELECT * FROM user WHERE status != 1;
- SELECT * FROM user WHERE id NOT IN (1,2,3);
这类条件通常无法有效利用索引，容易触发全表扫描。
基本上就这些常见情况。理解索引机制，结合EXPLAIN分析执行计划，能有效避免索引失效问题。关键是在写SQL时保持索引列“干净”，不被函数、计算或类型转换干扰。
