1、优化insert操作

        批量插入，防止大量与数据库进行访问

        手动控制事务，减少事务的频繁开启和提交。

        

        主键顺序插入

2、优化主键

        主键优化的点就是避免主键过长，因为如果有二级索引，叶子节点存储的数据时间上是主键，如果主键太长会造成存储压力过大。主键最好设置插入是自增的，避免乱序插入，如果乱序插入会造成也分裂现象严重消耗性能。

        1.页分裂现象

                 索引的叶子节点是按照索引的顺序进行排序的，如果乱序插入就会出现页分类现象这样会比较消耗性能。                   此时需要插入在47后面，但是47后面页空间不足了，就会出现页分裂现象，它会先开启一个新的页，然后把第一个页一半以上的部分数据移动到新的页里，也就是23,47这两条数据，然后将50插入47后面，最后再调整页的前后顺序。       

                这是调换之后的顺序，红箭头指示是调换之前的顺序。

        2.页合并现象

                当一个页删除的数据大于一半了，相邻页如果可以的话就会进行合并

                

                合并后

3、优化order by排序操作

        这个是通过EXPLAIN在查询前可以看到查询计划里的Extra部分里的提示，大概意思就是说如果出现Using index就是不需要全表扫描的情况。

       尽量使用覆盖索引，比如order by后面的一个字段，查出来的数据最多是id和这个字段，因为建立了这样的索引，所以第一次根据索引查，它的键就是字段，存的值就是id，一次性就能查出所需值。如果查询的值再多或者使用select * from 会进行回表查询，因为有许多数据不包含在这个索引内，此时条件允许可以设置对应值的联合索引。如果不非得直接查，除非通过id主键进行order by；

        所以order by后面的最好使用索引，这样就不会全表扫描而是走索引，但是这里有一点要说就是如果用的是联合索引的时候，不要违背最左前缀法则，对于where后的索引它是与书写顺序无关的，如果索引是ABC，写的时候ABC BCA CBA AB BA 这种都可以，但是order by就不一样了，它与书写顺序就有关了，它必须是ABC AB这种，并且如果排序升序与降序也要和当初创建的索引一致，默认索引排序是ASC，所以如果使用的话要提前考虑是否要设置对应的索引排序类型是ASC 还是DESC。

4、group by分组优化

        它优化起来也和order by 优化相似，在后面的自动加索引，并且遵循最左前缀法则，而且对书写顺序有关。

5、limit 优化

         用覆盖索引+子查询的方法，如果不支持子查询可以把索引覆盖查出的数据看做一张表进行条件查询。这样就可以降低一次性查出limit x,y中前x中的所有数据只查出一个id，然后通过id进行查询对应的数据，然后用或者在业务上记录下每次查的页数，如果查下一页就大于之前的页数，然后offset设置一个偏移页数，可以是一整页的数据，但是必须数据是自增的。

6、count优化

        有这么几种count(id),count(字段),count(1),count(*)        

        count(id) 将所有id拿出来计算，不用去判断是否为null，主键唯一且不为空

        count(字段)如果没有加not null 那么需要每次进行判断是否为null 然后取出来直接累加

        count(1)会遍历整张表，但不取值。服务层对每一行放进去一个1然后进行累加只要不为空。

        count(*) 有专门的优化不进行取值，直接累加。

        执行速度，后面两个快是因为他们不取值直接累加。

        count(字段)<count(id)<count(1)<count(*)  

7、update优化

        InnoDB引擎的三大特点就是 外键 事务 行级锁

        在默认的隔离级别的时候更新数据使用的是行锁，前提是使用的主键锁数据，但如果用非主键锁，那么此时会升级成表锁。为了让并发情况下更好，避免升级成表锁导致更新阻塞。