一.索引的作用
一般的应用系统,读写比例在10:1左右,而且插入操作和一般的更新操作很少出现性能问题,遇到最多的,也是最容易出问题的,还是一些复杂的查询操作,所以查询语句的优化显然是重中之重。
在数据量和访问量不大的情况下,mysql访问是非常快的,是否加索引对访问影响不大。但是当数据量和访问量剧增的时候,就会发现mysql变慢,甚至down掉,这就必须要考虑优化sql了,给数据库建立正确合理的索引,是mysql优化的一个重要手段。
索引的目的在于提高查询效率,可以类比字典,如果要查“mysql”这个单词,我们肯定需要定位到m字母,然后从上往下找到y字母,再找到剩下的sql。如果没有索引,那么你可能需要把所有单词看一遍才能找到你想要的。除了词典,生活中随处可见索引的例子,如火车站的车次表、图书的目录等。它们的原理都是一样的,通过不断的缩小想要获得数据的范围来筛选出最终想要的结果,同时把随机的事件变成顺序的事件,也就是我们总是通过同一种查找方式来锁定数据。
在创建索引时,需要考虑哪些列会用于 SQL 查询,然后为这些列创建一个或多个索引。事实上,索引也是一种表,保存着主键或索引字段,以及一个能将每个记录指向实际表的指针。数据库用户是看不到索引的,它们只是用来加速查询的。数据库搜索引擎使用索引来快速定位记录。
INSERT 与 UPDATE 语句在拥有索引的表中执行会花费更多的时间,而SELECT 语句却会执行得更快。这是因为,在进行插入或更新时,数据库也需要插入或更新索引值。
二.索引的创建、删除
索引的类型:
- UNIQUE(唯一索引):不可以出现相同的值,可以有NULL值
- INDEX(普通索引):允许出现相同的索引内容
- PROMARY KEY(主键索引):不允许出现相同的值
- fulltext index(全文索引):可以针对值中的某个单词,但效率确实不敢恭维
- 组合索引:实质上是将多个字段建到一个索引里,列值的组合必须唯一
温馨提示:根据《阿里巴巴Java开发手册》里的mysql规约,唯一索引建议命名为uk_字段名,普通索引名则为idx_字段名。(uk_即unique key; idx_即index的简称)。
(1)使用ALTER TABLE语句创建索性
应用于表创建完毕之后再添加。
1 | ALTER TABLE 表名 ADD 索引类型 (unique,primary key,fulltext,index)[索引名](字段名) |
1 | //普通索引 |
ALTER TABLE可用于创建普通索引、UNIQUE索引和PRIMARY KEY索引3种索引格式,table_name是要增加索引的表名,column_list指出对哪些列进行索引,多列时各列之间用逗号分隔。索引名index_name可选,缺省时,MySQL将根据第一个索引列赋一个名称。另外,ALTER TABLE允许在单个语句中更改多个表,因此可以同时创建多个索引。
(2)使用CREATE INDEX语句对表增加索引
CREATE INDEX可用于对表增加普通索引或UNIQUE索引,可用于建表时创建索引。
1 | CREATE INDEX index_name ON table_name(username(length)); |
如果是CHAR,VARCHAR类型,length可以小于字段实际长度;如果是BLOB和TEXT类型,必须指定 length。
1 | //只能添加这两种索引; |
table_name、index_name和column_list具有与ALTER TABLE语句中相同的含义,索引名不可选。另外,不能用CREATE INDEX语句创建PRIMARY KEY索引。
(3)删除索引
删除索引可以使用ALTER TABLE或DROP INDEX语句来实现。DROP INDEX可以在ALTER TABLE内部作为一条语句处理,其格式如下:
1 | drop index index_name on table_name ; |
其中,在前面的两条语句中,都删除了table_name中的索引index_name。而在最后一条语句中,只在删除PRIMARY KEY索引中使用,因为一个表只可能有一个PRIMARY KEY索引,因此不需要指定索引名。如果没有创建PRIMARY KEY索引,但表具有一个或多个UNIQUE索引,则MySQL将删除第一个UNIQUE索引。
如果从表中删除某列,则索引会受影响。对于多列组合的索引,如果删除其中的某列,则该列也会从索引中删除。如果删除组成索引的所有列,则整个索引将被删除。
(4) 组合索引与前缀索引
在这里要指出,组合索引和前缀索引是对建立索引技巧的一种称呼,并不是索引的类型。为了更好的表述清楚,建立一个demo表如下。
1 | create table USER_DEMO |
为了进一步榨取mysql的效率,就可以考虑建立组合索引,即将LOGIN_NAME,CITY,AGE建到一个索引里:
1 | ALTER TABLE USER_DEMO ADD INDEX name_city_age (LOGIN_NAME(16),CITY,AGE); |
建表时,LOGIN_NAME长度为100,这里用16,是因为一般情况下名字的长度不会超过16,这样会加快索引查询速度,还会减少索引文件的大小,提高INSERT,UPDATE的更新速度。
如果分别给LOGIN_NAME,CITY,AGE建立单列索引,让该表有3个单列索引,查询时和组合索引的效率是大不一样的,甚至远远低于我们的组合索引。虽然此时有三个索引,但mysql只能用到其中的那个它认为似乎是最有效率的单列索引,另外两个是用不到的,也就是说还是一个全表扫描的过程。
建立这样的组合索引,就相当于分别建立如下三种组合索引:
1 | LOGIN_NAME,CITY,AGE |
为什么没有CITY,AGE等这样的组合索引呢?这是因为mysql组合索引“最左前缀”的结果。简单的理解就是只从最左边的开始组合,并不是只要包含这三列的查询都会用到该组合索引。也就是说name_city_age(LOGIN_NAME(16),CITY,AGE)从左到右进行索引,如果没有左前索引,mysql不会执行索引查询。
如果索引列长度过长,这种列索引时将会产生很大的索引文件,不便于操作,可以使用前缀索引方式进行索引,前缀索引应该控制在一个合适的点,控制在0.31黄金值即可(大于这个值就可以创建)。
1 | SELECT COUNT(DISTINCT(LEFT(`title`,10)))/COUNT(*) FROM Arctic; -- 这个值大于0.31就可以创建前缀索引,Distinct去重复 |
三.索引的使用及注意事项
EXPLAIN可以帮助开发人员分析SQL问题,explain显示了mysql如何使用索引来处理select语句以及连接表,可以帮助选择更好的索引和写出更优化的查询语句。
使用方法,在select语句前加上Explain就可以了:
简要说明下:
参数 | 解释 |
---|---|
id | 选择标识符。id越大优先级越高,就越先被执行 |
select_type | 查询的类型 |
table | 输出结果集的表 |
partitions | 匹配的分区 |
type | 表的连接类型 |
possible_keys | 查询时可能使用的索引 |
key | 查询时可能使用的索引 |
key_len | 索引字段的长度 |
ref | 列与索引的比较 |
rows | 大概估算的行数 |
filtered | 按表条件过滤的行百分比 |
Extra | 执行情况的描述和说明 |
以上字段中type
字段是非常重要的,表的连接类型如下:
值 | 含义 |
---|---|
all | 扫描全表数据 |
index | 遍历索引 |
range | 索引范围查找 |
index_subquery | 在子查询中使用ref |
unique_subquery | 在子查询中使用eq_ref |
ref_or_null | 对null进行索引的优化的ref |
fulltext | 使用全文索引 |
ref | 使用非唯一索引查找数据 |
eq_ref | 在join查询中使用主键或唯一索引关联 |
select_type
:主要用于区别普通查询, 联合查询, 子查询等复杂查询。
- SIMPLE:查询中不包含子查询或者UNION
- 查询中若包含任何复杂的子部分,最外层查询则被标记为:PRIMARY
- 在SELECT或WHERE列表中包含了子查询,该子查询被标记为:SUBQUERY
- 在FROM列表中包含的子查询被标记为:DERIVED(衍生)
- 若第二个SELECT出现在UNION之后,则被标记为UNION;若UNION包含在FROM子句的子查询中,外层SELECT将被标记为:DERIVED
- 从UNION表获取结果的SELECT被标记为:UNION RESULT
possible_keys
:指出MySQL能使用哪个索引在表中找到行,查询涉及到的字段上若存在索引,则该索引将被列出,但不一定被查询使用。
key
:显示MySQL在查询中实际使用的索引,若没有使用索引,显示为NULL。
查询中若使用了覆盖索引,则该索引仅出现在key列表中。
key_len
:表示索引中使用的字节数,可通过该列计算查询中使用的索引的长度。
key_len显示的值为索引字段的最大可能长度,并非实际使用长度,即key_len是根据表定义计算而得,不是通过表内检索出的。
ref
:表示上述表的连接匹配条件,即哪些列或常量被用于查找索引列上的值。
rows
:表示MySQL根据表统计信息及索引选用情况,估算
(注意是估算,不是实际扫描的行数)的找到所需的记录所需要读取的行数。
Extra
:包含不适合在其他列中显示但十分重要的额外信息
- Using index:该值表示相应的select操作中使用了覆盖索引(Covering Index)。
- MySQL可以利用索引返回select列表中的字段,而不必根据索引再次读取数据文件
- 包含所有满足查询需要的数据的索引称为 覆盖索引(Covering Index)
- 注意:如果要使用覆盖索引,一定要注意select列表中只取出需要的列,不可select *,因为如果将所有字段一起做索引会导致索引文件过大,查询性能下降
- Using where:表示MySQL服务器在存储引擎受到记录后进行“后过滤”(Post-filter),
- 如果查询未能使用索引,Using where的作用只是提醒我们MySQL将用where子句来过滤结果集
- Using temporary:表示MySQL需要使用临时表来存储结果集,常见于排序和分组查询
- Using filesort:MySQL中无法利用索引完成的排序操作称为“文件排序”
下面来简单的介绍Extra中的一些区别:
- using index :使用覆盖索引的时候就会出现
- using where:在查找使用索引的情况下,需要回表去查询所需的数据
- using index condition:查找使用了索引,但是需要回表查询数据
- using index & using where:查找使用了索引,但是需要的数据都在索引列中能找到,所以不需要回表查询数据
以上四点就能看出它们之前的区别,或许有部分人都存在疑惑 using index & using where 和using index condition那个比较好,从上面的的解释中就能看出是前者比较好,毕竟不需要回表查询数据,效率上应该比较快的。
在stackoverflow中找到一个非常经典的描述:
尽量避免这些不走索引的sql:
1 | SELECT name,phone FROM `user` WHERE `age`+10=30; -- 不会使用索引,因为所有索引列参与了计算 |
索引虽然好处很多,但过多的使用索引可能带来相反的问题,索引也是有缺点的:
- 虽然索引大大提高了查询速度,同时却会降低更新表的速度,如对表进行INSERT,UPDATE和DELETE。因为更新表时,mysql不仅要保存数据,还要保存一下索引文件
- 建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重,但如果你在要给大表上建了多种组合索引,索引文件会膨胀很宽
索引只是提高效率的一个方式,如果mysql有大数据量的表,就要花时间研究建立最优的索引,或优化查询语句。
尽可能的使用主键查询,因为主键查询不会触发回表查询
,能节省一部分时间,变相提高了查询的性能。
使用索引时,有一些技巧
索引不会包含有NULL的列
只要列中包含有NULL值,都将不会被包含在索引中,复合索引中只要有一列含有NULL值,那么这一列对于此复合索引就是无效的。使用短索引
对串列进行索引,如果可以就应该指定一个前缀长度。例如,如果有一个char(255)的列,如果在前10个或20个字符内,多数值是唯一的,那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。索引列排序
mysql一张表查询只能用到一个索引。因此如果where子句中已经使用了索引的话,那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作,尽量不要包含多个列的排序,如果需要最好给这些列建复合索引。这一点是很多程序猿容易忽略的,如where子句的字段建了索引,排序的字段建了索引,但是分开建的,以为会走索引,其实这样的话排序的字段不会使用索引的,除非建复合索引,切记。like语句操作
一般情况下不鼓励使用like操作,如果非使用不可,注意正确的使用方式。like ‘%aaa%’不会使用索引,而like ‘aaa%’可以使用索引。不要在列上进行运算
不使用NOT IN 、<>、!=操作,但<,<=,=,>,>=,BETWEEN,IN是可以用到索引的。
索引要建立在经常进行select操作的字段上。
这是因为,如果这些列很少用到,那么有无索引并不能明显改变查询速度。相反,由于增加了索引,反而降低了系统的维护速度和增大了空间需求。索引要建立在值比较唯一的字段上。
对于那些定义为text、image和bit数据类型的列不应该增加索引。因为这些列的数据量要么相当大,要么取值很少。
在where和join中出现的列需要建立索引。
where的查询条件里有不等号(where column != …),mysql将无法使用索引。
如果where字句的查询条件里使用了函数(如:where DAY(column)=…),mysql将无法使用索引。
在join操作中(需要从多个数据表提取数据时),mysql只有在主键和外键的数据类型相同时才能使用索引,否则即使建立了索引也不会使用。这一点很容易忽略,切记,切记,切记!
在进行联表查询时,建立关联的表的字段类型最好一样且长度一致,这样能更好的发挥索引的作用。
组合索引时切记此条约束:
组合索引中有多个字段,其中一个字段是有范围判断,则需将此字段在最后面
。如1
ALTER TABLE USER_DEMO ADD INDEX name_age (NAME,AGE);
因为age会有范围判断,则建组合索引时将AGE字段放在后面。
简单总结这一条规则就是范右无索
(范围查询右边无法使用索引)。字符集字段比较,UTF8与UTF-BIN联合查询是不能走索引的。
如某张表的order_no字段类型为varchar(50),另一张表的order_no字段类型为varchar(50) COLLATE utf8_BIN。则此时联合查询时不能走索引的,切记。
即两张表的字段类型如下:1
2`order_no` varchar(50) COLLATE utf8_bin NOT NULL DEFAULT '' COMMENT '订单号';
`order_no` varchar(50) NOT NULL DEFAULT '' COMMENT '订单号';以下几种情况
不适合
建索引:- 表记录太少
- 经常插入、删除、修改的表
更新非常频繁的字段不适合创建索引
- 数据重复且分布平均的表字段。如一个表有10万行记录,其中字段column1只有A和B两种值,且每个值的分布概率大约为50%,那么对这种表column1字段建索引一般不会提高数据库的查询速度。
- 较频繁的查询字段应该创建索引
- 唯一性太差的字段不适合单独创建索引,即使该字段频繁作为查询条件
给表创建主键,对于没有主键的表,在查询和索引定义上有一定的影响。
避免表字段为null,建议设置默认值(如int类型设置默认值为0),这样在索引查询上,效率会高很多。
关于order by的索引问题重点说下:
无条件查询如果只有order by create_time,即便create_time上有索引,也不会使用到。
因为优化器认为走二级索引再去回表成本比全表扫描排序更高,所以选择走全表扫描。无条件查询但是order by create_time limit m,如果m值较小,是可以走索引的。
因为优化器认为根据索引有序性去回表查数据,然后得到m条数据,就可以终止循环,
那么成本比全表扫描小,则选择走二级索引。
即便没有二级索引,mysql针对order by limit也做了优化,采用堆排序。order by排序分为file sort和index,index的效率更高。但以下情况不会使用index排序:
- 检查的行数过多,并且没有使用覆盖索引
- 使用了多个索引,mysql一次只会采用一个索引
- where和order by使用了不同的索引,与上一条类似
- order by中加入了非索引列,且非索引列不在where中
- 当使用left join,使用右边的表字段排序
优化子查询
尽量使用join语句来替代子查询。因为子查询是嵌套查询,而嵌套查询会新建一张临时表,而临时表的创建和销毁会占用一定的系统资源,也花费一定的时间。但join语句并不会创建临时表,因此性能会高一点。
留意查询结果集
尽量使用
小表驱动大表
的方式进行查询。也就是如果B表的数据小于A表的数据,那执行的顺序就是先查B表再查A表。适当增加冗余字段
增加冗余字段可以减少大量的连表查询,因为多张表的连表查询性能很低,所以可以适当的增加冗余字段,以减少多张表的关联查询,这就是用
空间换时间
的优化策略。
参考: