一、插入数据
1.1、优化方案一（批量插入数据）
Insert into tb_test values(1,'Tom'),(2,'Cat'),(3,'Jerry');1.2、优化方案二（手动控制事务）
start transaction;
insert into tb_test values(1,'Tom'),(2,'Cat'),(3,'Jerry');
insert into tb_test values(4,'Tom'),(5,'Cat'),(6,'Jerry');
insert into tb_test values(7,'Tom'),(8,'Cat'),(9,'Jerry');
commit;1.3、优化方案三（主键顺序插入）
主键乱序插入 : 8 1 9 21 88 2 4 15 89 5 7 3
主键顺序插入 : 1 2 3 4 5 7 8 9 15 21 88 891.4、大批量插入数据
参考系列七的5.2章节
https://blog.csdn.net/HelloWorld20161112/article/details/129245692二、主键优化
主键顺序插入的性能高于乱序插入的原因分析：
2.1、数据组织方式
行数据，都是存储在聚集索引的叶子节点上的。InnoDB的逻辑结构图：
在InnoDB存储引擎中，数据行是记录在逻辑结构 page 页中的，而每一个页的大小是固定的，默认16K。那也就意味着， 一个页中所存储的行也是有限的，如果插入的数据行row在该页存储不小，将会存储到下一个页中，页与页之间会通过指针连接。
2.2、页分裂
2.2.1、主键顺序插入
（1）从磁盘中申请页， 主键顺序插入
（2）第一个页没有满，继续往第一页插入
（3）当第一个也写满之后，再写入第二个页，页与页之间会通过指针连接
（4） 当第二页写满了，再往第三页写入
2.2.2、主键乱序插入
（1）假如1#,2#页都已经写满了，存放了如图所示的数据
（2）此时再插入id为50的记录，看看会发生什么现象?会再次开启一个页，写入新的页中吗？
不会。因为索引结构的叶子节点是有顺序的。按照顺序，应该存储在47之后。
但是47所在的1#页，已经写满了，存储不了50对应的数据了。 那么此时会开辟一个新的页 3#
但是并不会直接将50存入3#页，而是会将1#页后一半的数据，移动到3#页，然后在3#页，插入50。
上述的这种现象，称之为 "页分裂"，是比较耗费性能的操作。
2.2.3、页合并
当我们对已有数据进行删除时，具体的效果如下:
当删除一行记录时，实际上记录并没有被物理删除，只是记录被标记（flaged）为删除并且它
的空间变得允许被其他记录声明使用。
当我们继续删除2#的数据记录：
这里面所发生的合并页的现象称之为 "页合并"。
说明：MERGE_THRESHOLD：合并页的阈值，可以自己设置，在创建表或者创建索引时指定。
2.2.4、索引设计原则
- 满足业务需求的情况下，尽量降低主键的长度；
-
插入数据时，尽量选择顺序插入，选择使用 AUTO_INCREMENT 自增主键；
- 尽量不要使用UUID做主键或者是其他自然主键，如身份证号；
- 业务操作时，避免对主键的修改；
三、order by优化
3.1、准备工作（索引初始化）
删除索引：idx_user_phone、idx_user_phone_name、idx_user_name
drop index idx_user_phone on tb_user;
drop index idx_user_phone_name on tb_user;
drop index idx_user_name on tb_user;
3.2、执行排序
3.2.1、排序的字段没有建立索引
explain select id,age,phone from tb_user order by age ;
explain select id,age,phone from tb_user order by age, phone ; 
结果分析：由于 age, phone 都没有索引，所以排序时，出现Using filesort， 排序性能较低。
3.2.2、排序的字段建立了索引
# 创建索引
create index idx_user_age_phone on tb_user(age,phone);
结果分析：建立索引之后，再次进行排序查询，就由原来的Using filesort， 变为了 Using index，性能就比较高的了。
3.2.3、创建索引后，根据age, phone进行降序排序
结果分析：也出现 Using index， 但是此时Extra中出现了 Backward index scan，表示反向扫描索引，因为在MySQL中我们创建的索引，默认索引的叶子节点是从小到大排序的，而此时我们查询排序时，是从大到小，所以在扫描时，就是反向扫描，就会出现 Backward index scan。 在 MySQL8版本中，支持降序索引，我们也可以创建降序索引。
3.2.4、根据phone，age进行升序排序，phone在前，age在后
结果分析：排序时,也需要满足最左前缀法则,否则也会出现 filesort。因为在创建索引的时候， age是第一个字段，phone是第二个字段，所以排序时，也就该按照这个顺序来，否则就会出现 Using filesort。
3.2.5、根据age, phone进行排序，一个升序，一个降序
explain select id,age,phone from tb_user order by age asc , phone desc;
结果分析：因为创建索引时，如果未指定顺序，默认都是按照升序排序的，而查询时，一个升序，一个降序，此时就会出现Using filesort。
3.2.6、创建联合索引（age升序,phone降序）后再次执行上述SQL
create index idx_user_age_phone_ad on tb_user(age asc ,phone desc);
3.2.7、升序/降序联合结构示意图
3.2.8、order by优化总结
（1）根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则；
（2）尽量使用覆盖索引；
（3）多字段排序, 一个升序一个降序，此时需要注意联合索引在创建时的规则（ASC/DESC）；
（4）如果不可避免的出现filesort，大数据量排序时，可以适当增大排序缓冲区大小sort_buffer_size(默认256k)。
四、group by优化
4.1、索引初始化（删除除主键索引外的其他索引）
drop index idx_user_pro_age_sta on tb_user;
drop index idx_user_pro on tb_user;
drop index idx_email_5 on tb_user;
drop index idx_user_age_phone on tb_user;
drop index idx_user_age_phone_ad on tb_user;
4.2、测试执行计划
4.2.1、按照profession分组
explain select profession , count(*) from tb_user group by profession ; 
4.2.2、创建联合索引后再次执行上述SQL
create index idx_user_pro_age_sta on tb_user(profession , age , status);
4.2.3、依次执行如下SQL
explain select profession , count(*) from tb_user group by profession ;
explain select profession , count(*) from tb_user group by profession,age;
explain select profession , count(*) from tb_user group by profession,age,status;
explain select profession , count(*) from tb_user group by age;
explain select profession , count(*) from tb_user group by status;
结果分析：如果仅仅根据age分组，就会出现 Using temporary ；而如果是根据profession,age两个字段同时分组，则不会出现 Using temporary。原因是因为对于分组操作，在联合索引中，也是符合最左前缀法则的。
4.3、分组优化总结
五、limit优化
5.1、结果分析
通过测试我们会看到，越往后，分页查询效率越低，这就是分页查询的问题所在。 因为当在进行分页查询时，如果执行 limit 2000000,10 ，此时需要MySQL排序前2000010 记录，仅仅返回 2000001 ~ 2000010 的记录，其他记录丢弃，查询排序的代价非常大。
5.2、优化思路
select * from tb_sku t , (select id from tb_sku order by id limit 2000000,10) temp where t.id = temp.id;
六、count优化
6.1、count概述
6.2、count用法
