插入数据优化,
insert 优化,
批量插入(一次不超过1000条)
手动提交事务
主键顺序插入

load 从本地一次插入大批量数据,
登陆时 mysql --local-infile -u root -p
load data local infile '/root/sql1.log' into table 'tb_user' fields terminated by ',' lines terminated by '\n';
从 '/root/sql1.log' 文件中,读取加载数据,加载数据到 tb_user 这个表,每个字段用 逗号分隔,每一行用 换行回车 分隔。

通过 select @@loacl_infile;查看是否打开可以批量插入数据的变量,
如果没有打开,则通过 set loacl_infile = 1; 打开该变量


主键优化,
我们看到 mysql innodb 中的 表数据 都是 根据主键顺序组织存放的。


page 是 innoDB的最小管理。
在主键顺序插入时,页中数据的形式

页分裂 - 在主键 乱序 插入时,页中数据可能会引起 页分裂


页合并
原始数据

依次删除 16,15,14,13 时


主键设计原则
主键长度 太长,辅助索引浪费更多的空间。
尽量顺序插入,选择使用 auto_incrment 避免 页分裂。

order by优化,
说白了,就是我们在 查询到数据后,在排序的时候使用order by 后面的字段 也是需要有 索引的。
如果排序后面的字段有索引,那么 explain select 执行后,extra 后面会提示 using index,表明我们的排序是使用的 索引完成的。
如果排序后面的字段没有索引,则extra后面的提示是 using filesort,表明排序没有使用索引。

测试,发现 extra 后面说明的 using index

创建age 和phone 的联合索引, 默认情况下 age和phone 都会按照 升序 排序。
如果我们像要让 age 按照 升序排序,让 phone 按照降序排序,则,按照如下的写法。




默认排序缓冲大小的值,在 变量 sort_buffer_size中存储。如果查询到的数据量就是很大,256k已经不够用了,默认mysql 就会在磁盘文件中开辟空间,I/O就会很慢。因此我们可以 改动 sort_buffer_size的大小,避免在 磁盘文件中开辟空间。
group by 优化,




limit 优化,

count 优化,
简单来说,count 优化是要自己计数的。
如果不优化,就使用count(*)计数,这个效率是最高的。


由于 id =24 没有专业,因此 select count(prefession) from tb_user的值是23
也就是说,如果按照字段计数,如果该字段为null,则不会计数。


update 优化
这是啥意思呢? 我们假设 student 表有3条记录
id name no
1 张三丰 2000100100
2 韦一笑 2000100105
3 度小满 2000100106
索引 只有 primary key = id,
我们有两个并行的事务,
一个按照id 更新 no,一个按照 name 更新 no
由于id 是有索引的,因此只会 锁定 id =1 的这一行,
但是name没有索引,会锁定 整张表,
也就是下面说的,innoDB的韩所是针对索引加的锁。
如果没有索引,会变成整张表的 锁。
应尽量避免将 整张表的锁。
这会让并行效率变的很低。
