索引对查询的速度有着至关重要的影响，理解索引也是进行数据库性能调优的起点，
sql学习笔记（15）MySQL索引与优化总结
。考虑如下情况，假设数据库中一个表有10^6条记录，DBMS的页面大小为4K，并存储100条记录。如果没有索引，查询将对整个表进行扫描，最坏的情况下，如果所有数据页都不在内存，需要读取10^4个页面，如果这10^4个页面在磁盘上随机分布，需要进行10^4次I/O，假设磁盘每次I/O时间为10ms(忽略数据传输时间)，则总共需要100s(但实际上要好很多很多)。如果对之建立B-Tree索引，则只需要进行log100(10^6)=3次页面读取，最坏情况下耗时30ms。
这就是索引带来的效果，很多时候，当你的应用程序进行SQL查询速度很慢时，应该想想是否可以建索引。
进入正题：
MySQL索引分为普通索引、唯一性索引、全文索引、单列索引、多列索引等等。这里将为大家介绍着几种索引各自的用途。一、 MySQL: 索引以B树格式保存
Memory存储引擎可以选择Hash或BTree索引，Hash索引只能用于=或<=>的等式比较。
1、普通索引：create index on Tablename(列的列表)
alter table TableName add index (列的列表)
create table TableName([...], index [IndexName] (列的列表)
2、唯一性索引：create unique index
alter ... add unique
主键：一种唯一性索引，必须指定为primary key
3、全文索引：从3.23.23版开始支持全文索引和全文检索，FULLTEXT， 可以在char、varchar或text类型的列上创建。
4、单列索引、多列索引： 多个单列索引与单个多列索引的查询效果不同，因为： 执行查询时，MySQL只能使用一个索引，会从多个索引中选择一个限制最为严格的索引。
5、前缀(Leftmost Prefixing)：多列索引，例如：fname_lname_age索引，以下的搜索条件MySQL都将使用
fname_lname_age索引：firstname,lastname,age;firstname,lastname;firstname，其他情况将不使用。
二、根据sql查询语句确定创建哪种类型的索引，如何优化查询
选择索引列：
a.性能优化过程中，选择在哪个列上创建索引是最重要的步骤之一。可以考虑使用索引的主要有 两种类型的列：在where子句中出现的列，在join子句中出现的列。
b.考虑列中值的分布，索引的列的基数越大，索引的效果越好。
c.使用短索引，如果对字符串列进行索引，应该指定一个前缀长度，可节省大量索引空间，提升查询速度。
d.利用最左前缀
e.不要过度索引，只保持所需的索引。每个额外的索引都要占用额外的磁盘空间，并降低写操作的性能。 在修改表的内容时，索引必须进行更新，有时可能需要重构，因此，索引越多，所花的时间越长。
MySQL只对一下操作符才使用索引：<,<=,=,>,>=,between,in, 以及某些时候的like(不以通配符%或_开头的情形)。
mysql 索引分类
在数据库表中，对字段建立索引可以大大提高查询速度。通过善用这些索引，可以令 MySQL的查询和运行更加高效。索引是快速搜索的关键。MySQL索引的建立对于MySQL的高效运行是很重要的。
三、下面介绍几种常见的MySQL索引类型。
1、普通型索引
这是最基本的索引类型，而且它没有唯一性之类的限制。普通索引可以通过以下几种方式创建：
（1）创建索引，例如CREATE INDEX 索引的名字 ON tablename (列名1，列名2,...);
（2）修改表，例如ALTER TABLE tablename ADD INDEX 索引的名字 (列名1，列名2,...);
（3）创建表的时候指定索引，例如CREATE TABLE tablename ( [...], INDEX 索引的名字 (列名1，列名
2,...) );
实例：
create table tableanme (fieldname1 columntype,fieldname2 columntype,index[indexname] (fieldname1 [,fieldname2...]));
create table tablename addindex[indexname] (fieldname1 [fieldname2...]);
alter table slaesadd index(value);
2、唯一索引
这种索引和前面的“普通索引”基本相同，但有一个区别：索引列的所有值都只能出现一次，即必须唯一。唯一性索引可以用以下几种方式创建：
（1）创建索引，例如CREATE UNIQUE INDEX 索引的名字 ON tablename (列的列表);
（2）修改表，例如ALTER TABLE tablename ADD UNIQUE 索引的名字 (列的列表);
（3）创建表的时候指定索引，例如CREATE TABLE tablename ( [...], UNIQUE 索引的名字 (列的列表) );
实例：
create table ui_test (f1 int,f2 int,unique(f1));
alter table ui_test add unique(f2);
3、主键
主键是一种唯一性索引，但它必须指定为“PRIMARY KEY”。如果你曾经用过AUTO_INCREMENT类型的列，你可能已经熟悉主键之类的概念了。主键一般在创建表的时候指定，例如“CREATE TABLE tablename ( [...], PRIMARY KEY (列的列表) ); ”。但是，我们也可以通过修改表的方式加入主键，例如“ALTER TABLE tablename ADD PRIMARY KEY (列的列表); ”。每个表只能有一个主键。 （主键相当于聚合索引，是查找最快的索引）
实例：
create table pk_test(f1 int not null,primary key(f1));
alter table customer modify id int not null,add primary key(id);
4、单列索引和多列索引
索引可以是单列索引，也可以是多列索引。
（1）单列索引就是常用的一个列字段的索引，常见的索引。
（2）多列索引就是含有多个列字段的索引
实例：
alter table student add index sy(name,age，score);
索引sy就为多列索引，多列索引在以下几中情况下才能有效：
select * from student where name='jia' and age>='12' //where条件中含有索引的首列字段和
第二个字段
select * from student where name='jia' //where条件中只含有首列字段
select * from student where name='jia' and score<60//where条件中含有首列字段和第三个字
段
总结：多列索引只有在where条件中含有索引中的首列字段时才有效
选择索引列
在性能优化过程中，选择在哪些列上创建索引是最重要的步骤之一。可以考虑使用索引的主要有两种类型的列：在WHERE子句中出现的列，在join子句中出现的列。请看下面这个查询：
SELECT age ## 不使用索引
FROM people WHERE firstname='Mike' ## 考虑使用索引
AND lastname='Sullivan' ## 考虑使用索引
这个查询与前面的查询略有不同，但仍属于简单查询。由于age是在SELECT部分被引用，MySQL不会用它来限制列选择操作。因此，对于这个查询来说，创建age列的索引没有什么必要。下面是一个更复杂的例子：
SELECT people.age, ##不使用索引
town.name ##不使用索引
FROM people LEFT JOIN town ON
people.townid=town.townid ##考虑使用索引
WHERE firstname='Mike' ##考虑使用索引
AND lastname='Sullivan' ##考虑使用索引
与前面的例子一样，由于firstname和lastname出现在WHERE子句中，因此这两个列仍旧有创建索引的必要。除此之外，由于town表的townid列出现在join子句中，因此我们需要考虑创建该列的索引。
那么，我们是否可以简单地认为应该索引WHERE子句和join子句中出现的每一个列呢？差不多如此，但并不完全。我们还必须考虑到对列进行比较的操作符类型。MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE。可以在LIKE操作中使用索引的情形是指另一个操作数不是以通配符（%或者_）开头的情形。例如，“SELECT peopleid FROM people WHERE firstname LIKE 'Mich%';”这个查询将使用索引，但“SELECT peopleid FROM people WHERE firstname LIKE '%ike';”这个查询不会使用索引。
删除或更改索引：
对索引的更改都需要先删除再重新定义。
alter table tablenamedrop primary key;
alter table tabledrop indexindexname;
drop index ontablename;
高效使用索引：
下面讨论的是用了索引会给我们带来什么？
1.) 获得域where从句中匹配的行：select * from customer wheresurname>‘c‘;
2.) 查找max()和min()值时，mysql只需在排序的索引中查找第一个和最后一个值。
3.) 返回的部分是索引的一部分，mysql就不需要去查询全表的数据而只需看索引：selectidfrom customer;
4.) 对域使用order by的地方：select * from customerorder bysurname;
5.) 还可以加速表的连接：select first_name,surname,commission from sales,sales_rep wheresales.sales_rep=sales_rep.employee_numberand code=8;
6.) 在通配符的情况下：select * from sales_rep where surnamelike ‘ser%‘;
这种情况就不能起作用：select * from sales_rep where surname like ‘%ser%‘;
选择索引：
1.) 有查询需要使用索引(比如where从句中条件的域)的时候，要创建索引；不要不使用的域(不如第一个字符是通配符的)创建索引。
2.) 创建的索引返回的行越少越好，主键最好，枚举类型的索引不什么用处。
3.) 使用短索引(比如，名字的头十个字符而不是全部)。
4.) 不要创建太多的索引，虽然加快了查询的速度，但增加了更新的添加记录的时间。如果索引在查询中很少使用，而没有索引只是轻微的影响速度，就不要创建索引。
最左边规则：
这种情况发生在多个有索引的域上，mysql从索引列表的最左边开始，按顺序使用他们。
alter table customer add initial varchar(5);
alter table customer add index(surname,initial,first_name);
update customer set initial=‘x‘ where id=1;
update customer set initial=‘c‘ where id=2;
update customer set initial=‘v‘ where id=3;
update customer set initial=‘b‘ where id=4;
update customer set initial=‘n‘ where id=20;
update customer set initial=‘m‘ where id=21;
如果在查询中使用了这三个域，那就最大限度的利用了索引：select * from customer where surname=‘clegg‘ and initial=‘x‘ and first_name=‘yvonne‘;
或者是利用索引的大部分：select * from customer where surname=‘clegg‘ and initial=‘x‘;
或仅仅是surname：select * from customer where surname=‘clegg‘;
如果打破最左边规则，下面的例子就不会用到索引：select * from customer where initial=‘x‘ and first_name=‘yvonne‘;
select * from customer where initial=‘x‘ ;
select * from customer where first_name=‘yvonne‘;
select * from customer where surname=‘clegg‘ and first_name=‘yvonne‘;
查看索引信息：
show index from tablename;
索引的缺点
到目前为止，我们讨论的都是索引的优点。事实上，索引也是有缺点的。
首先，索引要占用磁盘空间。通常情况下，这个问题不是很突出。但是，如果你创建每一种可能列组合的索引，索引文件体积的增长速度将远远超过数据文件。如果你有一个很大的表，索引文件的大小可能达到操作系统允许的最大文件限制。
第二，对于需要写入数据的操作，比如DELETE、UPDATE以及INSERT操作，索引会降低它们的速度。这是因为MySQL不仅要把改动数据写入数据文件，而且它还要把这些改动写入索引文件。
/*
所有MySQL列类型可以被索引。根据存储引擎定义每个表的最大索引数和最大索引长度。
所有存储引擎支持每个表至少16个索引，总索引长度至少为256字节。大多数存储引擎有更高的限制。
索引的存储类型目前只有两种（btree和hash），具体和存储引擎模式相关：
MyISAM btree
InnoDB btree
MEMORY/Heap hash，btree
默认情况MEMORY/Heap存储引擎使用hash索引
MySQL的btree索引和hash索引的区别
hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像btree(B-Tree)索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 hash 索引的查询效率要远高于 btree(B-Tree) 索引。
虽然 hash 索引效率高，但是 hash 索引本身由于其特殊性也带来了很多限制和弊端，主要有以下这些。
（1）hash 索引仅仅能满足=，<=>，IN，IS NULL或者IS NOT NULL查询，不能使用范围查询。
由于 hash 索引比较的是进行 hash 运算之后的 hash 值，所以它只能用于等值的过滤，不能用于基于范围的过滤，因为经过相应的 hash 算法处理之后的 hash 值的大小关系，并不能保证和hash运算前完全一样。
（2）hash 索引无法被用来避免数据的排序操作。
由于 hash 索引中存放的是经过 hash 计算之后的 hash 值，而且hash值的大小关系并不一定和 hash 运算前的键值完全一样，所以数据库无法利用索引的数据来避免任何排序运算；
（3）hash 索引不能利用部分索引键查询。
对于组合索引，hash 索引在计算 hash 值的时候是组合索引键合并后再一起计算 hash 值，而不是单独计算 hash 值，所以通过组合索引的前面一个或几个索引键进行查询的时候，hash 索引也无法被利用。
（4）hash 索引在任何时候都不能避免表扫描。
前面已经知道，hash 索引是将索引键通过 hash 运算之后，将 hash运算结果的 hash 值和所对应的行指针信息存放于一个 hash 表中，由于不同索引键存在相同 hash 值，所以即使取满足某个 hash 键值的数据的记录条数，也无法从 hash 索引中直接完成查询，还是要通过访问表中的实际数据进行相应的比较，并得到相应的结果。
（5）hash 索引遇到大量hash值相等的情况后性能并不一定就会比B-Tree索引高。
对于选择性比较低的索引键，如果创建 hash 索引，那么将会存在大量记录指针信息存于同一个 hash 值相关联。这样要定位某一条记录时就会非常麻烦，会浪费多次表数据的访问，而造成整体性能低下
B-Tree 索引是 MySQL 数据库中使用最为频繁的索引类型，除了 Archive 存储引擎之外的其他所有的存储引擎都支持 B-Tree 索引。不仅仅在 MySQL 中是如此，实际上在其他的很多数据库管理系统中B-Tree 索引也同样是作为最主要的索引类型，这主要是因为 B-Tree 索引的存储结构在数据库的数据检 索中有非常优异的表现。
一般来说， MySQL 中的 B-Tree 索引的物理文件大多都是以 Balance Tree 的结构来存储的，也就是所有实际需要的数据都存放于 Tree 的 Leaf Node ，而且到任何一个 Leaf Node 的最短路径的长度都是完全相同的，所以我们大家都称之为 B-Tree 索引当然，可能各种数据库（或 MySQL 的各种存储引擎）在存放自己的 B-Tree 索引的时候会对存储结构稍作改造。
如 Innodb 存储引擎的 B-Tree 索引实际使用的存储结构实际上是 B+Tree ，也就是在 B-Tree 数据结构的基础上做了很小的改造，在每一个Leaf Node 上面出了存放索引键的相关信息之外，还存储了指向与该 Leaf Node 相邻的后一个 LeafNode 的指针信息，这主要是为了加快检索多个相邻 Leaf Node 的效率考虑。
在 Innodb 存储引擎中，存在两种不同形式的索引，一种是 Cluster 形式的主键索引（ Primary Key ），另外一种则是和其他存储引擎（如 MyISAM 存储引擎）存放形式基本相同的普通 B-Tree 索引，这种索引在 Innodb 存储引擎中被称为 Secondary Index 。
在 Innodb 中如果通过主键来访问数据效率是非常高的，而如果是通过 Secondary Index 来访问数据的话， Innodb 首先通过 Secondary Index 的相关信息，通过相应的索引键检索到 Leaf Node之后，需要再通过 Leaf Node 中存放的主键值再通过主键索引来获取相应的数据行。
MyISAM 存储引擎的主键索引和非主键索引差别很小，只不过是主键索引的索引键是一个唯一且非空 的键而已。而且 MyISAM 存储引擎的索引和 Innodb 的 Secondary Index 的存储结构也基本相同，主要的区别只是 MyISAM 存储引擎在 Leaf Nodes 上面出了存放索引键信息之外，
再存放能直接定位到 MyISAM 数据文件中相应的数据行的信息（如 Row Number ），但并不会存放主键的键值信息。
我们这里建表
*/
CREATE TABLE mytable(
id INT,
username VARCHAR(16),
city VARCHAR(16),
age INT
);
/*
索引分单列索引和组合索引。单列索引，即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。组合索引，即一个索包含多个列。
MySQL索引类型包括：
（1）普通索引，这是最基本的索引，它没有任何限制。它有以下几种创建方式：
*/
-- 创建索引
CREATE INDEX indexName ON mytable(username(10)); -- 单列索引
-- CREATE INDEX indexName ON mytable(username(10),city(10)); -- 组合索引
-- indexName为索引名，mytable表名，username和city为列名，10为前缀长度，即索引在该列从最左字符开始存储的信息长度，单位字节
-- 如果是CHAR，VARCHAR类型，前缀长度可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 前缀长度，下同。
-- 修改表结构来创建索引
ALTER TABLE mytable ADD INDEX indexName (username(10));
-- ALTER TABLE mytable ADD INDEX indexName (username(10),city(10));
-- 此处 indexName 索引名可不写，系统自动赋名 username ，username_2 ，username_3，...
-- 创建表的时候直接指定
CREATE TABLE mytable(
id INT,
username VARCHAR(16),
city VARCHAR(16),
age INT,
INDEX indexName (username(10))-- INDEX indexName (username(10),city(10))
);
-- 此处 indexName 索引名同样可以省略
/*
（2）唯一索引，它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式（仅仅在创建普通索引时关键字 INDEX 前加 UNIQUE）：
*/
-- 创建索引
CREATE UNIQUE INDEX indexName ON mytable(username(10));
-- 修改表结构来创建索引
ALTER TABLE mytable ADD UNIQUE INDEX indexName (username(10));-- 也可简写成 ALTER TABLE mytable ADD UNIQUE indexName (username(10));
-- 创建表的时候直接指定
CREATE TABLE mytable(
id INT,
username VARCHAR(16),
city VARCHAR(16),
age INT,
UNIQUE INDEX indexName (username(10)) -- 也可简写成 UNIQUE indexName (username(10))
);
/*
（3）主键索引，它是一种特殊的唯一索引，不允许有空值。在建表的时候同时创建的主键即为主键索引
主键索引无需命名，一个表只能有一个主键。主键索引同时可是唯一索引或者全文索引，但唯一索引或全文索引不能共存在同一索引
*/
-- 修改表结构来创建索引
ALTER TABLE mytable ADD PRIMARY KEY (id);
-- 创建表的时候直接指定
CREATE TABLE mytable(
id INT,
username VARCHAR(16),
city VARCHAR(16),
age INT,
PRIMARY KEY(id)
);
/*
（4）全文索引，InnoDB存储引擎不支持全文索引
*/
-- 创建索引
CREATE FULLTEXT INDEX indexName ON mytable(username(10));
-- 修改表结构来创建索引
ALTER TABLE mytable ADD FULLTEXT INDEX indexName (username(10));-- 也可简写成 ALTER TABLE mytable ADD FULLTEXT indexName (username(10));
-- 创建表的时候直接指定
CREATE TABLE mytable(
id INT,
username VARCHAR(16),
city VARCHAR(16),
age INT,
FULLTEXT INDEX indexName (username(10)) -- 也可简写成 FULLTEXT indexName (username(10))
)ENGINE=MYISAM;
-- 建表时创建全文索引，要设置该表的存储引擎为MYISAM,新版mysql默认InnoDB存储引擎不支持全文索引
-- 删除索引
DROP INDEX indexName ON mytable;
/*
Mysql自动使用索引规则：
btree索引
当使用 <，<=，=，>=，>，BETWEEN，IN，!=或者<>，以及某些时候的LIKE才会使用btree索引，因为在以通配符%和_开头作查询时，MySQL不会使用索引。btree索引能用于加速ORDER BY操作
hash索引
当使用=，<=>，IN，IS NULL或者IS NOT NULL操作符时才会使用hash索引，并且不能用于加速ORDER BY操作，并且条件值必须是索引列查找某行该列的整个值
对where后边条件为字符串的一定要加引号，字符串如果为数字mysql会自动转为字符串，但是不使用索引。
mysql目前不支持函数索引，只能对列的前一部分（指定长度前缀）进行索引，对于char和varchar列，使用前缀索引（该列从起始字符到指定长度字符位置建立索引）将大大节省空间。
mysql列建议列是非null的。说是如果是允许null的列，对索引会有影响（索引不会包括有NULL值）。因为它们使得索引、索引的统计信息以及比较运算更加复杂。应该用0、一个特殊的值或者一个空串代替空值。
尽量不使用NOT IN和<>操作
username,city,age建立这三列的组合索引，其实是相当于分别建立了下面三组组合索引：
username,city,age
username,city
username
使用组合索引，比如where等条件，列名必须从组合索引最左列至右连续的列名做条件才可以，组合索引类似单一索引前缀
*/
-- 调用组合索引
SELECT * FROM mytable WHERE username = 'admin' AND city = 'DaLian';
-- 多表联查中的条件也可运用索引
-- 全文索引的使用
SELECT * , MATCH (username,city) AGAINST ('name100 name200 city500 thisisname') FROM mytable WHERE MATCH (username,city) AGAINST ('name100 name200 city500 thisisname');
-- 返回 mytable 表在 MATCH 的参数中的任意列中包含 AGAINST 字符串参数中被 "空格" "," 和 "." 分割的任意单词的行(断字的字符： "空格" "," 和 "." 但是不用这些符号断字的语言，如中文，就得自行手动断字。)
-- 表列中的单词也是以空格分割来区分
-- 这里指定 MATCH...AGAINST 两次。这不会引起附加的开销，因为 MySQL 优化器会注意到两次是同样的 MATCH...AGAINST 调用，并只调用一次全文搜索代码。
/*
函数 MATCH() 对照一个列名集(一个 FULLTEXT 索引中的一个或多个列的列名)。搜索字符串做为 AGAINST() 的参数给定。搜索以忽略字母大小写的方式执行，预设搜寻是不分大小写，若要分大小写，列的字符集设置要从utf8改成utf8_bin。
虽然同一个表格可以有不同字符集的字段，但是同一个FULLTEXT 索引里的字段必须是同一个字符集与collation。
任何在 stopword 列表上出现的，或太短的(3 个字符或更少的)的单词将被忽略。(可以覆写内建的 stopword 列表。可以修改最少四个字符的设定。 )
搜索的词有一个权重性，如果搜索的词在表中包含它的行太多，则这个搜索词将有较低的权重(可能甚至有一个零权重)，否则，它将得到一个较高的权重。然后，权重将被结合用于计算行的相似性。
如果搜索词在表中超过一半的行中出现。则它被有效地处理为一个 stopword (即，一个零语义值的词)，不搜索该词。
MATCH...AGAINST可以跟所有MySQL语法搭配使用，像是JOIN或是加上其他过滤条件。
对于表中的每行记录，MATCH...AGAINST 返回一个相关性值。即，返回的每行与搜索条件之间的相似性尺度。
当 MATCH() 被使用在一个 WHERE 子句中时，返回的结果被自动地以相关性从高到底的次序排序。如果即没有 WHERE 也没有 ORDER BY 子句，返回行是不排序的。
相关性值是正值的浮点数字。零相关性意味着不相似。
相关性的计算是基于：查找单词在表行中的数目、在行中唯一词的数目、在集中词的全部数目和包含一个特殊词的行的数目。
到 4.0.1 时，MySQL 也可以使用 IN BOOLEAN MODE 修饰语来执行一个逻辑全文搜索。
IN BOOLEAN MODE的特色：
不剔除50%以上符合的row。
不自动以相关性反向排序。
可以对没有FULLTEXT 索引的字段进行搜寻，但会非常慢。
限制最长与最短的字符串。
套用stopwords。
逻辑全文搜索支持下面的操作符：
+ 一个领头的加号表示，返回的结果的每行都必须包含有该单词。
- 一个领头的减号表示，包含该单词的行不能出现在返回的结果中。
> 操作符增加包含该单词返回行相似性值的基值。
< 操作符减少包含该单词返回行相似性值的基值。
() 被括号包含的多个词只相当一个词，即在查询时括号里只有一个词可代表该括号与括号外的词相结合做查询，但括号中每个词都会依次被轮到代表该括号，所以与括号外单词会产生多种结合形式，依次做查询条件，
电脑资料
《sql学习笔记（15）MySQL索引与优化总结》(https://www.unjs.com)。~ 将其相关性由正转负，表示拥有该字会降低相关性，但不像 - 将之排除，只是排在较后面。
* 一个星号是截断操作符，它应该被追加到一个词后，不加在前面。作用类似 LIKE 语句中的 %
"" 把被双引号包含的多个词作为一个词
这里是一些示例，在返回结果中：
1.+apple +juice ... 两个词均在被包含
2.+apple macintosh ... 包含词 “apple”，但是如果同时包含 “macintosh”，它的排列将更高一些
3.+apple -macintosh ... 包含 “apple” 但不包含 “macintosh”
4.+apple +(>pie
6."some words" ... 可以包含 “some words of wisdom”，但不是 “some noise words”
*/
SELECT *,MATCH (username,city) AGAINST ('>>name300 +thisisname -city100' IN BOOLEAN MODE) FROM mytable WHERE MATCH (username,city) AGAINST ('>>name300 +thisisname -city100' IN BOOLEAN MODE);
/*
全文索引的限制
MATCH() 函数的所有参数必须是从来自于同一张表的列，同时必须是同一个FULLTEXT 索引中的一部分，除非 MATCH() 是 IN BOOLEAN MODE 的。
MATCH() 列必须确切地匹配表的某一 FULLTEXT 索引中定义的列，除非 MATCH() 是 IN BOOLEAN MODE 的。
AGAINST() 的参数必须是一个常量字符串。
MySQL全文搜寻设定：
大部分的参数都是启动参数，也就是修改后必须重新启动MySQL。
有些参数修改必须重新产生索引文件。
mysql> SHOW VARIABLES LIKE 'ft%';
ft_boolean_syntax + -><()~*:""&|
ft_min_word_len 4
ft_max_word_len 84
ft_query_expansion_limit 20 ft_stopword_file (built-in)
ft_min_word_len：最短的索引字符串，默认值为4，修改后必须重建索引文件。
ft_max_word_len：最长的索引字符串，默认值因版本而不同，余同上一点。
[mysqld]
ft_min_word_len=1
ft_stopword_file：stopword档案路径，若留空白不设定表示要停用stopword过滤，修改后必须重新启动MySQL和重建索引；stopword档案内容可以用分行空白与逗号区隔stopword，但底线和单引号视为合法的字符串字符。
50%的门坎限制：配置文件在storage/myisam/ftdefs.h，将 #define GWS_IN_USE GWS_PROB 改为 #define GWS_IN_USE GWS_FREQ，然后重新编译MySQL，因为近低门坎会影响数据的精准度，所以不建议如此，可用IN BOOLEAN MODE即可以避开50%的限制。
ft_boolean_syntax：改变IN BOOLEAN MODE的查询字符，不用重新启动MySQL也不用重建索引。
修改字符串字符的认定，譬如说将「-」认定为字符串的合法字符：
方法一：修改storage/myisam/ftdefs.h的true_word_char()与misc_word_char()，然后重新编译MySQL，最后重建索引。
方法二：修改字符集档，然后在FULLTEXT index的字段使用该字符集，最后重建索引。
重建索引：
每个有FULLTEXT index的表格都要这么做。
mysql> REPAIR TABLE tbl_name QUICK;
要注意如果用过myisamchk，会导致上述的设定值回复成默认值，因为myisamchk不是用MySQL的设定值。
解法一：将修改过得设定值加到myisamchk的参数里。
shell> myisamchk --recover --ft_min_word_len=1 tbl_name.MYI
解法二：两边都要设定。
[mysqld]
ft_min_word_len=1
[myisamchk]
ft_min_word_len=1
解法三：用REPAIR TABLE、ANALYZE TABLE、OPTIMIZE TABLE与ALTER TABLE取代myisamchk语法，因为这些语法是由MySQL执行的。
中文全文索引可以建两个表，一个表字段里存中文，一个表对应字段存汉语拼音，两表行必须对应，数据一致，插入时中文转化下汉语拼音，两表都插入
查询时也转化下，全文索引查汉语拼音，然后找到中文表对应行
或者使用mysqlcft中文全文索引插件
查看索引使用情况
如果索引正在工作，Handler_read_key的值将很高，这个值代表了一个行被索引值读的次数，很低的值表明增加索引得到的性能改善不高，因为索引并不经常使用。
Handler_read_rnd_next的值高则意味着查询运行低效，并且应该建立索引补救。这个值的含义是在数据文件中读下一行的请求数。如果你正进行大量的表扫描，该值较高。通常说明表索引不正确或写入的查询没有利用索引。
语法：SHOW STATUS LIKE 'Handler_read%';
MyISAM表的数据文件和索引文件是自动分开的
InnoDB的数据和索引是存储在同一个表空间里面，但可以有多个文件组成
虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。
建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。
*/
第二章、索引与优化进阶
1、选择索引的数据类型
MySQL支持很多数据类型，选择合适的数据类型存储数据对性能有很大的影响。通常来说，可以遵循以下一些指导原则：
(1)越小的数据类型通常更好：越小的数据类型通常在磁盘、内存和CPU缓存中都需要更少的空间，处理起来更快。
(2)简单的数据类型更好：整型数据比起字符，处理开销更小，因为字符串的比较更复杂。在MySQL中，应该用内置的日期和时间数据类型，而不是用字符串来存储时间；以及用整型数据类型存储IP地址。
(3)尽量避免NULL：应该指定列为NOT NULL，除非你想存储NULL。在MySQL中，含有空值的列很难进行查询优化，因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值。
1.1、选择标识符
选择合适的标识符是非常重要的。选择时不仅应该考虑存储类型，而且应该考虑MySQL是怎样进行运算和比较的。一旦选定数据类型，应该保证所有相关的表都使用相同的数据类型。
(1) 整型：通常是作为标识符的最好选择，因为可以更快的处理，而且可以设置为AUTO_INCREMENT。
(2) 字符串：尽量避免使用字符串作为标识符，它们消耗更好的空间，处理起来也较慢。而且，通常来说，字符串都是随机的，所以它们在索引中的位置也是随机的，这会导致页面分裂、随机访问磁盘，聚簇索引分裂（对于使用聚簇索引的存储引擎）。
2、索引入门
对于任何DBMS，索引都是进行优化的最主要的因素。对于少量的数据，没有合适的索引影响不是很大，但是，当随着数据量的增加，性能会急剧下降。
如果对多列进行索引(组合索引)，列的顺序非常重要，MySQL仅能对索引最左边的前缀进行有效的查找。例如：
假设存在组合索引it1c1c2(c1,c2)，查询语句select * from t1 where c1=1 and c2=2能够使用该索引。查询语句select * from t1 where c1=1也能够使用该索引。但是，查询语句select * from t1 where c2=2不能够使用该索引，因为没有组合索引的引导列，即，要想使用c2列进行查找，必需出现c1等于某值。
2.1、索引的类型
索引是在存储引擎中实现的，而不是在服务器层中实现的。所以，每种存储引擎的索引都不一定完全相同，并不是所有的存储引擎都支持所有的索引类型。
2.1.1、B-Tree索引
假设有如下一个表：
CREATE TABLE People (
last_name varchar(50) not null,
first_name varchar(50) not null,
dob date not null,
gender enum('m', 'f') not null,
key(last_name, first_name, dob)
);
其索引包含表中每一行的last_name、first_name和dob列。其结构大致如下：
索引存储的值按索引列中的顺序排列。可以利用B-Tree索引进行全关键字、关键字范围和关键字前缀查询，当然，如果想使用索引，你必须保证按索引的最左边前缀(leftmost prefix of the index)来进行查询。
(1)匹配全值(Match the full value)：对索引中的所有列都指定具体的值。例如，上图中索引可以帮助你查找出生于1960-01-01的Cuba Allen。
(2)匹配最左前缀(Match a leftmost prefix)：你可以利用索引查找last name为Allen的人，仅仅使用索引中的第1列。
(3)匹配列前缀(Match a column prefix)：例如，你可以利用索引查找last name以J开始的人，这仅仅使用索引中的第1列。
(4)匹配值的范围查询(Match a range of values)：可以利用索引查找last name在Allen和Barrymore之间的人，仅仅使用索引中第1列。
(5)匹配部分精确而其它部分进行范围匹配(Match one part exactly and match a range on another part)：可以利用索引查找last name为Allen，而first name以字母K开始的人。
(6)仅对索引进行查询(Index-only queries)：如果查询的列都位于索引中，则不需要读取元组的值。
由于B-树中的节点都是顺序存储的，所以可以利用索引进行查找(找某些值)，也可以对查询结果进行ORDER BY。当然，使用B-tree索引有以下一些限制：
(1) 查询必须从索引的最左边的列开始。关于这点已经提了很多遍了。例如你不能利用索引查找在某一天出生的人。
(2) 不能跳过某一索引列。例如，你不能利用索引查找last name为Smith且出生于某一天的人。
(3) 存储引擎不能使用索引中范围条件右边的列。例如，如果你的查询语句为WHERE last_name="Smith" AND first_name LIKE 'J%' AND dob='1976-12-23'，则该查询只会使用索引中的前两列，因为LIKE是范围查询。
2.1.2、Hash索引
MySQL中，只有Memory存储引擎显示支持hash索引，是Memory表的默认索引类型，尽管Memory表也可以使用B-Tree索引。Memory存储引擎支持非唯一hash索引，这在数据库领域是罕见的，如果多个值有相同的hash code，索引把它们的行指针用链表保存到同一个hash表项中。
假设创建如下一个表：
CREATE TABLE testhash (
fname VARCHAR(50) NOT NULL,
lname VARCHAR(50) NOT NULL,
KEY USING HASH(fname)
) ENGINE=MEMORY;
包含的数据如下：
假设索引使用hash函数f( )，如下：
f('Arjen') = 2323
f('Baron') = 7437
f('Peter') = 8784
f('Vadim') = 2458
此时，索引的结构大概如下：
Slots是有序的，但是记录不是有序的。当你执行
mysql> SELECT lname FROM testhash WHERE fname='Peter';
MySQL会计算’Peter’的hash值，然后通过它来查询索引的行指针。因为f('Peter') = 8784，MySQL会在索引中查找8784，得到指向记录3的指针。
因为索引自己仅仅存储很短的值，所以，索引非常紧凑。Hash值不取决于列的数据类型，一个TINYINT列的索引与一个长字符串列的索引一样大。
Hash索引有以下一些限制：
(1)由于索引仅包含hash code和记录指针，所以，MySQL不能通过使用索引避免读取记录。但是访问内存中的记录是非常迅速的，不会对性造成太大的影响。
(2)不能使用hash索引排序。
(3)Hash索引不支持键的部分匹配，因为是通过整个索引值来计算hash值的。
(4)Hash索引只支持等值比较，例如使用=，IN( )和<=>。对于WHERE price>100并不能加速查询。
2.1.3、空间(R-Tree)索引
MyISAM支持空间索引，主要用于地理空间数据类型，例如GEOMETRY。
2.1.4、全文(Full-text)索引
全文索引是MyISAM的一个特殊索引类型，主要用于全文检索。
3、高性能的索引策略
3.1、聚簇索引(Clustered Indexes)
聚簇索引保证关键字的值相近的元组存储的物理位置也相同（所以字符串类型不宜建立聚簇索引，特别是随机字符串，会使得系统进行大量的移动操作），且一个表只能有一个聚簇索引。因为由存储引擎实现索引，所以，并不是所有的引擎都支持聚簇索引。目前，只有solidDB和InnoDB支持。
聚簇索引的结构大致如下：
注：叶子页面包含完整的元组，而内节点页面仅包含索引的列(索引的列为整型)。一些DBMS允许用户指定聚簇索引，但是MySQL的存储引擎到目前为止都不支持。InnoDB对主键建立聚簇索引。如果你不指定主键，InnoDB会用一个具有唯一且非空值的索引来代替。如果不存在这样的索引，InnoDB会定义一个隐藏的主键，然后对其建立聚簇索引。一般来说，DBMS都会以聚簇索引的形式来存储实际的数据，它是其它二级索引的基础。
3.1.1、InnoDB和MyISAM的数据布局的比较
为了更加理解聚簇索引和非聚簇索引，或者primary索引和second索引(MyISAM不支持聚簇索引)，来比较一下InnoDB和MyISAM的数据布局，对于如下表：
CREATE TABLE layout_test (
col1 int NOT NULL,
col2 int NOT NULL,
PRIMARY KEY(col1),
KEY(col2)
);
假设主键的值位于1---10,000之间，且按随机顺序插入，然后用OPTIMIZE TABLE进行优化。col2随机赋予1---100之间的值，所以会存在许多重复的值。
(1) MyISAM的数据布局
其布局十分简单，MyISAM按照插入的顺序在磁盘上存储数据，如下：
注：左边为行号(row number)，从0开始。因为元组的大小固定，所以MyISAM可以很容易的从表的开始位置找到某一字节的位置。
据些建立的primary key的索引结构大致如下：
注：MyISAM不支持聚簇索引，索引中每一个叶子节点仅仅包含行号(row number)，且叶子节点按照col1的顺序存储。
来看看col2的索引结构：
实际上，在MyISAM中，primary key和其它索引没有什么区别。Primary key仅仅只是一个叫做PRIMARY的唯一，非空的索引而已。
(2) InnoDB的数据布局
InnoDB按聚簇索引的形式存储数据，所以它的数据布局有着很大的不同。它存储表的结构大致如下：
注：聚簇索引中的每个叶子节点包含primary key的值，事务ID和回滚指针(rollback pointer)——用于事务和MVCC，和余下的列(如col2)。
相对于MyISAM，二级索引与聚簇索引有很大的不同。InnoDB的二级索引的叶子包含primary key的值，而不是行指针(row pointers)，这减小了移动数据或者数据页面分裂时维护二级索引的开销，因为InnoDB不需要更新索引的行指针。其结构大致如下：
聚簇索引和非聚簇索引表的对比：
3.1.2、按primary key的顺序插入行(InnoDB)
如果你用InnoDB，而且不需要特殊的聚簇索引，一个好的做法就是使用代理主键(surrogate key)——独立于你的应用中的数据。最简单的做法就是使用一个AUTO_INCREMENT的列，这会保证记录按照顺序插入，而且能提高使用primary key进行连接的查询的性能。应该尽量避免随机的聚簇主键，例如，字符串主键就是一个不好的选择，它使得插入操作变得随机。
3.2、覆盖索引(Covering Indexes)
如果索引包含满足查询的所有数据，就称为覆盖索引。覆盖索引是一种非常强大的工具，能大大提高查询性能。只需要读取索引而不用读取数据有以下一些优点：
(1)索引项通常比记录要小，所以MySQL访问更少的数据；
(2)索引都按值的大小顺序存储，相对于随机访问记录，需要更少的I/O；
(3)大多数据引擎能更好的缓存索引。比如MyISAM只缓存索引。
(4)覆盖索引对于InnoDB表尤其有用，因为InnoDB使用聚集索引组织数据，如果二级索引中包含查询所需的数据，就不再需要在聚集索引中查找了。
覆盖索引不能是任何索引，只有B-TREE索引存储相应的值。而且不同的存储引擎实现覆盖索引的方式都不同，并不是所有存储引擎都支持覆盖索引(Memory和Falcon就不支持)。
对于索引覆盖查询(index-covered query)，使用EXPLAIN时，可以在Extra一列中看到“Using index”。例如，在sakila的inventory表中，有一个组合索引(store_id,film_id)，对于只需要访问这两列的查询，MySQL就可以使用索引，如下：
mysql> EXPLAIN SELECT store_id, film_id FROM sakila.inventory\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: inventory
type: index
possible_keys: NULL
key: idx_store_id_film_id
key_len: 3
ref: NULL
rows: 5007
Extra: Using index
1 row in set (0.17 sec)
在大多数引擎中，只有当查询语句所访问的列是索引的一部分时，索引才会覆盖。但是，InnoDB不限于此，InnoDB的二级索引在叶子节点中存储了primary key的值。因此，sakila.actor表使用InnoDB，而且对于是last_name上有索引，所以，索引能覆盖那些访问actor_id的查询，如：
mysql> EXPLAIN SELECT actor_id, last_name
-> FROM sakila.actor WHERE last_name = 'HOPPER'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: actor
type: ref
possible_keys: idx_actor_last_name
key: idx_actor_last_name
key_len: 137
ref: const
rows: 2
Extra: Using where; Using index
3.3、利用索引进行排序
MySQL中，有两种方式生成有序结果集：一是使用filesort，二是按索引顺序扫描。利用索引进行排序操作是非常快的，而且可以利用同一索引同时进行查找和排序操作。当索引的顺序与ORDER BY中的列顺序相同且所有的列是同一方向(全部升序或者全部降序)时，可以使用索引来排序。如果查询是连接多个表，仅当ORDER BY中的所有列都是第一个表的列时才会使用索引。其它情况都会使用filesort。
create table actor(
actor_id int unsigned NOT NULL AUTO_INCREMENT,
name varchar(16) NOT NULL DEFAULT '',
password varchar(16) NOT NULL DEFAULT '',
PRIMARY KEY(actor_id),
KEY (name)
) ENGINE=InnoDB
insert into actor(name,password) values('cat01','1234567');
insert into actor(name,password) values('cat02','1234567');
insert into actor(name,password) values('ddddd','1234567');
insert into actor(name,password) values('aaaaa','1234567');
mysql> explain select actor_id from actor order by actor_id \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: actor
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 4
Extra: Using index
1 row in set (0.00 sec)
mysql> explain select actor_id from actor order by password \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: actor
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4
Extra: Using filesort
1 row in set (0.00 sec)
mysql> explain select actor_id from actor order by name \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: actor
type: index
possible_keys: NULL
key: name
key_len: 18
ref: NULL
rows: 4
Extra: Using index
1 row in set (0.00 sec)
当MySQL不能使用索引进行排序时，就会利用自己的排序算法(快速排序算法)在内存(sort buffer)中对数据进行排序，如果内存装载不下，它会将磁盘上的数据进行分块，再对各个数据块进行排序，然后将各个块合并成有序的结果集（实际上就是外排序）。对于filesort，MySQL有两种排序算法。
(1)两遍扫描算法(Two passes)
实现方式是先将须要排序的字段和可以直接定位到相关行数据的指针信息取出，然后在设定的内存（通过参数sort_buffer_size设定）中进行排序，完成排序之后再次通过行指针信息取出所需的Columns。
注：该算法是4.1之前采用的算法，它需要两次访问数据，尤其是第二次读取操作会导致大量的随机I/O操作。另一方面，内存开销较小。
(3) 一次扫描算法(single pass)
该算法一次性将所需的Columns全部取出，在内存中排序后直接将结果输出。
注：从 MySQL 4.1 版本开始使用该算法。它减少了I/O的次数，效率较高，但是内存开销也较大。如果我们将并不需要的Columns也取出来，就会极大地浪费排序过程所需要的内存。在 MySQL 4.1 之后的版本中，可以通过设置 max_length_for_sort_data 参数来控制 MySQL 选择第一种排序算法还是第二种。当取出的所有大字段总大小大于 max_length_for_sort_data 的设置时，MySQL 就会选择使用第一种排序算法，反之，则会选择第二种。为了尽可能地提高排序性能，我们自然更希望使用第二种排序算法，所以在 Query 中仅仅取出需要的 Columns 是非常有必要的。
当对连接操作进行排序时，如果ORDER BY仅仅引用第一个表的列，MySQL对该表进行filesort操作，然后进行连接处理，此时，EXPLAIN输出“Using filesort”；否则，MySQL必须将查询的结果集生成一个临时表，在连接完成之后进行filesort操作，此时，EXPLAIN输出“Using temporary;Using filesort”。
3.4、索引与加锁
索引对于InnoDB非常重要，因为它可以让查询锁更少的元组。这点十分重要，因为MySQL 5.0中，InnoDB直到事务提交时才会解锁。有两个方面的原因：首先，即使InnoDB行级锁的开销非常高效，内存开销也较小，但不管怎么样，还是存在开销。其次，对不需要的元组的加锁，会增加锁的开销，降低并发性。
InnoDB仅对需要访问的元组加锁，而索引能够减少InnoDB访问的元组数。但是，只有在存储引擎层过滤掉那些不需要的数据才能达到这种目的。一旦索引不允许InnoDB那样做（即达不到过滤的目的），MySQL服务器只能对InnoDB返回的数据进行WHERE操作，此时，已经无法避免对那些元组加锁了：InnoDB已经锁住那些元组，服务器无法解锁了。
来看个例子：
create table actor(
actor_id int unsigned NOT NULL AUTO_INCREMENT,
name varchar(16) NOT NULL DEFAULT '',
password varchar(16) NOT NULL DEFAULT '',
PRIMARY KEY(actor_id),
KEY (name)
) ENGINE=InnoDB
insert into actor(name,password) values('cat01','1234567');
insert into actor(name,password) values('cat02','1234567');
insert into actor(name,password) values('ddddd','1234567');
insert into actor(name,password) values('aaaaa','1234567');
SET AUTOCOMMIT=0;
BEGIN;
SELECT actor_id FROM actor WHERE actor_id < 4
AND actor_id <> 1 FOR UPDATE;
该查询仅仅返回2---3的数据，实际已经对1---3的数据加上排它锁了。InnoDB锁住元组1是因为MySQL的查询计划仅使用索引进行范围查询（而没有进行过滤操作，WHERE中第二个条件已经无法使用索引了）：
mysql> EXPLAIN SELECT actor_id FROM test.actor
-> WHERE actor_id < 4 AND actor_id <> 1 FOR UPDATE \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: actor
type: index
possible_keys: PRIMARY
key: PRIMARY
key_len: 4
ref: NULL
rows: 4
Extra: Using where; Using index
1 row in set (0.00 sec)
mysql>
表明存储引擎从索引的起始处开始，获取所有的行，直到actor_id<4为假，服务器无法告诉InnoDB去掉元组1。
为了证明row 1已经被锁住，我们另外建一个连接，执行如下操作：
SET AUTOCOMMIT=0;
BEGIN;
SELECT actor_id FROM actor WHERE actor_id = 1 FOR UPDATE;
该查询会被挂起，直到第一个连接的事务提交释放锁时，才会执行（这种行为对于基于语句的复制(statement-based replication)是必要的）。
如上所示，当使用索引时，InnoDB会锁住它不需要的元组。更糟糕的是，如果查询不能使用索引，MySQL会进行全表扫描，并锁住每一个元组，不管是否真正需要。