MySql详解（二）--索引篇

MySQL索引篇

索引介绍

索引是什么

官方介绍索引是帮助MySQL高效获取数据的数据结构。更通俗的说，数据库索引好比是一本书前 面的目录，能加快数据库的查询速度。

一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往是存储在磁盘上的文件中的（可能存储在单独的索引文件中，也可能和数据一起存储在数据文件中）。

我们通常所说的索引，包括聚集索引、覆盖索引、组合索引、前缀索引、唯一索引等，没有特别说 明，默认都是使用B+树结构组织（多路搜索树，并不一定是二叉的）的索引。

索引的优势和劣势

优势：

可以提高数据检索的效率，降低数据库的IO成本，类似于书的目录。

通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗。

被索引的列会自动进行排序，包括【单列索引】和【组合索引】，只是组合索引的排序要复 杂一些。

如果按照索引列的顺序进行排序，对应order by语句来说，效率就会提高很多。

劣势：

索引会占据磁盘空间

索引虽然会提高查询效率，但是会降低更新表的效率。比如每次对表进行增删改操作，MySQL不 仅要保存数据，还有保存或者更新对应的索引文件。

索引的分类

单列索引

普通索引：MySQL中基本索引类型，没有什么限制，允许在定义索引的列中插入重复值和空值， 纯粹为了查询数据更快一点。

唯一索引：索引列中的值必须是唯一的，但是允许为空值。主键索引：是一种特殊的唯一索引，不允许有空值。

组合索引

在表中的多个字段组合上创建的索引

组合索引的使用，需要遵循最左前缀原则（最左匹配原则，后面高级篇讲解）。

一般情况下，建议使用组合索引代替单列索引（主键索引除外，具体原因后面知识点讲解）。

全文索引

只有在MyISAM引擎上才能使用，而且只能在CHAR,VARCHAR,TEXT类型字段上使用全文索引。

空间索引

不做介绍，一般使用不到。

索引的使用

创建索引

单列索引之普通索引

CREATE    INDEX    index_name    ON    table(column(length)) ;    
ALTER    TABLE    table_name    ADD    INDEX index_name (column(length))    ;

单列索引之唯一索引

CREATE    UNIQUE    INDEX    index_name    ON    table(column(length))    ;

单列索引之全文索引

CREATE    FULLTEXT    INDEX    index_name    ON    table(column(length))    ;

组合索引

ALTER    TABLE    article    ADD    INDEX    index_titme_time    (title,time);

注意事项：

- 创建索引时，可以指定索引列的长度，但是数值类型不要指定。

删除索引

DROP    INDEX    index_name    ON    table

查看索引

SHOW    INDEX    FROM    table_name    

索引的存储结构

• 页、块、扇区之间的关系和区别。

• 内存以页这个单位去进行IO读取，一般大小为4K，在MySQL中可以通过Innodb_page_size设置 大小，一般设置为16K。

• 操作系统以块这个逻辑单位去操作磁盘，常见为4K。

• 磁盘以扇区这个物理最小磁盘单位去存储数据，常见为512Byte。

• 页大小查看：getconf PAGE_SIZE，常见为4K； 磁盘块大小查看：stat /boot/|grep “IO Block”， 常见为4K； 扇区大小查看：fdisk-l，常见为512Byte；

• 指针默认长度为6bit，如果key为bigint的话，为8bit，那么一个索引的话为8+6 = 14bit；

索引存储结构介绍

索引是在存储引擎中实现的，也就是说不同的存储引擎，会使用不同的索引数据结构。

MyISAM和InnoDB存储引擎：只支持B+TREE索引， 也就是说默认使用B+TREE，不能够更换

B树和B+树

数据结构示例网站 ： https://www.cs.usfca.edu/~galles/visualization/Algorithms.html

B树图示：

B树是为了磁盘或其它存储设备而设计的一种多叉平衡查找树（下面你会看到，相对于二叉，B树每个 内结点有多个分支，即多叉）。

B树的高度一般都是在2-4这个高度，树的高度直接决定IO读写的次数以及查询时间复杂度（log(n)）。

如果是三层树结构---支撑的数据可以达到20G，如果是四层树结构---支撑的数据可以达到几十T

B树和B+树的区别

