MySQL索引整理总结

 

一、索引是什么?

二、索引类型

三、索引的优化

 

一、索引是什么?

    是一种特殊文件,包含数据表里所有的引用指针。好比一本书的目录。

    索引,分为 聚簇索引,非聚簇索引 两大类,都是引用的 B+ 数索引。

    聚簇索引:也叫聚集索引,能提高 多行检索 的速度。类似新华字典,正文内容本身就是按照一定规律排列的目录。

    非聚簇索引:也叫非聚集索引,对于 单行检索 很快。这种目录纯粹是目录,正文纯粹是正文的排列方式。

 

聚集索引的形成:

    InnoDB 要求表必须有主键(MyISAM 可以没有),InnoDB 会按照以下规则进行处理:

      1.如果有一个主键被定义,那么这个主键就作为,聚集索引。

      2.如果没有主键定义,那么该表第一个,唯一非空索引就被作为,聚集索引。

      3.如果,没有主键,也没有合适唯一索引,那么 InnoDB 内部就会生成一个隐藏的主键作为聚集索引,这个索引是一个6字节的列,该列的值会随着数据插入自增。

      但是,业务角度上来说,自增ID列相对没什么意义,而聚集索引一个表只能有一个。所以这里引入了非聚集索引的概念。

 

非聚集索引:

    定义的原则往往是基于业务逻辑,非聚集索引在物理地址上不相邻,更像是一个数据字典索引。比聚集索引慢,但是表中可以建立多个。

 

    BTREE:默认,二叉树形式存储数据。

    HASH:一次定位,类似键值对形式存储,唯一。(只有“=”,“in”条件下有效,效率不高)

 

二、索引类型

1.普通索引:最基本索引,没有限制。

CREATE INDEX indexName ON table(column(length))

 

2.唯一索引:索引列必须唯一,但允许有空值(与主键不同),组合索引,则列值组合必须唯一

CREATE UNIQUE INDEX indexName ON table(column(length))

 

3.全文索引(FULL TEXT):仅可用于 MyISAM 引擎,针对 CHAR,VARCHAR,TEXT 列,吃资源。

CREATE FULLTEXT INDEX index_content ON article(content)

比使用 like 去逐行检索要快,因为建立倒排索引,极大的提升检索效率,用于全文搜索,是文档检索系统中最常用的数据结构。

 

4.单列索引、多列索引:多个单索引,与单个多索引不一样,因为查询时,mysql 只能是用一个索引,会从多个索引中选择一个限制最严格的索引。

 

5.组合索引(最左前缀):平常 SQL 查询一般都有多个限制条件,为了进一步提升效率,就要考虑组合索引。

    ALTER TABLE article ADD INDEX index_titme_time (title(50),time(10))

    此时,相当于分别建立了下面两组,组合索引:

      -- title,time

      -- title

    为什么没有 time 的组合索引呢?因为“最左前缀”:就是从最左面开始组合,例如

      -- 使用上述索引

      select * from article where title="程序猿" and time=20200313;

      select * from article where title="程序猿";

      -- 未使用上述索引

      select * from article where time=20203013;

 

三、索引的优化

索引能大大提升查询效率,也会降低更新表的速度,如 INSERT/UPDATE/DELETE。因为保存数据同时,也要保存索引文件。

1.索引不包含 NULL 值列

只要列中有 NULL,就不会包含在索引中,所以最好索引列默认不为 NULL。复合索引也会因 为 NULL 列而失效。

 

2.使用短索引

对串列进行索引,最好指定前缀长度。如,有一个CHAR(255)的列,如果在前10个或者20个字符内,多数值是唯一的,那么就不需要对整个列进行索引。

短索引,不近可以提升查询效率,还能节省磁盘空间,和 I/O 操作。

 

3.索引列排序

MySQL 查询只用一个索引,即 where 中使用,则 order by 就不使用索引了。如果能使用默认排序,就不要添加排序。尽量不要使用多个列排序,如果需要则添加复合索引。

 

4.like 语句操作

不鼓励使用 like,若非使用不可,like "%aaa%" 不使用索引,like "aaa%" 使用索引。

 

5.不要在列上进行运算

例如:select * from users where YEAR(add_date)<2007; --将每行计算,索引失效

改成:select * from users where add_date<'2007-01-01';

MySQL 只对以下操作符使用索引:<,<=,=,>,>=,between,in 以及某些时候的 like(不加通配符%)。

理论上,每张表最多可创建 16 个索引,除非数据量真的多,要不不要轻易添加索引。

 

6.不要使用 NOT IN 和 <> 操作

 

 

 

 

 

 

