生成测试数据:
创建表用于测试:
/*创建t_user表用于数据测试*/
DROP TABLE IF EXISTS t_user;
CREATE TABLE `t_user` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`name` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
`address` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
`phone` varchar(20) COLLATE utf8_unicode_ci DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=13997 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
创建随机字符串函数:
/*创建rand_string方法自动生成随机字符串*/
DROP FUNCTION IF EXISTS rand_string;
DELIMITER $$
CREATE FUNCTION rand_string(n INT) RETURNS VARCHAR(255)
BEGIN
DECLARE chars_str VARCHAR(100) DEFAULT 'abcdefghijklmnopqrstuvwxyzABCDEFGHIGKLMNOPQRSTUVWXYZ';
DECLARE return_str VARCHAR(255) DEFAULT '';
DECLARE i INT DEFAULT 0;
WHILE i<n DO
SET return_str =CONCAT(return_str,SUBSTRING(chars_str,FLOOR(1+RAND()*52),1));
SET i=i+1;
END WHILE;
RETURN return_str;
END
$$
创建存储过程:
/*创建create_data存储过程，自动生成100万的随机数据*/
DROP PROCEDURE IF EXISTS create_data;
DELIMITER $$
CREATE PROCEDURE create_data()
BEGIN
DECLARE i INT;
SET i=1;
WHILE i<1000001 DO
INSERT INTO t_user (NAME,address,phone,age)
VALUES(rand_string(10),rand_string(10),rand_string(10),i);
SET i=i+1;
END WHILE;
END
$$
调用存储过程,生成数据:
/*查询t_user总数据量*/
SELECT COUNT(*) FROM t_user;
索引性能验证:
1.无索引列的查询
在where条件当中没有添加索引的列,性能会比较差,比如查询
/*无索引列的查询，索引不会命中*/
SELECT * FROM t_user WHERE NAME = 'ZYWMUoLMAu';
就需要耗时0.4s左右
2.主键列查询(主键值是默认的唯一索引值)
/*主键列查询，索引会命中*/
SELECT * FROM t_user WHERE id = 1;
按照索引进行查询SQL执行时间大约为1ms,比较上面的来说性能提升很大
3.在name上面添加索引值
/*添加NAME列上的索引*/
ALTER TABLE `t_user` ADD INDEX index_name ( `name` ) ;
随着数据量的增加,索引创建时间会增长,在添加完索引之后在进行SQL查询,之后的性能较没有索引之前提升很多,并且执行时间大约为10ms
4.范围查询的索引效果
age上面没有索引,在age列上面进行范围查询,执行SQL耗时0.4s,性能较差,当在age上面加上索引之后在进行测试,执行时间为10ms,这说明对其范围查询已经生效
5.排序的索引效果
我们在address列上进行排序查询，测试性能，限制查询数据量为100。
/*在address列上没有索引，索引不会命中*/
SELECT*FROMt_userORDERBYaddressDESCLIMIT100;
上面的SQL执行时间大约在1秒左右，性能较差。
在age列上添加BTREE索引,再进行测试。
/*在address列上有索引，索引会命中*/
ALTERTABLE`t_user`ADDINDEXindex_address (`address`) ;
上面的SQL执行时间大约在30毫秒左右，这说明address列上索引对于排序查询来说已经生效。
总结:
mysql在进行查询的时候如果加上索引,在对数据库进行查询的时候在性能上会提升很多.
高性能索引策略:
1.独立的列
如果查询中的列不是独立的，则Mysql就不会使用索引。独立的含义是指索引列不能是表达式的一部分，也不能是函数的参数。
/*使用了表达式，不是独立的列，不会命中索引*/
SELECT*FROMt_userWHEREid +0=1;
上面的SQL等价于id = 1但是Mysql的索引就会因此失效，执行时间大约在0.4秒左右。
2.like查询开头不能以%开头
如果查询中包含like查询以%为开头，则索引会失效。
/*LIKE查询以%为开头，不会命中索引*/
SELECT * FROM t_user WHERE NAME LIKE '%ZYWMU%';
上面的SQL语句执行时间在0.5秒左右，然后我们将开头的%去掉，进行测试。
/*LIKE查询不以%为开头，会命中索引*/
SELECT*FROMt_userWHERENAMELIKE'ZYWMU%';
当like查询不以%为开头之后，查询时间在0.02秒，证明索引已经命中，性能得到非常大的提升。
3.列类型是字符串,一定要在条件中将数据使用引号引用起来
尝试以下SQL，在name列有索引的情况下
/*在name列有索引，字符串未用引号引用，不会命中索引*/
SELECT*FROMt_userWHERENAME =123;
未查找到数据，执行时间0.6秒，如果我们将数据使用引号引用
/*在name列有索引，字符串用引号引用，会命中索引*/
SELECT*FROMt_userWHERENAME ='123';
未查找到数据，执行时间0.01秒，证明索引已经命中。
4.最左匹配原则
在mysql建立联合索引时会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配，删除所有索引，对列name、列address和列phone建一个联合索引
ALTERTABLE`t_user`ADDINDEXindex_combile (`name`,`address`,`phone`);
联合索引index_combile实际建立了(name)、(name,address)、(name,address,phone)三个索引。所以下面的三个SQL语句都可以命中索引。
SELECT*FROMt_userWHEREaddress ='KPSTOrpBMf'ANDphone ='pjZvejKYKF'ANDNAME ='myGKHeCwAm'
SELECT*FROMt_userWHERENAME ='myGKHeCwAm'ANDaddress ='KPSTOrpBMf'
SELECT*FROMt_userWHERENAME ='myGKHeCwAm';
上面三个查询语句执行时会依照最左前缀匹配原则，检索时分别会使用索引
(name,address,phone)
(name,address)
(name)
进行数据匹配。
索引的字段可以是任意顺序的，如：
/*优化器会帮助我们调整顺序，下面的SQL语句都可以命中索引*/
SELECT*FROMt_userWHEREaddress ='KPSTOrpBMf'ANDphone ='pjZvejKYKF'ANDNAME ='myGKHeCwAm';
Mysql的优化器会帮助我们调整where条件中的顺序，以匹配我们建立的索引。
联合索引中最左边的列不包含在条件查询中，所以根据上面的原则，下面的SQL语句就不会命中索引。
/*联合索引中最左边的列不包含在条件查询中，下面的SQL语句就不会命中索引*/
SELECT * FROM t_user WHERE address = 'KPSTOrpBMf' AND phone = 'pjZvejKYKF';
拓展:
使用explain语句先去查询,看一下sql的执行效率,索引是否被命中等
语句有:
explain SELECT * FROM t_user WHERE address = 'KPSTOrpBMf' AND phone = 'pjZvejKYKF' AND NAME = 'myGKHeCwAm';
显示结果如下：
idselect_typetablepartitionstypepossible_keyskeykey_lenrefrowsfilteredExtra
1SIMPLEt_user(NULL)ALL(NULL)(NULL)(NULL)(NULL)9960861.00Using where
EXPLAIN列的解释：
table：显示这一行的数据是关于哪张表的
type：这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL
possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句
key： 实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MYSQL会选择优化不足的索引。这种情况下，可以在SELECT语句中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引
key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好
ref：显示索引的哪一列被使用了，如果可能的话，是一个常数
rows：MYSQL认为必须检查的用来返回请求数据的行数
Extra：关于MYSQL如何解析查询的额外信息。
type
以下排序从上到下，性能由坏到好。
a.ALL：Full Table Scan， MySQL将遍历全表以找到匹配的行
b.index：Full Index Scan，index与ALL区别为index类型只遍历索引树
c.range：索引范围扫描，对索引的扫描开始于某一点，返回匹配值域的行，常见于between、<、>等的查询
d.ref：非唯一性索引扫描，返回匹配某个单独值的所有行。常见于使用非唯一索引即唯一索引的非唯一前缀进行的查找
e.eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描
f.const、system：当MySQL对查询某部分进行优化，并转换为一个常量时，使用这些类型访问。如将主键置于where列表中，MySQL就能将该查询转换为一个常量
g.NULL：MySQL在优化过程中分解语句，执行时甚至不用访问表或索引
所以由type可以进行分析，如果是ref、eq_ref那么索引命中且性能较好。
