数据库——MySQL——索引

时间 2019-12-11

标签数据库 mysql 索引栏目 SQL 繁體版

原文原文链接

索引的功能就是加速查找，MySQL中的primary key，unique，联合惟一也都是索引，只是这些索引除了加速查找之外，还有约束功能。html

通常的应用系统，读写比例在10:1左右，并且插入操做和通常的更新操做不多出现性能问题，在生产环境中，咱们遇到最多的，也是最容易出问题的，仍是一些复杂的查询操做，所以对查询语句的优化显然是重中之重。提及加速查询，就不得不提到索引了。索引在MySQL中也叫作“键”，是存储引擎用于快速找到记录的一种数据结构。索引对于良好的性能
很是关键，尤为是当表中的数据量愈来愈大时，索引对于性能的影响愈发重要。
索引优化应该是对查询性能优化最有效的手段了。索引可以轻易将查询性能提升好几个数量级。mysql

索引是应用程序设计和开发的一个重要方面。若索引太多，应用程序的性能可能会受到影响。而索引太少，对查询性能又会产生影响，要找到一个平衡点，这对应用程序的性能相当重要。sql

MySQL中经常使用的索引数据库

普通索引
- index：加速查找
惟一索引
- 主键索引primary key：加速查找+约束(不为空，不能重复)
- 惟一索引unique：加速查找+约束（不能重复）
联合索引
- primary key(id, name)：联合主键索引
- unique(id, name)：联合惟一索引
- index(id, name)：联合普通索引

索引原理及B+树的内容看我另外一篇博客：https://www.cnblogs.com/kuxingseng95/articles/9559097.html缓存

索引的两大类型

#咱们能够在建立上述索引的时候，为其指定索引类型，分两类
hash类型的索引：查询单条快，范围查询慢
btree类型的索引：b+树，层数越多，数据量指数级增加（咱们就用它，由于innodb默认支持它）

#不一样的存储引擎支持的索引类型也不同
InnoDB 支持事务，支持行级别锁定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；
MyISAM 不支持事务，支持表级别锁定，支持 B-tree、Full-text 等索引，不支持 Hash 索引；
Memory 不支持事务，支持表级别锁定，支持 B-tree、Hash 等索引，不支持 Full-text 索引；
NDB 支持事务，支持行级别锁定，支持 Hash 索引，不支持 B-tree、Full-text 等索引；
Archive 不支持事务，支持表级别锁定，不支持 B-tree、Hash、Full-text 等索引；

关于两种类型，推荐博客：http://www.javashuo.com/article/p-cevbwntc-bh.html性能优化

建立/删除索引的语法

#方法一：建立表时
    　　CREATE TABLE 表名 (
                字段名1  数据类型 [完整性约束条件…],
                字段名2  数据类型 [完整性约束条件…],
                [UNIQUE | FULLTEXT | SPATIAL ]   INDEX | KEY
                [索引名]  (字段名[(长度)]  [ASC |DESC]) 
                );


#方法二：CREATE在已存在的表上建立索引
        CREATE  [UNIQUE | FULLTEXT | SPATIAL ]  INDEX  索引名 
                     ON 表名 (字段名[(长度)]  [ASC |DESC]) ;


#方法三：ALTER TABLE在已存在的表上建立索引
        ALTER TABLE 表名 ADD  [UNIQUE | FULLTEXT | SPATIAL ] INDEX
                             索引名 (字段名[(长度)]  [ASC |DESC]) ;
                             
#删除索引：DROP INDEX 索引名 ON 表名字;

#方式一
create table t1(
    id int,
    name char,
    age int,
    sex enum('male','female'),
    unique key uni_id(id),
    index ix_name(name) #index没有key
);


#方式二
create index ix_age on t1(age);

#方式三
alter table t1 add index ix_sex(sex);