B树和B+树的最大区别在于非叶子节点是否存储数据的问题。

• B树是非叶子节点和叶子节点都会存储数据。

• B+树只有叶子节点才会存储数据，而且存储的数据都是在一行上，而且这些数据都是有指针指向的，是有顺链表。

聚集索引（InnoDB）

完整的记录，存储在主键索引中，通过主键索引，就可以获取记录所有的列，也就是说数据和索 引是在一起，这就是聚集索引。

主键索引

没有主键怎么办？

辅助索引（次要索引）

非聚集索引（MyISAM）

B+树叶子节点只会存储数据行（数据文件）的指针，简单来说数据和索引不在一起，就是非聚集 索引。

非聚集索引包含主键索引和辅助索引都会存储指针的值

主键索引

辅助索引（次要索引）

联合索引的存储结构

首先，表T1有字段a,b,c,d,e，其中a是主键，除e为varchar其余为int类型，并创建了一个联合索引idx_t1_bcd(b,c,d)，然后b、c、d三列作为联合索引，在B+树上的结构正如上图所示。联合索引 的所有索引列都出现在索引数上，并依次比较三列的大小。上图树高只有两层不容易理解，下面 是假设的表数据以及我对其联合索引在B+树上的结构图的改进。

PS：基于InnoDB存储引擎。

bcd联合索引在B+树上的结构图

联合索引的查找方式

当我们的SQL语言可以应用到索引的时候，比如select * from T1 where b = 12 and c = 14 andd = 3; 也就是T1表中a列为4的这条记录。存储引擎首先从根节点（一般常驻内存）开始查找，第一个索引的第一个索引列为1,12大于1，第二个索引的第一个索引列为56,12小于56，于是从这俩索引的中间 读到下一个节点的磁盘文件地址，从磁盘上Load这个节点，通常伴随一次磁盘IO，然后在内存里去查 找。当Load叶子节点的第二个节点时又是一次磁盘IO，比较第一个元素，b=12,c=14,d=3完全符合，于 是找到该索引下的data元素即ID值，再从主键索引树上找到最终数据。

最左前缀匹配原则

之所以会有最左前缀匹配原则和联合索引的索引构建方式及存储结构是有关系的。

首先我们创建的idx_t1_bcd(b,c,d)索引，相当于创建了(b)、（b、c）（b、c、d）三个索引，看完下面 你就知道为什么相当于创建了三个索引。

我们看，联合索引是首先使用多列索引的第一列构建的索引树，用上面idx_t1_bcd(b,c,d)的例子就是优 先使用b列构建，当b列值相等时再以c列排序，若c列的值也相等则以d列排序。我们可以取出索引树的 叶子节点看一下。

索引的第一列也就是b列可以说是从左到右单调递增的，但我们看c列和d列并没有这个特性，它们只能 在b列值相等的情况下这个小范围内递增，如第一叶子节点的第1、2个元素和第二个叶子节点的后三个元素。

由于联合索引是上述那样的索引构建方式及存储结构，所以联合索引只能从多列索引的第一列开始查找。所以如果你的查找条件不包含b列如（c,d）、(c）、(d)是无法应用缓存的，以及跨列也是无法完全 用到索引如(b,d)，只会用到b列索引。

查看执行计划

建表语句

create table tuser(
id int primary key,
name varchar(100),
age int,
sex char(1),
address varchar(100)
);
alter table tuser add index idx_name_age(name(100),age);
alter table tuser add index idx_sex(sex(1));

insert into tuser(id,name,age,sex,address) values (1,'zhangsan',20,'0','致真
大厦');

介绍

MySQL 提供了一个 EXPLAIN 命令, 它可以对 SELECT 语句的执行计划进行分析, 并输出SELECT 执行的详细信息, 以供开发人员针对性优化.

使用explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描，这都可以通过explain命令来查看。

可以通过explain命令深入了解MySQL的基于开销的优化器，还可以获得很多可能被优化器考虑到的访 问策略的细节，以及当运行SQL语句时哪种策略预计会被优化器采用。

EXPLAIN 命令用法十分简单, 在 SELECT 语句前加上 explain 就可以了,例如:

参数说明

EXPLAIN 命令的输出内容大致如下:

mysql> explain select * from user where id = 2
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: user_info
partitions: NULL
type: const
possible_keys: PRIMARY
key: PRIMARY
key_len: 8
ref: rows: filtered:
Extra: NULL
1 row in set,    1 warning    (0.00    sec)

各列的含义如下:

id: SELECT 查询的标识符. 每个 SELECT 都会自动分配一个唯一的标识符.

select_type: SELECT 查询的类型. table:查询的是哪个表

partitions: 匹配的分区

type: join 类型

possible_keys: 此次查询中可能选用的索引

key: 此次查询中确切使用到的索引. ref: 哪个字段或常数与key 一起被使用

rows: 显示此查询一共扫描了多少行. 这个是一个估计值. filtered: 表示此查询条件所过滤的数据的百分比

extra: 额外的信息

id

每个单位查询的SELECT语句都会自动分配的一个唯一标识符，表示查询中操作表的顺序，有以下情况：

id相同：执行顺序由上到下

id不同：如果是子查询，id号会自增，id越大，优先级越高。

id列为null的就表示这是一个结果集，不需要使用它来进行查询。

select_type（重要）

单位查询的查询类型，比如：普通查询、联合查询(union、union all)、子查询等复杂查询。

simple

表示不需要union操作或者不包含子查询的简单select查询。有连接查询时，外层的查询为simple，且只有一个

primary

一个需要union操作或者含有子查询的select，位于最外层的单位查询的select_type即为primary。且只 有一个

union

union连接的两个select查询，第一个查询是dervied派生表，除了第一个表外，第二个以后的表select_type都是union

dependent union

与union一样，出现在union 或union all语句中，但是这个查询要受到外部查询的影响

union result

包含union的结果集，在union和union all语句中,因为它不需要参与查询，所以id字段为null

subquery

除了from字句中包含的子查询外，其他地方出现的子查询都可能是subquery

dependent subquery

与dependentunion类似，表示这个subquery的查询要受到外部表查询的影响

derived

from字句中出现的子查询，也叫做派生表，其他数据库中可能叫做内联视图或嵌套select

table

显示的单位查询的表名，有如下几种情况：

• 如果查询使用了别名，那么这里显示的是别名如果不涉及对数据表的操作，那么这显示为null

• 如果显示为尖括号括起来的就表示这个是临时表，后边的N就是执行计划中的id，表示结果来自于 这个查询产生。

• 如果是尖括号括起来的<union M,N>，与类似，也是一个临时表，表示这个结果来自于union查询的id为M,N的结果集。

type

显示的是单位查询的连接类型或者理解为访问类型，访问性能依次从好到差：

1	system
2	const
3	eq_ref
4	ref
5	fulltext
6	ref_or_null
7	unique_subquery
8	index_subquery
9	range
10	index_merge
11	index
12	ALL

注意事项：

• 除了all之外，其他的type都可以使用到索引

• 除了index_merge之外，其他的type只可以用到一个索引

• 最少要使用到range级别

system

表中只有一行数据或者是空表。

const

使用唯一索引或者主键，返回记录一定是1行记录的等值where条件时，通常type是const。其他数据库 也叫做唯一索引扫描。

eq_ref

多表关联、等值连接。

等值连接的两个表的列是唯一索引列或者主键列。

此类型通常出现在多表的 join 查询, 表示对于前表的每一个结果, 都只能匹配到后表的一行结果. 并且查询的比较操作通常是 = , 查询效率较高。

ref

多表关联等值连接

等值连接的两个表的列是非唯一索引列

针对非唯一性索引，使用等值（=）查询。或者是使用了最左前缀规则索引的查询。

组合索引：

非唯一索引:

fulltext

全文索引检索，要注意，全文索引的优先级很高，若全文索引和普通索引同时存在时，mysql不管代 价，优先选择使用全文索引

ref_or_null

与ref方法类似，只是增加了null值的比较。实际用的不多。

unique_subquery

用于where中的in形式子查询，子查询返回不重复值唯一值

index_subquery

用于in形式子查询使用到了辅助索引或者in常数列表，子查询可能返回重复值，可以使用索引将子查询 去重。

range

索引范围扫描，常见于使用>,<,isnull,between ,in ,like等运算符的查询中。

index_merge

表示查询使用了两个以上的索引，最后取交集或者并集，常见and ，or的条件使用了不同的索引，官方排序这个在ref_or_null之后，但是实际上由于要读取所个索引，性能可能大部分时间都不如range

index

select结果列中使用到了索引，type会显示为index。

全部索引扫描，把索引从头到尾扫一遍，常见于使用索引列就可以处理不需要读取数据文件的查询、可 以使用索引排序或者分组的查询。

all

这个就是全表扫描数据文件，然后再在server层进行过滤返回符合要求的记录

possible_keys

此次查询中可能选用的索引，一个或多个

key

查询真正使用到的索引，select_type为index_merge时，这里可能出现两个以上的索引，其他的

select_type这里只会出现一个。

key_len

用于处理查询的索引长度，如果是单列索引，那就整个索引长度算进去，如果是多列索引，那么查询不一定都能使用到所有的列，具体使用到了多少个列的索引，这里就会计算进去，没有使用到的列，这里不会计算进去。

留意下这个列的值，算一下你的多列索引总长度就知道有没有使用到所有的列了。

另外，key_len只计算where条件用到的索引长度，而排序和分组就算用到了索引，也会计算到key_len中。

ref

如果是使用的常数等值查询，这里会显示const

• 如果是连接查询，被驱动表的执行计划这里会显示驱动表的关联字段

• 如果是条件使用了表达式或者函数，或者条件列发生了内部隐式转换，这里可能显示为func

rows

这里是执行计划中估算的扫描行数，不是精确值（InnoDB不是精确的值，MyISAM是精确的值，主要原 因是InnoDB里面使用了MVCC并发机制）

extra（重要）

这个列包含不适合在其他列中显示单十分重要的额外的信息，这个列可以显示的信息非常多，有几十种

using index（重要）

查询时不需要回表查询，直接通过索引就可以获取查询的结果数据。

• 表示相应的SELECT查询中使用到了覆盖索引（Covering Index），避免访问表的数据行，效率不错！

• 如果同时出现Using Where ，说明索引被用来执行查找索引键值

• 如果没有同时出现Using Where ，表明索引用来读取数据而非执行查找动作。

using where（重要）

表示Mysql server层将对storage engine提取的结果进行过滤，过滤条件字段无索引；

using indexcondition(重要)

介绍

Using index condition会先条件过滤索引，过滤完索引后找到所有符合索引条件的数据行，随后用WHERE 子句中的其他条件去过滤这些数据行；

因为MySQL的架构原因，分成了server层和引擎层，才有所谓的“下推”的说法。所以ICP（Index Condition Pushdown，索引下推）其实就是实现了index filter技术，将原来的在server层进行的table filter中可以进行index filter的部分，在引擎层面使用index filter进行处理，不再需要回表进行table filter。

Index Condition Pushdown(ICP)是MySQL 5.6中新特性，是一种在存储引擎层使用索引过滤数据的一种 优化方式。ICP可以减少存储引擎访问基表的次数以及MySQL服务器访问存储引擎的次数。

where条件分类

要想深入理解 ICP 技术，必须先理解数据库是如何处理 where 中的条件的。

对 where 中过滤条件的处理，根据索引使用情况分成了三种：indexkey, index filter, table filter。

index key

用于确定SQL查询在索引中的连续范围(起始范围+结束范围)的查询条件，被称之为Index Key。

由于一个范围，至少包含一个起始与一个终止，因此IndexKey也被拆分为Index First Key和Index Last Key，分别用于定位索引查找的起始，以及索引查询的终止条件。也就是说根据索引来确定扫描的范围。

Index filter

在使用 index key 确定了起始范围和结束范围之后，在此范围之内，还有一些记录不符合where条件， 如果这些条件可以使用索引进行过滤，那么就是 index filter。也就是说用索引来进行where条件过滤。

table filter

where 中的条件不能使用索引进行处理的，只能访问table，进行条件过滤了。

也就是说各种各样的 where 条件，在进行处理时，分成了上面三种情况：

• 一种条件会使用索引确定扫描的范围；

• 一种条件可以在索引中进行过滤；

• 一种必须回表进行过滤；

如何确定哪些where条件分别是 index key, index filter, table filter？

• 在 MySQL5.6 之前，并不区分Index Filter与Table Filter，统统将Index First Key与Index Last Key范围内的索引记录，回表读取完整记录，然后返回给MySQL Server层进行过滤。

• 而在MySQL 5.6（包含）之后，Index Filter与Table Filter分离，Index Filter下降到InnoDB的索引层面进行过滤，减少了回表与返回MySQLServer层的记录交互开销，提高了SQL的执行效率。

• 所以所谓的ICP技术，其实就是 index filter技术而已。只不过因为MySQL的架构原因，分成了server层和引擎层，才有所谓的“下推”的说法。所以ICP其实就是实现了index filter技术，将原来的在server层进行的table filter中可以进行indexfilter的部分，在引擎层面使用indexfilter进行处理，不再需要回表进行table filter。

不使用ICP扫描的过程

storage层：

只将满足index key条件的索引记录对应的整行记录取出，返回给server层。

server 层：

对返回的数据，使用后面的where条件过滤，直至返回最后一行。

使用ICP扫描的过程

storage层：

首先将index key条件满足的索引记录区间确定，然后在索引上使用index filter进行过滤将满足的index filter条件的索引记录才去回表取出整行记录返回server层。

不满足index filter条件的索引记录丢弃，不回表、也不会返回server层。

server 层：

对返回的数据，使用table filter条件做最后的过滤。

使用前后的成本差别

• 使用ICP前，存储层多返回了需要被index filter过滤掉的整行记录。

• 使用ICP后，直接就去掉了不满足index filter条件的记录，省去了他们回表和传递到server层的成本。

ICP 例子

官方文档给出了一个例子：

SELECT * FROM people WHERE zipcode = '95054' and lastname like '%etrunia%' AND
address LIKE '%Main Street%'

上面例子中的 lastername like '%etrunia%' 和 address like'%Main Street%' 本来是无法使用复合索引 index(zipcode, lastername, firstname) 进行过滤的，但是因为有了ICP技术，所以他们可以在index filter 阶段使用索引进行过滤，无需回表进行 table filter。

例子2：

role_goods 表上有组合索引 index(roleId,status,number)，下面的select语句，因为 “索引最左前缀原则”，只能使用到 组合索引的 roleId 部分，但是因为ICP 技术的存在，现在 number条件过滤也可以在 index filter 阶段完成了，无需像以前一样需要进行 tablefiler 了：

mysql> explain select * from role_goods where roleId=100000001 and number=1;
+----+-------------+------------+------+---------------+----------+---------
+-------+------+-----------------------+
| id | select_type | table    | type | possible_keys | key    | key_len |
ref    | rows | Extra    |
+----+-------------+------------+------+---------------+----------+---------
+-------+------+-----------------------+
|    1 | SIMPLE    | role_goods | ref    | roleId_2    | roleId_2 | 9    |
const |    14 | Using index condition |
+----+-------------+------------+------+---------------+----------+---------
+-------+------+-----------------------+
1 row in set (0.01 sec)

案例解析：

可以看到 key_len = 9, 因为 roleId是bigint 类型，所以 key_len = 8 + 1 = 9; 所以在 indexkey 阶段中， 并没有使用到 组合索引 index(roleId,status,number) 中的 number 字段(因为中间有一个status字段没有出现在where 条件中)，但是 “Usingindex condition” 却说明使用到了ICP技术，显然是 number=1 条件过滤使用到了ICP技术。

ICP的使用条件

• 只能用于二级索引(secondary index)。

• explain显示的执行计划中type值（join 类型）为range、 ref、 eq_ref或者ref_or_null且查询需要访问表的整行数据，即不能直接通过二级索引的元组数据获得查询结果(索引覆盖)。

• 对于InnnoDB表，ICP仅用于二级索引。（ICP的目的是减少全行读取的次数，从而减少IO操作）。

• 对于innodb聚集索引，完整的记录已被读入到innodb缓冲区，在这种情况下，ICP不会减少io。

• ICP可以用于MyISAM和InnnoDB存储引擎，不支持分区表（5.7将会解决这个问题）

using filesort（重要）

排序时无法使用到索引时，就会出现这个。常见于order by和group by语句中说明MySQL会使用一个外部的索引排序，而不是按照索引顺序进行读取。MySQL中无法利用索引完成的排序操作称为“文件排序”

using temporary

• 表示使用了临时表存储中间结果。

• MySQL在对查询结果orderby和group by时使用临时表

• 临时表可以是内存临时表和磁盘临时表，执行计划中看不出来，需要查看status变量，used_tmp_table，used_tmp_disk_table才能看出来。

distinct

在select部分使用了distinct关键字 （索引字段）

mysql> explain select distinct a.id from tuser a,tdep b where
a.dep=b.id;

+----+-------------+-------+--------+-----------------------------------
-------------+---------+---------+------------+------+------------------
-------------------------+
| id | select_type | table | type    | possible_keys
| key    | key_len | ref    | rows | Extra
|
+----+-------------+-------+--------+-----------------------------------
-------------+---------+---------+------------+------+------------------
-------------------------+
|    1 | SIMPLE    | a    | index    |
PRIMARY,idx_loginname,idx_name_age_sex,idx_dep | idx_dep | 5    |
NULL    |    2 | Using where; Using index; Using temporary |
|    1 | SIMPLE    | b    | eq_ref | PRIMARY
| PRIMARY | 4    | kkb2.a.dep |    1 | Using index;
Distinct    |
+----+-------------+-------+--------+-----------------------------------
-------------+---------+---------+------------+------+------------------
-------------------------+

no tables used

不带from字句的查询或者From dual查询

使用not in()形式子查询或not exists运算符的连接查询，这种叫做反连接

即，一般连接查询是先查询内表，再查询外表，反连接就是先查询外表，再查询内表。

索引失效分析

案例环境

案例演示

1.全值匹配我最爱

2.最佳左前缀法则

3.不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描

4.存储引擎不能使用索引中范围条件右边的列

5.尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致))，减少select *

