Question

如何使用索引提高查询速度

Answer 1

人们在使用SQL时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略了不同的实现方法之间可能存在的
性能差异，这种性能差异在大型的或是复杂的数据库环境中（如联机事务处理OLTP或决策支持系统DSS）中表现得尤为明
显。笔者在工作实践中发现，不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。在对
它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个方面分别进行总结：

---- 为了更直观地说明问题，所有实例中的SQL运行时间均经过测试，不超过1秒的均表示为（< 1秒）。

---- 测试环境--
---- 主机：HP LH II
---- 主频：330MHZ
---- 内存：128兆
---- 操作系统：Operserver5.0.4
----数据库：Sybase11.0.3

一、不合理的索引设计
----例：表record有620000行，试看在不同的索引下，下面几个 SQL的运行情况：
---- 1.在date上建有一个非群集索引

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上有大量的重复值，在非群集索引下，数据在物理上随机存放在数据页上，在范围查找时，必须执行一次表扫描才能找到这一范围内的全部行。

---- 2.在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秒）

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

---- 3.在place，date，amount上的组合索引

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，且引用的所有列都包含在组合索引中，形成了索引覆盖，所以它的速度是非常快的。

---- 4.在date，place，amount上的组合索引
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中形成了索引覆盖，因而性能达到了最优。

---- 5.总结：

---- 缺省情况下建立的索引是非群集索引，但有时它并不是最佳的；合理的索引设计要建立在对各种查询的分析和预测
上。一般来说：

---- ①.有大量重复值、且经常有范围查询

（between, >,< ，>=,< =）和order by
、group by发生的列，可考虑建立群集索引；

---- ②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；

---- ③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。

二、不充份的连接条件：
---- 例：表card有7896行，在card_no上有一个非聚集索引，表account有191122行，在 account_no上有一个非聚集索引，试看在不同的表连接条件下，两个SQL的执行情况：

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

---- 将SQL改为：
select sum(a.amount) from account a,card b where a.card_no = b.card_no and a.account_no=b.account_no（< 1秒）

---- 分析：
---- 在第一个连接条件下，最佳查询方案是将account作外层表，card作内层表，利用card上的索引，其I/O次数可由以下公式估算为：

---- 外层表account上的22541页+（外层表account的191122行*内层表card上对应外层表第一行所要查找的3页）=595907次I/O

---- 在第二个连接条件下，最佳查询方案是将card作外层表，account作内层表，利用account上的索引，其I/O次数可由以下公式估算为：

---- 外层表card上的1944页+（外层表card的7896行*内层表account上对应外层表每一行所要查找的4页）= 33528次I/O

---- 可见，只有充份的连接条件，真正的最佳方案才会被执行。

---- 总结：

---- 1.多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的表；内外表的选择可由公式：外层表中的匹配行数*内层表中每一次查找的次数确定，乘积最小为最佳方案。

---- 2.查看执行方案的方法-- 用set showplanon，打开showplan选项，就可以看到连接顺序、使用何种索引的信息；想
看更详细的信息，需用sa角色执行dbcc(3604,310,302)。

三、不可优化的where子句
---- 1.例：下列SQL条件语句中的列都建有恰当的索引，但执行速度却非常慢：

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秒）

---- 你会发现SQL明显快起来！

---- 2.例：表stuff有200000行，id_no上有非群集索引，请看下面这个SQL：

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 as
declare @a int
declare @b int
declare @c int
declare @d char(10)
begin
select @a=count(*) from stuff where id_no='0'
select @b=count(*) from stuff where id_no='1'
end
select @c=@a+@b
select @d=convert(char(10),@c)
print @d

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

---- 可见，所谓优化即where子句利用了索引，不可优化即发生了表扫描或额外开销。

---- 1.任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

---- 2.in、or子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把子句拆开；拆开的子句中应该包含索引。

---- 3.要善于使用存储过程，它使SQL变得更加灵活和高效。

---- 从以上这些例子可以看出，SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。

Answer 2

(1)主键索引
它是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引：

复制代码 代码如下:

CREATE TABLE user(
id int unsigned not null auto_increment,
name varchar(50) not null,
email varchar(40) not null,
primary key (id)
);

(2)普通索引
这是最基本的索引，它没有任何限制。创建方式：

复制代码 代码如下:

create index idx_name on user(
name(20)
);

mysql支持前缀索引，一般姓名不会超过20个字符，所以我们这里建立索引的时候限定了长度20，这样可以节省索引文件大小

(3)唯一索引
它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。创建方式：

复制代码 代码如下:

CREATE UNIQUE INDEX idx_email ON user(
email
);

(4)全文索引
MySQL支持全文索引和搜索功能。MySQL中的全文索引类型为FULLTEXT的索引。 FULLTEXT 索引仅可用于 MyISAM表；

复制代码 代码如下:

CREATE TABLE articles (
id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
title VARCHAR(200),
body TEXT,
FULLTEXT (title,body)
);