<think>好的,我现在需要帮助用户总结MySQL索引失效的常见场景及原因。首先,我要回忆用户提供的引用内容,确保信息准确。用户提到了四个引用,涉及索引失效的不同情况,比如OR条件、范围查询后的失效、LIKE操作符的使用等。 首先,我应该整理这些引用中的关键点。引用[1]提到了索引失效的几种常见场景,但没有具体说明;引用[2]指出OR关键字导致失效的情况,特别是当其中一个字段没有索引或使用范围查询时;引用[3]提到范围查询后索引可能部分使用,但后续条件可能失效;引用[4]强调LIKE以通配符开头导致索引失效。 接下来,我需要将用户的问题结构化,分点说明常见的失效场景。每个场景需要包含原因和示例,这样用户更容易理解。例如,OR条件的情况,需要说明当OR连接的字段中有一个无索引时,整个查询会失效。或者使用LIKE以%开头时,无法利用索引,因为最左前缀原则。 同时,要注意用户提到的系统级指令,比如行内数学表达式用$...$,独立公式用$$...$$,但这个问题可能不需要数学公式,所以可能不需要使用。另外,用中文回答,结构清晰,分点列出。 然后,根据引用中的信息,我需要确保每个失效场景都有对应的引用标注。例如,当提到OR条件失效时,引用[2]和引用[3]。对于范围查询后的索引失效,引用[3]指出优化器可能部分使用索引,但后续条件可能失效。LIKE的情况引用[4]。 可能还需要补充其他常见场景,比如对索引列使用函数或表达式,这会导致索引失效,但用户提供的引用中没有提到这点。不过用户的问题可能希望基于提供的引用,所以是否需要包括?根据引用内容,用户提供的引用里没有提到函数导致失效的情况,所以可能不在这里讨论。需要严格按照引用内容来组织答案。 检查是否有遗漏的引用内容。引用[2]还提到OR两边为范围查询时失效。引用[3]提到范围查询后索引可能部分使用,但其他条件可能失效。引用[4]主要讲LIKE的通配符开头问题。引用[1]是结语,没有具体场景。 总结起来,用户提供的引用中的场景包括: 1. OR条件导致失效(引用2) 2. 范围查询后的索引失效(引用3) 3. LIKE以%开头导致失效(引用4) 此外,可能还有其他场景如不遵循最左前缀原则、数据类型隐式转换等,但根据用户提供的引用,可能需要集中在提到的几点。或者用户可能希望更全面的总结,但根据提供的引用,需要基于引用内容来回答。 不过,用户的问题是想了解常见的场景及原因,而提供的引用可能没有涵盖所有情况。但根据指令,回答中引用的段落末尾需要添加引用标识,所以必须确保每个点都有对应的引用来源。因此,我需要严格按照提供的四个引用中的信息来组织答案,可能无法涵盖其他常见场景如函数使用、数据类型转换等,因为引用中没有提到这些。 现在,开始组织回答结构: 第一部分:引言,说明索引失效的重要性,引用[1]的结语部分。 然后分点列出场景: 1. 使用OR条件导致索引失效(引用2) 2. 范围查询后的索引失效(引用3) 3. LIKE操作符以通配符开头(引用4) 4. 其他可能的场景,如果引用中有的话? 检查引用内容: 引用2提到OR条件,其中字段无索引或范围查询导致失效;引用3补充了范围查询后可能部分使用索引;引用4是LIKE的情况。引用1只是结语,没有具体场景。可能还有其他场景如联合索引不遵循最左前缀,但用户提供的引用中没有提到,所以可能不在回答范围内。 因此,主要分三个场景: 1. OR条件导致索引失效 2. 范围查询后的索引部分失效 3. LIKE操作符以通配符开头 每个场景需要详细说明原因,并附上示例和对应的引用。例如: 对于OR条件,当其中一个字段没有索引,整个查询无法使用索引,必须全表扫描,如select * from table where a=1 or b=2,如果b无索引,则索引失效(引用2)。此外,如果OR两边是范围查询,也会失效(引用2)。 范围查询后的情况,例如where a>10 and b=5,如果a和b是联合索引,a的范围查询导致b无法使用索引(引用3)。 LIKE的情况,如where name like '%abc',无法使用索引(引用4)。 确保每个点都有对应的引用标识。然后,在最后生成相关问题,如: 相关问题可能包括如何避免索引失效、如何优化查询语句、索引设计的最佳实践等。 现在,把这些整理成结构清晰的回答,使用中文,分点说明,并正确标注引用。</think>### MySQL索引失效常见场景及原因总结 MySQL索引失效会严重影响查询性能,了解常见场景可帮助优化数据库设计和查询语句[^1]。以下是主要场景及分析: --- #### 1. **使用`OR`条件导致索引失效** - **原因**: - 如果`OR`连接的字段中**至少有一个字段未建立索引**,则整个查询会退化为全表扫描。 - 即使所有字段都有索引,若`OR`两侧为范围查询(如`>`、`<`),索引也可能失效[^2]。 - **示例**: ```sql SELECT * FROM users WHERE age = 25 OR address = 'Beijing'; ``` 若`address`字段无索引,即使`age`有索引,整体查询仍无法使用索引。 --- #### 2. **范围查询后的索引部分失效** - **原因**: - 在联合索引中,如果对某一列进行范围查询(如`BETWEEN`、`>`),其后的列无法继续使用索引。 - MySQL优化器可能仅使用索引的部分条件,后续过滤需在内存中完成[^3]。 - **示例**: ```sql SELECT * FROM orders WHERE create_time > '2023-01-01' AND status = 'paid'; ``` 若索引为`(create_time, status)`,范围查询`create_time > '2023-01-01'`会导致`status`无法利用索引。 --- #### 3. **`LIKE`操作符以通配符开头** - **原因**: - `LIKE`以`%`开头时(如`%abc`),违反**最左前缀匹配原则**,导致索引失效。 - 若通配符仅出现在末尾(如`abc%`),索引仍可能被使用[^4]。 - **示例**: ```sql SELECT * FROM products WHERE name LIKE '%apple%'; -- 索引失效 SELECT * FROM products WHERE name LIKE 'apple%'; -- 可能使用索引 ``` --- #### 4. **其他常见场景** - **数据类型隐式转换**: 若查询条件与索引字段类型不一致(如字符串字段使用数字值),会导致索引失效。 ```sql SELECT * FROM users WHERE phone = 13800138000; -- phone为VARCHAR类型 ``` - **对索引列使用函数或表达式**: 对索引列进行运算或函数调用(如`WHERE YEAR(create_time) = 2023`)会破坏索引结构。 --- ### 优化建议 1. 避免在`WHERE`子句中使用`OR`,改用`UNION`拆分查询。 2. 合理设计联合索引的顺序,将等值查询列放在范围查询列之前。 3. 对高频查询字段建立覆盖索引,减少回表操作。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值