6.mysql在使用不等于(!=或者<>)的时候无法使用索引会导致全表扫描

7.is null ,is not null也无法使用索引

8.like以通配符开头("%abc...' )导致mysql索引失效会变成全表扫描的操作

9.字符串不加单引号索引失效

10.少用or,用它来连接时会索引失效

1. 全值匹配

2. 最佳左前缀法则

带头索引不能死，中间索引不能断

如果索引了多个列，要遵守最佳左前缀法则。指的是查询从索引的最左前列开始 并且不跳过索引中的列。 正确的示例参考上图。

错误的示例：

带头索引死：

中间索引断（带头索引生效，其他索引失效）：

3. 不要在索引上做计算

不要进行这些操作：计算、函数、自动/手动类型转换，不然会导致索引失效而转向全表扫描。

4. 范围条件右边的列失效

不能继续使用索引中范围条件（bettween、<、>、in）等右边的列

5. 尽量使用覆盖索引

尽量使用覆盖索引（只查询索引的列），也就是索引列和查询列一致，减少select *

6. 索引字段上不要使用不等

7. 索引字段上不要判断null

索引字段上使用 is null/ is not null 判断时，会导致索引失效而转向全表扫描

8. 索引字段使用like不以通配符开头

索引字段使用like以通配符开头（‘%字符串’）时，会导致索引失效而转向全表扫描

由结果可知，like以通配符结束相当于范围查找，索引不会失效。与范围条件（bettween、<、>、in 等）不同的是：不会导致右边的索引失效。

问题：解决like ‘%字符串%’时，索引失效问题的方法？ 使用覆盖索引可以解决。

9. 索引字段字符串要加单引号

索引字段是字符串，但查询时不加单引号，会导致索引失效而转向全表扫描

10. 索引字段不要使用or

索引字段使用 or 时，会导致索引失效而转向全表扫描

总结

1.全值匹配我最爱

2.最佳左前缀法则

3.不在索引列上做任何操作（计算、函数、(自动or手动)类型转换），会导致索引失效而转向全表扫描

4.存储引擎不能使用索引中范围条件右边的列

5.尽量使用覆盖索引(只访问索引的查询(索引列和查询列一致))，减少select *

6.mysql在使用不等于(!=或者<>)的时候无法使用索引会导致全表扫描

7.is null ,is not null也无法使用索引

8.like以通配符开头("%abc...' )导致mysql索引失效会变成全表扫描的操作

9.字符串不加单引号索引失效

10.少用or,用它来连接时会索引失效