SQL优化：索引优化

SQL索引

 　　SQL索引在数据库优化中占有一个很是大的比例， 一个好的索引的设计，可让你的效率提升几十甚至几百倍，在这里将带你一步步揭开他的神秘面纱。mysql

　　1.1 什么是索引？web

　　SQL索引有两种，汇集索引和非汇集索引，索引主要目的是提升了SQL Server系统的性能，加快数据的查询速度与减小系统的响应时间 sql

下面举两个简单的例子：数据库

        图书馆的例子：一个图书馆那么多书，怎么管理呢？创建一个字母开头的目录，例如：a开头的书，在第一排，b开头的在第二排，这样在找什么书就好说了，这个就是一个汇集索引，但是不少人借书找某某做者的，不知道书名怎么办？图书管理员在写一个目录，某某做者的书分别在第几排，第几排，这就是一个非汇集索引api

        字典的例子：字典前面的目录，能够按照拼音和部首去查询，咱们想查询一个字，只须要根据拼音或者部首去查询，就能够快速的定位到这个汉字了，这个就是索引的好处，拼音查询法就是汇集索引，部首查询就是一个非汇集索引.性能优化

    看了上面的例子，下面的一句话你们就很容易理解了：网络

1. 汇集索引存储记录是物理上连续存在，而非汇集索引是逻辑上的连续，物理存储并不连续。
   
2. 就像字段，汇集索引是连续的，a后面确定是b，非汇集索引就不连续了，就像图书馆的某个做者的书，有可能在第1个货架上和第10个货架上。
   
3. 还有一个小知识点就是：汇集索引一个表只能有一个，而非汇集索引一个表能够存在多个。
   

　　　1.2 索引的存储机制app

  　　首先，无索引的表，查询时，是按照顺序存续的方法扫描每一个记录来查找符合条件的记录，这样效率十分低下,举个例子，若是咱们将字典的汉字随即打乱，没有前面的按照拼音或者部首查询，那么咱们想找一个字，按照顺序的方式去一页页的找，这样效率有多底，你们能够想象。数据库设计

       汇集索引和非汇集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致，其实理解起来很是简单，仍是举字典的例子：若是按照拼音查询，那么都是从a-z的，是具备连续性的，a后面就是b，b后面就是c， 汇集索引就是这样的，他是和表的物理排列顺序是同样的，例若有id为汇集索引，那么1后面确定是2,2后面确定是3，因此说这样的搜索顺序的就是汇集索引。ide

        非汇集索引就和按照部首查询是同样是，可能按照偏房查询的时候，根据偏旁‘弓’字旁，索引出两个汉字，张和弘，可是这两个其实一个在100页，一个在1000页，（这里只是举个例子），他们的索引顺序和数据库表的排列顺序是不同的，这个样的就是非汇集索引。

      原理明白了，那他们是怎么存储的呢？在这里简单的说一下，汇集索引就是在数据库被开辟一个物理空间存放他的排列的值，例如1-100，因此当插入数据时，他会从新排列整个整个物理空间，而非汇集索引其实能够看做是一个含有汇集索引的表，他只仅包含原表中非汇集索引的列和指向实际物理表的指针。他只记录一个指针，其实就有点和堆栈差很少的感受了

　　1.3 什么状况下设置索引 

• 创建索引的原则：
  

1) 定义主键的数据列必定要创建索引。

2) 定义有外键的数据列必定要创建索引。

3) 对于常常查询的数据列最好创建索引。

4) 对于须要在指定范围内的快速或频繁查询的数据列;

5) 常常用在WHERE子句中的数据列。

6) 常常出如今关键字order by、group by、distinct后面的字段，创建索引。若是创建的是复合索引，索引的字段顺序要和这些关键字后面的字段顺序一致，不然索引不会被使用。

7) 对于那些查询中不多涉及的列，重复值比较多的列不要创建索引。

8) 对于定义为text、image和bit的数据类型的列不要创建索引。

9) 对于常常存取的列避免创建索引 

9) 限制表上的索引数目。对一个存在大量更新操做的表，所建索引的数目通常不要超过3个，最多不要超过5个。索引虽然说提升了访问速度，但太多索引会影响数据的更新操做。

10) 对复合索引，按照字段在查询条件中出现的频度创建索引。在复合索引中，记录首先按照第一个字段排序。对于在第一个字段上取值相同的记录，系统再按照第二个字段的取值排序，以此类推。所以只有复合索引的第一个字段出如今查询条件中，该索引才可能被使用,所以将应用频度高的字段，放置在复合索引的前面，会使系统最大可能地使用此索引，发挥索引的做用。

• 索引的不足之处
  

上面都在说使用索引的好处，但过多的使用索引将会形成滥用。所以索引也会有它的缺点：

