MySQL调优（四）：MySQL索引优化实现细节

查询优化

在编写快速的查询之前，需要清楚一点，真正重要的是响应时间，而且要知道在整个SQL语句的执行过程中每个步骤都花费了多长时间，要知道哪些步骤是拖垮执行效率的关键步骤，想要做到这点，必须要知道查询的生命周期，然后进行优化，不同的应用场景有不同的优化方式，不要一概而论，具体情况具体分析。

可以看执行时间（由于数据量比较小，所以差别不是很明显）

create table user(id int,name varchar(10),phone varchar(11));alter table user add index idx_1(phone);

Join

A join B，一定是先找A，后找B吗？
不一定。MySQL会进行优化。但可以进行constraint_join制定，强制先后顺序。
小表Join大表这样比较好，A是外键，B是主键索引，A是驱动表，B是非驱动表。

将小表放进内存的 join buffer 缓冲区中
可以把默认的join_buffer_size=256K调大，根据你的硬件决定。

两个语句比较

返回结果一样
执行计划，看起来是一模一样的，没啥区别
执行时间也差不多

on的条件不参与join的运算

其他的一些优化点

# 索引优化分析案例

预先准备好数据

SET FOREIGN_KEY_CHECKS=0;
DROP TABLE IF EXISTS `itdragon_order_list`;
CREATE TABLE `itdragon_order_list` (`id` bigint(11) NOT NULL AUTO_INCREMENT COMMENT '主键id，默认自增长',`transaction_id` varchar(150) DEFAULT NULL COMMENT '交易号',`gross` double DEFAULT NULL COMMENT '毛收入(RMB)',`net` double DEFAULT NULL COMMENT '净收入(RMB)',`stock_id` int(11) DEFAULT NULL COMMENT '发货仓库',`order_status` int(11) DEFAULT NULL COMMENT '订单状态',`descript` varchar(255) DEFAULT NULL COMMENT '客服备注',`finance_descript` varchar(255) DEFAULT NULL COMMENT '财务备注',`create_type` varchar(100) DEFAULT NULL COMMENT '创建类型',`order_level` int(11) DEFAULT NULL COMMENT '订单级别',`input_user` varchar(20) DEFAULT NULL COMMENT '录入人',`input_date` varchar(20) DEFAULT NULL COMMENT '录入时间',PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=10003 DEFAULT CHARSET=utf8;INSERT INTO itdragon_order_list VALUES ('10000', '81X97310V32236260E', '6.6', '6.13', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '2017-08-28 17:01:49');
INSERT INTO itdragon_order_list VALUES ('10001', '61525478BB371361Q', '18.88', '18.79', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '2017-08-18 17:01:50');
INSERT INTO itdragon_order_list VALUES ('10002', '5RT64180WE555861V', '20.18', '20.17', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '2017-09-08 17:01:49');

逐步开始进行优化：

第一个案例：

select * from itdragon_order_list where transaction_id = "81X97310V32236260E";
--通过查看执行计划发现type=all,需要进行全表扫描
explain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";--优化一、为transaction_id创建唯一索引create unique index idx_order_transaID on itdragon_order_list (transaction_id);
--当创建索引之后，唯一索引对应的type是const，通过索引一次就可以找到结果，普通索引对应的type是ref，表示非唯一性索引赛秒，找到值还要进行扫描，直到将索引文件扫描完为止，显而易见，const的性能要高于refexplain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";--优化二、使用覆盖索引，查询的结果变成 transaction_id,当extra出现using index,表示使用了覆盖索引explain select transaction_id from itdragon_order_list where transaction_id = "81X97310V32236260E";

第二个案例

--创建复合索引
create index idx_order_levelDate on itdragon_order_list (order_level,input_date);--创建索引之后发现跟没有创建索引一样，都是全表扫描，都是文件排序
explain select * from itdragon_order_list order by order_level,input_date;--可以使用force index强制指定索引
explain select * from itdragon_order_list force index(idx_order_levelDate) order by order_level,input_date;
--其实给订单排序意义不大，给订单级别添加索引意义也不大，因此可以先确定order_level的值，然后再给input_date排序
explain select * from itdragon_order_list where order_level=3 order by input_date;

索引优化分析案例