SQL优化

插入数据

如果我们需要一次性往数据库表中插入多条记录，可以从以下三个方面进行优化
1、批量插入数据
2、手动提交事务
3、主键顺序插入

如果一次性插入大批量数据，使用insert性能较低，可以使用load指令进行插入

主键优化

主键顺序插入效果：第一页没有满则继续插入，第一页满后，再写入第二页，依次插入，如果当中插入一个中间的数值，会有页分裂现象
			  ，开辟一个新的页，取前一页的中间部分放入新的页中，比较浪费性能。
当删除一行记录时，并没有被物理删除，只是被标记成删除，但是它的空间允许被其他记录使用，当删除的记录达到页的50%，开始寻找最靠近的页，
进行页合并优化空间

1、满足业务需求的情况下，尽量降低主键的长度
2、插入数据时，尽量选择顺序插入，使用自增主键
3、业务操作时，避免对主键的修改

order by优化

mysql的排序，有两种方式：
Using filesort ： 通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓冲区sort buffer中完成排序操作，
				  所以不是通过索引直接返回排序结果的排序都叫filesort排序
Using index ：通过有序索引顺序扫描直接返回有序数据，这种情况即为using index，不需要额外排序，操作效率高

对于以上的两种排序，Using index的性能高，而Using filesort的性能低，我们在优化排序操作时，尽量要优化成Using index				  

1、根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则
2、尽量使用覆盖索引
3、多字段排序，一个升序一个降序，此时需要注意联合索引在创建时的规则（ASC/DESC）
4、如果避免出现filesort，大数据量排序时，可以适当增加排序缓冲区大小 sort_buffer_size(默认256k)

group by优化

1、在分组操作时，可以通过索引来提高效率
2、分组操作时，索引的使用也满足最左前缀法则

limit优化

在数据量比较大时，如果进行limit分页查询，在查询时，越往后，分页查询效率越低
优化思路：
	一般分页查询时，通过创建覆盖索引能够比较好的提升性能，可以通过覆盖索引加子查询进行优化
	explain select * from tb_sku t , (select id from tb_sku order by id limit 200000,10) a where t.id = a.id;

count优化

数据量很大时，在执行count操作是非常耗时的
MyISAM引擎把表的总行数存放在磁盘上，直接返回，所以效率很高
Innodb需要把一行一行的读出来，然后累加技术
如果想要优化count，可以自己计数（借助于redis数据库进行，但是如果是带条件的count又比较麻烦）

count(*)：Innodb引擎并不会把全部字段取出来，而是做了专门优化，不取值，服务层之间按行进行累加
count(主键)：Innodb引擎会遍历整张表，把每一行的主键id都取出来，返回服务层。
			服务层拿到主键后，直接进行累加（主键不可能为null）
count(字段)：如果没有no null约束，也就是可以运行null值，Innodb引擎会遍历整张表把每一行的字段值取出来，
				返回给服务层，服务层判断是否为null，不为null，计数累加
			如果有no null约束，innodb引擎遍历整张表把每一行的字段值取出来，返回服务层，直接按行计数累加
count(数字)：Innodb引擎遍历整张表，但不取值。服务层对于返回的每一行，放一个数字“1”进去，直接按行进行累加

按照效率排序的话：count(*) ~ count(1) > count(主键id) > count(字段)						

update优化

update course set name = 'javaEE' where id = 1 ;
当我们在执行这样的SQL语句的时候，会锁定id为1的这一行的数据，然后事务提交之后，行锁释放

但是我们在执行下面SQL时
update course set name = 'SpringBoot' where name = 'PHP' ;
我们开启多个事务，在执行上述SQL，发现行锁升级为了表锁。导致该update语句的性能大大降低


Innodb的行锁是针对索引加的锁，不是针对记录加的锁，并且该索引不能失效，否则会从行锁升级为表锁