1. 虽然索引大大提升了查询速度，同时却会下降更新表的速度，如对表进行INSERT、UPDATE和DELETE。由于更新表时，MySQL不只要保存数据，还要保存一下索引文件。
   
2. 创建索引会占用磁盘空间的索引文件。通常状况这个问题不太严重，但若是你在一个大表上建立了多种组合索引，索引文件的会膨胀很快。索引只是提升效率的一个因素，若是你的MySQL有大数据量的表，就须要花时间研究创建最优秀的索引，或优化查询语句。
   

使用索引时，有如下一些技巧和注意事项：

• 索引不会包含有NULL值的列

只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。因此咱们在数据库设计时不要让字段的默认值为NULL。

• 使用短索引

对串列进行索引，若是可能应该指定一个前缀长度。例如，若是有一个CHAR(255)的列，若是在前10个或20个字符内，多数值是唯一的，那么就不要对整个列进行索引。短索引不只能够提升查询速度并且能够节省磁盘空间和I/O操做。

• 索引列排序

MySQL查询只使用一个索引，所以若是where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。所以数据库默认排序能够符合要求的状况下不要使用排序操做；尽可能不要包含多个列的排序，若是须要最好给这些列建立复合索引。

• like语句操做

通常状况下不鼓励使用like操做，若是非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引，而like “aaa%”可使用索引。

• 不要在列上进行运算

select * from users where YEAR(adddate)<2007; 

将在每一个行上进行运算，这将致使索引失效而进行全表扫描，所以咱们能够改为

select * from users where adddate<‘2007-01-01’;  

• 不使用NOT IN和<>操做

1.4 如何建立索引

　　1.41 建立索引的语法：

CREATE [UNIQUE][CLUSTERED | NONCLUSTERED]  INDEX  index_name  

