目录

1插入数据

1.1 insert

1.2大批量插入数据

2主键优化

3 order by 优化

4 group by 优化

5 limit 优化

6 count 优化

6.1概述

6.2 count用法

7 update优化

1插入数据

1.1 insert

优化方案主要有3种

批量插入数据

Insert into tb_test values(1,'Tom'),(2,'Cat'),(3,'Jerry');

手动控制事务

主键顺序插入，性能要高于乱序插入

1.2大批量插入数据

如果一次性需要插入大批量数据(比如: 几百万的记录)，使用insert语句插入性能较低，此时可以使 用MySQL数据库提供的load指令进行插入。具体操作如下：

（1）客户端连接服务端时，加上参数 --local-infile

mysql --local-infile -u root -p

（2）设置全局参数local_infile为1或on，开启从本地加载文件导入数据的开关

 set global local_infile = 1;

（3）在finalshell底栏上传数据到sql文件夹，然后可以进行查看

wc -l tb_sku1.sql;  #看看数据有多少行，-L是不定

head tb_sku1.sql;  #看看数据的前10行

（4）执行load指令将准备好的数据，加载到表结构中：

load data local infile '/root/sql/tb_sku1.sql' into table `tb_sku` fields terminated by ',' lines terminated by '\n';

每个字段逗号,分隔，每行数据\n分隔。

2主键优化

（1）数据组织方式

在InnoDB存储引擎中，表数据都是根据主键顺序组织存放的，这种存储方式的表称为索引组织表。

（2）主键乱序插入时，会出现页分裂的现象，比较耗性能

（3）页合并：当删除一行记录时，实际上记录并没有被物理删除，只是记录被标记（flaged）为删除并且它的空间变得允许被其他记录声明使用。当页中删除的记录达到 MERGE_THRESHOLD（默认为页的50%），InnoDB会开始寻找最靠近的页（前 或后）看看是否可以将两个页合并以优化空间使用。

（4）主键索引的设计原则

1）满足业务需求的情况下，尽量降低主键的长度。

太长会占用磁盘空间，在搜索查询时会占用磁盘IO，

2）插入数据时，尽量选择顺序插入，选择使用AUTO_INCREMENT自增主键。

乱序插入可能会出现页分裂现象，耗费性能。

3）尽量不要使用UUID做主键或者是其他自然主键，如身份证号。

UUID是无序的，且很长

4）业务操作时，避免对主键的修改。

3 order by 优化

MySQL的排序，有两种方式：

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

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

案例：

（1）将tb_user2这个表的索引删减到这些。

（2）现在按照age和phone排序，都是使用Using filesort进行排序的，因为这两个字段都没有索引。

（3）创建联合索引(age,phone)

create index idx_user_age_phone on tb_user2(age,phone);

升序联合索引结构图示:

（4）现在再来排序查询

联合索引是age为第一个字段，上面两个先按照age排序，都是按照Using index的方式，但是下面两个出现了Using filesort，是因为违背了最左前缀法则。

（5）反向扫描

在B-Tree中的叶子节点，按照age升序，如果age相同，再按照phone升序（创建索引不指定时默认升序）。这里都要倒序，就需要反向扫描。

（6）一升一降

因为创建索引没有指定排序，就默认是升序，这里phone要降序，就需要额外的排序。

（7）创建索引指定排序方向（优化！！！）

create index idx_user_age_phone_ad on tb_user2(age asc,phone desc);

（8）这时候再一升一降就是按照索引了，没有额外的了

order by优化原则:

A. 根据排序字段建立合适的索引，多字段排序时，也遵循最左前缀法则。

B. 尽量使用覆盖索引（不要使用select *，尽量不要造成回表查询）。

C. 多字段排序, 一个升序一个降序，此时需要注意联合索引在创建时的规则（ASC/DESC）。

D. 如果不可避免的出现filesort，大数据量排序时，可以适当增大排序缓冲区大小

sort_buffer_size(默认256k)。

修改缓冲区大小的代码：

show variables like 'sort_buffer_size';

set sort_buffer_size=262145;

4 group by 优化

（1）删掉除开主键以外的索引

drop index idx_user_email_5 on tb_user2;

（2）没有索引时，执行分组操作

分组就不要select*，没有任何意义，查询sql执行发现用到了临时表Using temporary 。

（3）创建索引再查询——尽量创建联合索引(profession,age,status)

create index idx_user_pro_age_sta on tb_user2(profession,age,status);

发现查询profession,age都是利用的索引

（4）遵守最左前缀法则

当跳过第一个字段profession，直接用age

explain select age,count(*) from tb_user2 group by age;

但是profession不一定要在group by后面，只要出现了就行。

5 limit 优化

在数据量比较大时，如果进行limit分页查询，在查询时，越往后，分页查询效率越低。

因为，当在进行分页查询时，如果执行 limit 1000000,10 ，此时需要MySQL排序前1000010 记 录，仅仅返回 1000000 - 1000010 的记录，其他记录丢弃，查询排序的代价非常大 。

SQL代码：select * from tb_sku limit 1000000,10;

优化方法：覆盖索引+子查询

In后面不能用到limit这样的关键字，不支持这种语法。

错误SQL：select * from tb_sku where id in(select * from tb_sku limit 1000000,10);

正确SQL代码：

select s.* from tb_sku s,(select * from tb_sku limit 1000000,10) a where s.id=a.id;

6 count 优化

6.1概述

如果数据量很大，在执行count操作时，是非常耗时的（默认是InnoDB 引擎）。

（1）MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count(*) 的时候会直接返回这个 数，效率很高； 但是如果是带条件的count，MyISAM也慢。

（2）InnoDB 引擎就麻烦了，它执行 count(*) 的时候，需要把数据一行一行地从引擎里面读出 来，然后累积计数。

6.2 count用法

count() 是一个聚合函数，对于返回的结果集，一行行地判断，如果 count 函数的参数不是 NULL，累计值就加 1，否则不加，最后返回累计值。

count用法：count（*）、count（主键）、count（字段）、count（数字）

（1）count(主键) InnoDB 引擎会遍历整张表，把每一行的 主键id 值都取出来，返回给服务层。 服务层拿到主键后，直接按行进行累加(主键不可能为null)

（2）count(字段) 没有not null 约束 : InnoDB 引擎会遍历整张表把每一行的字段值都取出 来，返回给服务层，服务层判断是否为null，不为null，计数累加。 有not null 约束：InnoDB 引擎会遍历整张表把每一行的字段值都取出来，返 回给服务层，直接按行进行累加。

（3）count(数字) InnoDB 引擎遍历整张表，但不取值。服务层对于返回的每一行，放一个数字“1” 进去，直接按行进行累加。

（4）count(*) InnoDB引擎并不会把全部字段取出来，而是专门做了优化，不取值，服务层直接 按行进行累加。

按照效率排序的话，count(字段) < count(主键 id) < count(1) ≈ count(*)，

所以尽量使用 count(*)。

7 update优化

优化：更新字段时最好根据索引字段更新（InnoDB 引擎默认是行锁。）

如果更新索引字段，则事务执行时只会锁住这一行，如事务1锁住id=4的行，不会影响id=1的行操作。update course set name = 'C++' where id = 1;

如果不是用索引字段，则会将整个表锁住。

如下事务1用的非索引字段name，在未提交前将整个表都锁住了，事务2就只能等待。

事务2在事务1提交完之后才能执行。

InnoDB的行锁是针对索引加的锁，不是针对记录加的锁 ,并且该索引不能失效，否则会从行锁升级为表锁。表锁状态并发性会降低。