mysql> SELECT * FROM articles WHERE MATCH (title,body) AGAINST ('database');

查询结果：
+----+-------------------+------------------------------------------+
| id | title | body |
+----+-------------------+------------------------------------------+
| 5 | MySQL vs. YourSQL | In the following database comparison ... |
| 1 | MySQL Tutorial | DBMS stands for DataBase ... |
+----+-------------------+------------------------------------------+
2 rows in set (0.00 sec)
MATCH()函数对于一个字符串执行资料库内的自然语言搜索。一个资料库就是1套1个或2个包含在FULLTEXT内的列。搜索字符串作为对AGAINST()的参数而被给定。对于表中的每一行, MATCH() 返回一个相关值，即, 搜索字符串和 MATCH()表中指定列中该行文字之间的一个相似性度量。
(5)复合索引

复制代码 代码如下:

CREATE TABLE test (
id INT NOT NULL,
last_name CHAR(30) NOT NULL,
first_name CHAR(30) NOT NULL,
PRIMARY KEY (id),
INDEX name (last_name,first_name)
);

name索引是一个对last_name和first_name的索引。索引可以用于为last_name，或者为last_name和first_name在已知范围内指定值的查询。因此，name索引用于下面的查询：
SELECT * FROM test WHERE last_name='Widenius';
SELECT * FROM test WHERE last_name='Widenius' AND first_name='Michael';
但是不能用于SELECT * FROM test WHERE first_name='Michael';这是因为MySQL组合索引为“最左前缀”的结果,简单的理解就是只从最左面的开始组合。

3.在什么情况下使用索引
(1)为搜索字段建索引,如果在你的表中，某个字段你经常用来做搜索，那么，请为其建立索引吧。一般来说，在WHERE和JOIN中出现的列需要建立索引以提高查询速度。
例如从fps表（表中有name字段）中检索姓名为"李武"的人，
下面用explain来解释执行建立索引和未建立索引的区别：
a.未建立索引前

复制代码 代码如下:

explain select name from fps where name="李武";

[SQL] select name from fps where name="李武";
影响的数据栏: 0
时间: 0.003ms
b.建立索引后

复制代码 代码如下:

create index idx_name on fps(
name
);

explain select name from fps where name="李武";

[SQL] select name from fps where name="李武";

影响的数据栏: 0
时间: 0.001ms

(2)下面我们就来看看这个EXPLAIN分析结果的含义。
table：这是表的名字。
type：连接操作的类型。下面是MySQL文档关于ref连接类型的说明：
“对于每个来自于前面的表的行组合，所有有匹配索引值的行将从这张表中读取。如果联接只使用键的最左边的前缀，或如果键不是
UNIQUE或PRIMARY KEY（换句话说，如果联接不能基于关键字选择单个行的话），则使用ref。如果使用的键仅仅匹配少量行，该联接
类型是不错的。” 在本例中，由于索引不是UNIQUE类型，ref是我们能够得到的最好连接类型。 如果EXPLAIN显示连接类型是“ALL”，而且你并不想从表里面选择出大多数记录，那么MySQL的操作效率将非常低，因为它要扫描整个表。你可以加入更多的索引来解决这个问题。预知更多信息，请参见MySQL的手册说明。
possible_keys：
可能可以利用的索引的名字。这里的索引名字是创建索引时指定的索引昵称；如果索引没有昵称，则默认显示的是索引中第一个列的名字
（在本例中，它是“idx_name”）。
Key：
它显示了MySQL实际使用的索引的名字。如果它为空（或NULL），则MySQL不使用索引。
key_len：
索引中被使用部分的长度，以字节计。
ref：
它显示的是列的名字（或单词“const”），MySQL将根据这些列来选择行。在本例中，MySQL根据三个常量选择行。
rows：
MySQL所认为的它在找到正确的结果之前必须扫描的记录数。显然，这里最理想的数字就是1。 本例中未索引前遍历的记录数为1041，而建立索引后为1
Extra：
这里可能出现许多不同的选项，其中大多数将对查询产生负面影响。在本例中，MySQL只是提醒我们它将用using where，using index子句限制搜索结果集。
4.最常用的存储引擎：
(1)Myisam存储引擎：每个Myisam在磁盘上存储成三个文件。文件名都和表名相同，扩展名分别为.frm（存储表定义）、.MYD（存储数据）、.MYI（存储索引）。数据文件和索引文件可以放置在不同目录，平均分布io，获得更快的速度。对存储大小没有限制，MySQL数据库的最大有效表尺寸通常是由操作系统对文件大小的限制决定的,
(2)InnoDB存储引擎：具有提交、回滚、奔溃恢复能力的事务安全。与Myisam相比，InnoDB的写效率差一些并且会占用更多的磁盘空间以保留数据和索引。
(3)如何选择合适的引擎
下面是常用存储引擎适用的环境：
Myisam：它是在Web、数据仓储和其他应用环境下最常使用的存储引擎;
InnoDB：用于事务处理应用程序，具有更多特性，包括ACID事务特性。