ON {table_name | view_name} [WITH [index_property [,....n]]

说明：

UNIQUE: 创建惟一索引。

CLUSTERED: 创建汇集索引。

NONCLUSTERED: 创建非汇集索引。

Index_property: 索引属性。

 UNIQUE索引既能够采用汇集索引结构，也能够采用非汇集索引的结构，若是不指明采用的索引结构，则SQL Server系统默认为采用非汇集索引结构。

1.42 删除索引语法：

DROP INDEX table_name.index_name[,table_name.index_name]

说明：table_name: 索引所在的表名称。

index_name : 要删除的索引名称。

1.43 显示索引信息：

使用系统存储过程：sp_helpindex 查看指定表的索引信息。

执行代码以下：

Exec sp_helpindex book1;

 1.44查询索引(都可) 

show index from table_name;

show keys from table_name;

desc table_Name;

　 1.44组合索引

不少时候，咱们在mysql中建立了索引，可是某些查询仍是很慢，根本就没有使用到索引！通常来讲，多是某些字段没有建立索引，或者是组合索引中字段的顺序与查询语句中字段的顺序不符。

看下面的例子：
假设有一张订单表(orders)，包含order_id和product_id二个字段。
一共有31条数据。符合下面语句的数据有5条。执行下面的sql语句：

select product_id

from orders

where order_id in (123, 312, 223, 132, 224);

这条语句要mysql去根据order_id进行搜索，而后返回匹配记录中的product_id。因此组合索引应该按照如下的顺序建立：

create index orderid_productid on orders(order_id, product_id)

mysql> explain select product_id from orders where order_id in (123, 312, 223, 132, 224) \G

*************************** 1. row ***************************

           id: 1

  select_type: SIMPLE

        table: orders

         type: range

possible_keys: orderid_productid

          key: orderid_productid

      key_len: 5

          ref: NULL

         rows: 5

        Extra: Using where; Using index

1 row in set (0.00 sec)

mysql> create index orderid_productid on orders(product_id, order_id);                                                      

Query OK, 31 rows affected (0.01 sec)

Records: 31  Duplicates: 0  Warnings: 0

mysql> explain select product_id from orders where order_id in (123, 312, 223, 132, 224) \G

*************************** 1. row ***************************

           id: 1

  select_type: SIMPLE

        table: orders

         type: index

possible_keys: NULL

          key: orderid_productid

      key_len: 10

          ref: NULL

         rows: 31

        Extra: Using where; Using index

1 row in set (0.00 sec)

mysql> alter table orders add modify_a char(255) default 'aaa';

Query OK, 31 rows affected (0.01 sec)

Records: 31  Duplicates: 0  Warnings: 0

mysql>

mysql>

mysql> explain select modify_a from orders where order_id in (123, 312, 223, 132, 224) \G         

*************************** 1. row ***************************

           id: 1

  select_type: SIMPLE

        table: orders

         type: ALL

possible_keys: NULL

          key: NULL

      key_len: NULL

          ref: NULL

         rows: 31

        Extra: Using where

1 row in set (0.00 sec)

col_a = "some value";

col_a = "some value" and col_b = "some value";

col_a = "some value" and col_b = "some value" and col_c = "some value";

col_b = "some value" and col_a = "some value" and col_c = "some value";

col_b = "aaaaaa";

col_b = "aaaa" and col_c = "cccccc";

mysql>SELECT ｀uid｀ FROM people WHERE lname｀='Liu'  AND ｀fname｀='Zhiqun' AND ｀age｀=26

ALTER TABLE people ADD INDEX lname (lname);

ALTER TABLE people ADD INDEX lname_fname_age (lame,fname,age);

SELECT t.Name FROM mytable t LEFT JOIN mytable m ON t.Name=m.username WHERE m.age=20 AND m.city='郑州'

SELECT * FROM mytable WHERE username like'admin%'

SELECT * FROM mytable WHEREt Name like'%admin'

select count(*) from record where date >'19991201' and date < '19991214'and amount >2000 (25秒)

select date ,sum(amount) from record group by date(55秒)

select count(*) from record where date >'19990901' and place in ('BJ','SH') (27秒)

---- 分析：----

date上有大量的重复值，在非群集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描才能找到这一范围内的所有行。

select count(*) from record where date >'19991201' and date < '19991214' and amount >2000 （14秒）

select date,sum(amount) from record group by date（28秒）

select count(*) from record where date >'19990901' and place in ('BJ','SH')（14秒）

---- 分析：---- 在群集索引下，数据在物理上按顺序在数据页上，重复值也排列在一块儿，于是在范围查找时，能够先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范围扫描，提升了查询速度。

select count(*) from record where date >'19991201' and date < '19991214' and amount >2000 （26秒）

select date,sum(amount) from record group by date（27秒）

select count(*) from record where date >'19990901' and place in ('BJ, 'SH')（< 1秒）

---- 分析：---- 这是一个不很合理的组合索引，由于它的前导列是place，第一和第二条SQL没有引用place，所以也没有利用上索引；第三个SQL使用了place，且引用的全部列都包含在组合索引中，造成了索引覆盖，因此它的速度是很是快的。

select count(*) from record where date >'19991201' and date < '19991214' and amount >2000(< 1秒)

select date,sum(amount) from record group by date（11秒）

select count(*) from record where date >'19990901' and place in ('BJ','SH')（< 1秒）

---- 分析：---- 这是一个合理的组合索引。它将date做为前导列，使每一个SQL均可以利用索引，而且在第一和第三个SQL中造成了索引覆盖，于是性能达到了最优。

select sum(a.amount) from account a,card b where a.card_no = b.card_no（20秒）

select sum(a.amount) from account a,card b where a.card_no = b.card_no and a.account_no=b.account_no（< 1秒）

select * from record where substring(card_no,1,4)='5378'(13秒)

select * from record where amount/30< 1000（11秒）

select * from record where convert(char(10),date,112)='19991201'（10秒）

分析：

where子句中对列的任何操做结果都是在SQL运行时逐列计算获得的，所以它不得不进行表搜索，而没有使用该列上面的索引；

若是这些结果在查询编译时就能获得，那么就能够被SQL优化器优化，使用索引，避免表搜索，所以将SQL重写成下面这样：

select * from record where card_no like'5378%'（< 1秒）

select * from record where amount< 1000*30（< 1秒）

select * from record where date= '1999/12/01'（< 1秒）

select count(*) from stuff where id_no in('0','1')（23秒）

分析：----

where条件中的'in'在逻辑上至关于'or'，因此语法分析器会将in ('0','1')转化为id_no ='0' or id_no='1'来执行。

咱们指望它会根据每一个or子句分别查找，再将结果相加，这样能够利用id_no上的索引；

但实际上（根据showplan）,它却采用了"OR策略"，即先取出知足每一个or子句的行，存入临时数据库的工做表中，再创建惟一索引以去掉重复行，最后从这个临时表中计算结果。所以，实际过程没有利用id_no上索引，而且完成时间还要受tempdb数据库性能的影响。

实践证实，表的行数越多，工做表的性能就越差，当stuff有620000行时，执行时间竟达到220秒！还不如将or子句分开：

select count(*) from stuff where id_no='0' select count(*) from stuff where id_no='1'

获得两个结果，再做一次加法合算。由于每句都使用了索引，执行时间只有3秒，在620000行下，时间也只有4秒。

或者，用更好的方法，写一个简单的存储过程：

create proc count_stuff asdeclare @a intdeclare @b intdeclare @c intdeclare @d char(10)beginselect @a=count(*) from stuff where id_no='0'select @b=count(*) from stuff where id_no='1'endselect @c=@a+@bselect @d=convert(char(10),@c)print @d

直接算出结果，执行时间同上面同样快！