#查看
mysql> show create table t1;
| t1    | CREATE TABLE `t1` (
  `id` int(11) DEFAULT NULL,
  `name` char(1) DEFAULT NULL,
  `age` int(11) DEFAULT NULL,
  `sex` enum('male','female') DEFAULT NULL,
  UNIQUE KEY `uni_id` (`id`),
  KEY `ix_name` (`name`),
  KEY `ix_age` (`age`),
  KEY `ix_sex` (`sex`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1

示范

例子

关于查询须要了解的数据结构

在表中已存在大量数据的前提下，为某个字段创建索引，创建速度会很慢
必定是为搜索条件的字段建立索引
在innodb存储引擎中，索引和数据文件都是在一个拓展名为".ibd"的文件中。文件自己就是按照B+Tree组织的索引结构。这棵树的叶节点data域保存了完整的数据记录，这个索引的key是数据表的主键，所以innodb表数据文件自己就是主索引。
在mysam存储引擎中，索引文件和数据文件是分离的。索引存放在单独的拓展名为".myi"的索引文件中。索引文件仅保存数据记录的地址。

正确的使用索引

并非说咱们创建了索引就必定会加快查询的速度，若是想要利用索引达到预想的提升查询速度的效果，咱们在添加索引时，必须考虑如下问题。ide

1.范围问题函数

当条件中出现>,>=,<,<=,!=,between...and..,like这样的条件不许确的符号或者关键字性能

除了like的符号或者关键字要看查找的范围大小了。

当like匹配的字符中有%，可是处于开头的时候，速度慢。其余状况速度仍是很快的。

2.尽可能选择区分度高的列做为索引

区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大咱们扫描的记录数越少，惟一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不一样，这个值也很难肯定，通常须要join的字段咱们都要求是0.1以上，

3. =和in能够乱序，好比a = 1 and b = 2 and c = 3 创建(a,b,c)索引能够任意顺序，mysql的查询优化器会帮你优化成索引能够识别的形式

4.索引列不能参与计算，保持列“干净”，好比id*3 = 3000。缘由很简单，b+树中存的都是数据表中的字段值，但进行检索时，须要把全部元素都应用函数才能比较，显然成本太大。因此语句应该写成create_time = unix_timestamp(’2014-05-29’)

5.and/or

#一、and与or的逻辑
    条件1 and 条件2:全部条件都成立才算成立，但凡要有一个条件不成立则最终结果不成立
    条件1 or 条件2:只要有一个条件成立则最终结果就成立

#二、and的工做原理
    条件：
        a = 10 and b = 'xxx' and c > 3 and d =4
    索引：
        制做联合索引(d,a,b,c)
    工做原理:
        对于连续多个and：mysql会按照联合索引，从左到右的顺序找一个区分度高的索引字段(这样即可以快速锁定很小的范围)，加速查询，即按照d—>a->b->c的顺序

#三、or的工做原理
    条件：
        a = 10 or b = 'xxx' or c > 3 or d =4
    索引：
        制做联合索引(d,a,b,c)
        
    工做原理:
        对于连续多个or：mysql会按照条件的顺序，从左到右依次判断，即a->b->c->d

好比：

通过分析，在条件为name='egon' and gender='male' and id>333 and email='xxx'的状况下，咱们彻底不必为前三个条件的字段加索引，由于只能用上email字段的索引，前三个字段的索引反而会下降咱们的查询效率

6 最左前缀匹配原则（详见第八小节），很是重要的原则，对于组合索引mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就中止匹配(指的是范围大了，有索引速度也慢)，好比a = 1 and b = 2 and c > 3 and d = 4 若是创建(a,b,c,d)顺序的索引，d是用不到索引的，若是创建(a,b,d,c)的索引则均可以用到，a,b,d的顺序能够任意调整。

- 避免使用select *
- count(1)或count(列) 代替 count(*)
- 建立表时尽可能时 char 代替 varchar
- 表的字段顺序固定长度的字段优先
- 组合索引代替多个单列索引（常用多个条件查询时）
- 尽可能使用短索引
- 使用链接（JOIN）来代替子查询(Sub-Queries)
- 连表时注意条件类型需一致
- 索引散列值（重复少）不适合建索引，例：性别不适合
- 使用函数
    select * from tb1 where reverse(email) = 'egon';
            
- 类型不一致
    若是列是字符串类型，传入条件是必须用引号引发来，否则...
    select * from tb1 where email = 999;
    
#排序条件为索引，则select字段必须也是索引字段，不然没法命中
- order by
    select name from s1 order by email desc;
    当根据索引排序时候，select查询的字段若是不是索引，则速度仍然很慢
    select email from s1 order by email desc;
    特别的：若是对主键排序，则仍是速度很快：
        select * from tb1 order by nid desc;
 
- 组合索引最左前缀
    若是组合索引为：(name,email)
    name and email       -- 命中索引
    name                 -- 命中索引
    email                -- 未命中索引


- count(1)或count(列)代替count(*)在mysql中没有差异了

- create index xxxx  on tb(title(19)) #text类型，必须制定长度

其余

补充：查询优化之——explain：【转】https://www.jianshu.com/p/ea3fc71fdc45

关于使用，看后面的例子。

联合索引

若是是为了更快查询到数据，有单列索引不是ok了，为何有‘联合索引’的存在？

如今你们广泛的说法是由于，查询条件出现相似这类状况时‘where xx=xx && xx=xx && xx>xx’使用联合索引会比单列索引高效，因此要使用多列索引，可是通过测试，事情并不是如此，反而是单列索引处理时间比多列索引还快....

事实上建立多列索引的意义就是为了‘减小io操做’

联合索引的建立

联合索引时指对表上的多个列合起来作一个索引。联合索引的建立方法与单个索引的建立方法同样，不一样之处在仅在于有多个索引列，以下

mysql> create table t(
    -> a int,
    -> b int,
    -> primary key(a),
    -> key idx_a_b(a,b)
    -> );
Query OK, 0 rows affected (0.11 sec)

那么什么时候须要使用联合索引呢？在讨论这个问题以前，先来看一下联合索引内部的结果。从本质上来讲，联合索引就是一棵B+树，不一样的是联合索引的键值得数量不是1，而是>=2。接着来讨论两个整型列组成的联合索引，假定两个键值得名称分别为a、b如图

能够看到这与咱们以前看到的单个键的B+树并无什么不一样，键值都是排序的，经过叶子结点能够逻辑上顺序地读出全部数据，就上面的例子来讲，即（1,1），（1,2），（2,1），（2,4），（3,1），（3,2），数据按（a,b）的顺序进行了存放。

所以，对于查询select * from table where a=xxx and b=xxx, 显然是可使用(a,b) 这个联合索引的，对于单个列a的查询select * from table where a=xxx,也是可使用（a,b）这个索引的。

但对于b列的查询select * from table where b=xxx,则不可使用（a,b）索引，其实你不难发现缘由，叶子节点上b的值为一、二、一、四、一、2显然不是排序的，所以对于b列的查询使用不到(a,b) 索引

联合索引的第二个好处是在第一个键相同的状况下，已经对第二个键进行了排序处理，例如在不少状况下应用程序都须要查询某个用户的购物状况，并按照时间进行排序，最后取出最近三次的购买记录，这时使用联合索引能够帮咱们避免多一次的排序操做，由于索引自己在叶子节点已经排序了，以下

例子：

#===========准备表==============
create table buy_log(
    userid int unsigned not null,
    buy_date date
);

insert into buy_log values
(1,'2009-01-01'),
(2,'2009-01-01'),
(3,'2009-01-01'),
(1,'2009-02-01'),
(3,'2009-02-01'),
(1,'2009-03-01'),
(1,'2009-04-01');

alter table buy_log add key(userid);
alter table buy_log add key(userid,buy_date);

#===========验证==============
mysql> show create table buy_log;
| buy_log | CREATE TABLE `buy_log` (
  `userid` int(10) unsigned NOT NULL,
  `buy_date` date DEFAULT NULL,
  KEY `userid` (`userid`),
  KEY `userid_2` (`userid`,`buy_date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |

#能够看到possible_keys在这里有两个索引能够用，分别是单个索引userid与联合索引userid_2,可是优化器最终选择了使用的key是userid由于该索引的叶子节点包含单个键值，因此理论上一个页能存放的记录应该更多
mysql> explain select * from buy_log where userid=2;
+----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+
| id | select_type | table   | type | possible_keys   | key    | key_len | ref   | rows | Extra |
+----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+
|  1 | SIMPLE      | buy_log | ref  | userid,userid_2 | userid | 4       | const |    1 |       |
+----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+
row in set (0.00 sec)

#接着假定要取出userid为1的最近3次的购买记录，用的就是联合索引userid_2了，由于在这个索引中，在userid=1的状况下，buy_date都已经排序好了
mysql> explain select * from buy_log where userid=1 order by buy_date desc limit 3;
+----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+
| id | select_type | table   | type | possible_keys   | key      | key_len | ref   | rows | Extra                    |
+----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+
|  1 | SIMPLE      | buy_log | ref  | userid,userid_2 | userid_2 | 4       | const |    4 | Using where; Using index |
+----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+
row in set (0.00 sec)

#ps：若是extra的排序显示是Using filesort，则意味着在查出数据后须要二次排序(以下查询语句，没有先用where userid=3先定位范围，因而即使命中索引也没用，须要二次排序)
mysql> explain select * from buy_log order by buy_date desc limit 3;
+----+-------------+---------+-------+---------------+----------+---------+------+------+-----------------------------+
| id | select_type | table   | type  | possible_keys | key      | key_len | ref  | rows | Extra                       |
+----+-------------+---------+-------+---------------+----------+---------+------+------+-----------------------------+
|  1 | SIMPLE      | buy_log | index | NULL          | userid_2 | 8       | NULL |    7 | Using index; Using filesort |
+----+-------------+---------+-------+---------------+----------+---------+------+------+-----------------------------+


#对于联合索引（a,b）,下述语句能够直接使用该索引，无需二次排序
select ... from table where a=xxx order by b;

#而后对于联合索引(a,b,c)来首，下列语句一样能够直接经过索引获得结果
select ... from table where a=xxx order by b;
select ... from table where a=xxx and b=xxx order by c;

#可是对于联合索引(a,b,c)，下列语句不能经过索引直接获得结果，还须要本身执行一次filesort操做，由于索引（a，c)并未排序
select ... from table where a=xxx order by c;

View Code

覆盖索引

InnoDB存储引擎支持覆盖索引（covering index，或称索引覆盖），即从辅助索引中就能够获得查询记录，而不须要查询汇集索引中的记录。

使用覆盖索引的一个好处是：辅助索引不包含整行记录的全部信息，故其大小要远小于汇集索引，所以能够减小大量的IO操做

注意：覆盖索引技术最先是在InnoDB Plugin中完成并实现，这意味着对于InnoDB版本小于1.0的，或者MySQL数据库版本为5.0如下的，InnoDB存储引擎不支持覆盖索引特性

对于InnoDB存储引擎的辅助索引而言，因为其包含了主键信息，所以其叶子节点存放的数据为（primary key1，priamey key2，...,key1，key2，...）。例如

例子：

select age from s1 where id=123 and name = 'liming'; #id字段有索引，可是name字段没有索引,该sql命中了索引，但未覆盖，须要去汇集索引中再查找详细信息。
最牛逼的状况是，索引字段覆盖了全部，那全程经过索引来加速查询以及获取结果就ok了
mysql> desc s1;
+--------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| id | int(11) | NO | | NULL | |
| name | varchar(20) | YES | | NULL | |
| gender | char(6) | YES | | NULL | |
| email | varchar(50) | YES | | NULL | |
+--------+-------------+------+-----+---------+-------+
rows in set (0.21 sec)

mysql> explain select name from s1 where id=1000; #没有任何索引
+----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+
| 1 | SIMPLE | s1 | NULL | ALL | NULL | NULL | NULL | NULL | 2688336 | 10.00 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+
row in set, 1 warning (0.00 sec)

mysql> create index idx_id on s1(id); #建立索引
Query OK, 0 rows affected (4.16 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> explain select name from s1 where id=1000; #命中辅助索引，可是未覆盖索引，还须要从汇集索引中查找name
+----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------+
| 1 | SIMPLE | s1 | NULL | ref | idx_id | idx_id | 4 | const | 1 | 100.00 | NULL |
+----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------+
row in set, 1 warning (0.08 sec)

mysql> explain select id from s1 where id=1000; #在辅助索引中就找到了所有信息，Using index表明覆盖索引
+----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------------+
| 1 | SIMPLE | s1 | NULL | ref | idx_id | idx_id | 4 | const | 1 | 100.00 | Using index |
+----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------------+
row in set, 1 warning (0.03 sec)

View Code

从上面的例子能够看出来，覆盖索引的另外一个好处就是快速统计。

mysql> explain select count(*) from buy_log;
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table   | type  | possible_keys | key    | key_len | ref  | rows | Extra       |
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
|  1 | SIMPLE      | buy_log | index | NULL          | userid | 4       | NULL |    7 | Using index |
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)

View Code

慢查询优化

0.先运行看看是否真的很慢，注意设置SQL_NO_CACHE，讲缓存关掉。
1.where条件单表查，锁定最小返回记录表。这句话的意思是把查询语句的where都应用到表中返回的记录数最小的表开始查起，单表每一个字段分别查询，看哪一个字段的区分度最高
2.explain查看执行计划，是否与1预期一致（从锁定记录较少的表开始查询）
3.order by limit 形式的sql语句让排序的表优先查
4.了解业务方使用场景
5.加索引时参照建索引的几大原则
6.观察结果，不符合预期继续从0分析