【SQL】索引失效的11种情况

本文探讨了SQL索引在11种情况下可能失效的问题,包括全值匹配、最佳左前缀法则、主键插入顺序、计算和函数、类型转换、范围条件、不等于操作、IS NULL与IS NOT NULL、LIKE通配符、OR条件和字符集不一致等。通过理解这些情况,可以优化数据库性能,避免不必要的数据操作开销。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

数据库调优的大致方向:

  • 索引失效,没有充分利用到索引——建立索引
  • 关联查询太多join——sql优化
  • 服务器调优及各个参数设置——my.cnf
  • 数据过多——分库分表

sql查询优化技术有很多,大体分为物理查询优化逻辑查询优化:

  • 物理查询优化:通过索引和表连接方式等技术进行优化
  • 逻辑查询优化:通过SQL等价变换提升查询效率,就是换一种sql写法

数据准备:

CREATE DATABASE atguigudb2;
USE atguigudb2;

#############    class 表    #################
CREATE TABLE `class` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`className` VARCHAR(30) DEFAULT NULL,
`address` VARCHAR(40) DEFAULT NULL,
`monitor` INT NULL ,
PRIMARY KEY (`id`)
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

#############    student 表    #################
CREATE TABLE `student` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`stuno` INT NOT NULL ,
`name` VARCHAR(20) DEFAULT NULL,
`age` INT(3) DEFAULT NULL,
`classId` INT(11) DEFAULT NULL,
PRIMARY KEY (`id`)
#CONSTRAINT `fk_class_id` FOREIGN KEY (`classId`) REFERENCES `t_class` (`id`)
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

#################################

SET GLOBAL log_bin_trust_function_creators=1; # 不加global只是当前窗口有效。

#随机产生字符串
DELIMITER //
CREATE FUNCTION rand_string(n INT) RETURNS VARCHAR(255)
BEGIN
DECLARE chars_str VARCHAR(100) DEFAULT
'abcdefghijklmnopqrstuvwxyzABCDEFJHIJKLMNOPQRSTUVWXYZ';
DECLARE return_str VARCHAR(255) DEFAULT '';
DECLARE i INT DEFAULT 0;
WHILE i < n DO
SET return_str =CONCAT(return_str,SUBSTRING(
<think>好的,我现在要解决用户关于如何预防SQL索引失效以及常见原因分析的问题。首先,我需要回忆一下SQL索引的基本原理。索引的作用类似于书籍的目录,帮助数据库快速定位数据。如果索引失效,查询就会变慢,特别是在大数据量的情况下,影响更明显。 接下来,常见原因方面,用户可能遇到的情况包括:在WHERE子句中对索引列使用函数或运算,比如`WHERE YEAR(create_time) = 2023`,这会导致索引失效,因为数据库无法直接使用索引的值。还有类型转换的问题,比如字符串字段用数字查询,或者隐式类型转换,这会让数据库无法有效使用索引。此外,使用LIKE以通配符开头,比如`LIKE '%abc'`,也会让索引失效,因为B树索引的结构是从左到右匹配的。 联合索引的最左前缀原则也是常见的问题点。如果查询条件不包含联合索引的最左列,索引就无法被使用。例如,联合索引是`(a, b, c)`,但查询只用了b和c,这时索引可能不会被用到。还有OR操作符,如果OR两侧的列不是都有索引,可能导致全表扫描。 然后是预防的最佳实践。需要确保WHERE条件中的列避免使用函数或运算,保持列“干净”。类型匹配也很重要,确保查询条件的类型与列定义一致。对于LIKE查询,尽量避免前置通配符,或者考虑使用全文索引。设计联合索引时,按照最左前缀原则安排列的顺序,并且根据查询频率调整。使用EXPLAIN分析执行计划,查看索引使用情况,这是实际优化中常用的方法。另外,定期维护索引,比如重建或优化碎片化的索引,保持统计信息准确,帮助优化器做出正确决策。 还要考虑其他因素,比如索引选择性。选择性低的索引(如性别字段)可能不会被使用,这时候可能需要结合其他列建立复合索引。避免过多的索引,因为增删改操作需要维护索引,影响性能。覆盖索引可以减少回表,提高效率,但需要权衡空间和查询需求。 用户可能还关心具体案例,比如如何改写查询以避免函数使用,或者如何分析执行计划。这时候需要给出示例,比如将`YEAR(create_time)=2023`改为范围查询,或者使用EXPLAIN命令查看索引使用情况。 最后,需要确保引用相关的资料,比如用户提到的参考文章,可能涉及更详细的优化策略,这里适当引用,增强回答的可信度。同时,生成的相关问题要围绕索引优化,比如失效场景分析、执行计划解读、联合索引设计等,帮助用户进一步学习。</think>### 预防SQL索引失效的最佳实践与常见原因分析 #### 一、索引失效的常见原因 1. **对索引列进行运算或函数操作** ```sql SELECT * FROM users WHERE YEAR(create_time) = 2023; -- 索引失效 ``` 若对索引列`create_time`使用`YEAR()`函数,数据库无法直接使用索引,需全表扫描[^1]。 2. **隐式类型转换** ```sql SELECT * FROM orders WHERE order_no = 10086; -- 若order_no是字符串类型,索引失效 ``` 数据库需将`order_no`隐式转换为数字,导致索引失效。 3. **LIKE查询以通配符开头** ```sql SELECT * FROM products WHERE name LIKE '%apple%'; -- 无法使用索引 ``` B树索引无法匹配前缀模糊查询,建议使用`LIKE 'apple%'`或全文索引。 4. **未遵循最左前缀原则** 联合索引`(a, b, c)`的查询条件若缺少`a`,如`WHERE b=1 AND c=2`,索引失效。 5. **OR条件未完全覆盖索引** ```sql SELECT * FROM logs WHERE id = 100 OR content = 'error'; -- 若content无索引,全表扫描 ``` --- #### 二、预防索引失效的最佳实践 1. **保持WHERE条件列“干净”** 避免对索引列进行运算或函数调用,改为直接比较: ```sql SELECT * FROM users WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'; ``` 2. **严格匹配数据类型** 确保查询条件类型与列定义一致: ```sql SELECT * FROM orders WHERE order_no = '10086'; -- 显式使用字符串 ``` 3. **优化LIKE查询结构** 使用右模糊查询或全文索引: ```sql SELECT * FROM products WHERE name LIKE 'apple%'; -- 使用索引 ``` 4. **联合索引设计原则** - 高频查询条件放在最左侧 - 根据查询场景调整列顺序 示例:联合索引`(country, city, age)`可支持以下查询: ```sql SELECT * FROM users WHERE country='中国' AND city='北京'; -- 使用索引 SELECT * FROM users WHERE country='中国' AND age>25; -- 部分使用索引 ``` 5. **使用EXPLAIN分析执行计划** ```sql EXPLAIN SELECT * FROM orders WHERE total_price > 1000; ``` 查看`key`列确认是否命中索引,`rows`列估算扫描行数。 6. **定期维护索引** ```sql ANALYZE TABLE orders; -- 更新统计信息 OPTIMIZE TABLE orders; -- 重建表及索引 ALTER INDEX idx_name REBUILD; -- 重建特定索引(部分数据库支持) ``` --- #### 三、进阶优化策略 1. **覆盖索引优化** 包含查询所需全部字段的索引可避免回表操作: ```sql CREATE INDEX idx_covering ON orders (user_id, status) INCLUDE (total_price); ``` 2. **索引选择性评估** 选择性计算公式: $$ \text{选择性} = \frac{\text{不同值数量}}{\text{总行数}} $$ 选择性>0.1的列更适合建索引。 3. **避免过度索引** 每个额外索引会增加写操作成本,建议单表索引不超过5个。 --- #### 四、典型案例分析 **案例1:日期范围查询优化** ❌ 低效写法: ```sql SELECT * FROM sales WHERE DATE_FORMAT(sale_time, '%Y-%m') = '2023-08'; ``` ✅ 优化方案: ```sql SELECT * FROM sales WHERE sale_time >= '2023-08-01' AND sale_time < '2023-09-01'; ``` **案例2:组合索引优化** 表结构:`employees (id, dept_id, salary)` 高频查询: ```sql SELECT * FROM employees WHERE dept_id=5 ORDER BY salary DESC LIMIT 10; ``` 优化方案: ```sql CREATE INDEX idx_dept_salary ON employees (dept_id, salary DESC); ``` ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值