目录

·插入数据

insert的优化（少量数据）

批量插入

手动事务提交

主键顺序插入

插入大量数据

·主键优化

数据组织方式：

页分裂：

主键顺序插入的方式：

主键乱序插入：

页合并：

主键设计原则：

·order by优化

·group by 优化

·limit优化

优化方式：

·count优化

count的用法：

几种用法的优劣：

count（主键)

count(字段)

count ( 1 )

count (* )

·update优化

---

·插入数据

插入多条数据的优化方案：（插入一条没啥优化的哈）

insert的优化（少量数据）

批量插入

像这种模式，一般建议数据量最多在500-1000条左右。

Insert into tb_test values(1,'To'),(2,'WO'),(3,'jee');

手动事务提交

因为每句insert的执行都会涉及事务的提交，执行的越多越占用时间，为此可以进行手动事务提交，

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;

主键顺序插入

一般而言主键顺序插入还是乱序插入都可以，建议主键顺序插入

乱序：2 5 22 86 34 8987 213

顺序：1 2 3 4 5 6 7 8 9

插入大量数据

一次性插入大量数据，insert的插入性能较低，可以使用MySQL提供的load指令进行插入：

注意，插入的数据需要具有一定的格式

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

mysql --local-infile -u root -p

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

set global local_infile =1;

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

load data local infile '/root/sql1.log' into table `tb_user` fields terminated by ',' lines terminated by '\n';

插入1000000的数据需要16s，如果是使用insert大概需要十几分钟。

·主键优化

数据组织方式：

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

为什么都是根据主键顺序存放的呢：

数据库的数据是根据表空间，段，区，页，行的形式存放的，行就是每一条数据，表是InnoDB管理的最小单位。数据的索引分为聚集索引和二级索引，聚集索引使用的是B+树，它的每个主键都会在树的最下面存放，而前面的向上分裂的部分作为查询数据的索引。所以表的数据都是根据主键顺序组织存放的。

页分裂：

页可以为空，也可以填充一半，也可以填充100%。每个页包含了2-N行数据(如果一行数据过大，会行溢出)，根据主键排列。

主键顺序插入的方式：

就从前往后插数据，第一个页写满了，就写入第二个页，然后用一个双向指针维护两个页的关系。

主键乱序插入：

如果是这种情况，第一个页写满了，但是要插入一个id为50的数据，这个时候怎么办呢？

他会新建一个数据页，然后把第一个页分一半出来，把50插入到新的数据页中

然后把链表指针改变一下，把1号的下一个改为3号，3号的next改为2号。

所以：顺序插入的效率最高。

页合并：

当删除一行记录时，实际上记录并没有被物理删除，只是记录被标记（flaged)为删除并且它的空间变得允许被其他记录声明使用。

当页中删除的记录达到 MERGE_THRESHOLD（默认为页的50%)，InnoDB会开始寻找最靠近的页（前或后）看看是否可以将两个页合并以优化空间使用。

主键设计原则：

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

因为二级索引的最下面存放都是主键，主键太长，就会占用大量的IO和磁盘。

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

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

两个原因：无序且过长

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

·order by优化

在mysql中有两种排序方式

1、Using filesort :通过表的索引或全表扫描，读取满足条件的数据行，然后在排序缓冲区sort buffer中完成排序操作。所有不是通过索引直接返回排序结果的排序都叫FileSort 排序。

2、Using index :通过有序索引顺序扫描直接返回有序数据，这种情况即为using index，不需要额外排序，操作效率高。

所以优化的就需要让排序方式尽量变成Using index。

#没有创建索引时，根据age, phone进行排序
explain select id,age,phone from tb_user order by age , phone;
#创建索引
create index idx_user_age_phone_aa on tb_user(age,phgne);
#创建索引后，根据age, phone进行升序排序
explain select id,age,phone from tb_user order by age , phone;
#创建索引后，根据age, phone进行降序排序
explain select id,age,phone from tb_user order by age desc , phone desc ;

创建了联合

·group by 优化

分组操作的研究中，我们主要研究索引对分组操作的影响。

这是没有索引的查询效率：

下面

是创建索引后的性能：

建立适当的索引，满足最左前缀法则即可提高分组效率。

如果查询时是这样，pro在where，而age在group by也是满足最左前缀法则的。

·limit优化

什么时候要考虑limit进行优化呢：

select * from sb_tu limit 0,10;

第0条数据开始，查10个数据

select * from sb_tu limit 100000,10;

从第100000个数据开始查10个数据。

越往后查询的代价越大，他会把0到100000个数据全部排序，然后丢弃，只返回100000到100010这10个数据。

优化方式：

覆盖索引加子查询

1：先查出想要的id

select id from tb_sku order by id limit 100000,10;

2：表联查查数据

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

原方法耗时19s，优化后耗时11.47s。

·count优化

select count(*) from tb_sku;

MyISAM引擎把一个表的总行数存在了磁盘上，因此执行count(*)的时候会直接返回这个数，效率很高。如果有where条件就需要一行一行的读取了。

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

目前由于存储引擎的缘故，没有太好的优化count的方法，常用的就是使用像redis之类的数据库进行自我计数。

count的用法：

count(*)，count(主键)，count(字段)，count(1)；

count(主键)统计有多少个主键。一般为数据库表的总数。

count(字段)是查询该字段不为空的总数，如果为空则不计入。count(*)同理。

count(1)是给每个字段添加一个1的标识，然后统计1的数量。

几种用法的优劣：

count（主键)

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

count(字段)

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

count ( 1 )

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

count (* )

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

按照效率排序的话，count(字段)<count(主键id)<count(1) = count(*)，所以尽量使用count(*)。

·update优化

我们在更新数据时一定要根据id进行更新，因为在事务中使用id索引进行update用的是行级锁，该行在事务未commit之前不会再被其他人修改。

如果使用字段进行字段进行查询则会被开启表级锁，整张表在该事务未提交之前不会再被修改，会影响其他人操作。

如果字段有建立索引表则不会被添加表级锁，而是行级锁。