[MySQL]SQL优化之sql语句优化

🌈键盘敲烂，年薪30万🌈

目录

一、索引优化 回顾：

📕索引分类：

📕索引失效：

📕设计原则：

📕SQL性能分析

二、SQL优化 语句优化

📕 insert语句：

📕 主键优化：

📕 order by优化：

📕 group by优化：

📕 limit 优化

📕 count 优化

📕 update 优化?

---

一、索引优化 回顾：

📕索引分类：

• 一般分类：主键索引、唯一索引、常规索引、全文索引
• 按存储分类：聚集索引、二级索引

注意：

主键索引只能有一个且必须有一个，二级索引可以有多个，如果没有主键，选唯一索引作为主键索引，如果没有唯一索引，那么mysql会创建一个隐藏字段rowid作为索引。

?

📕索引失效：

• 不满足最左前缀法则
• 索引列计算
• 字符串类型不加'' 导致类型转化
• 使用or连接了非索引的列
• %在最左边，>或<号
• 数据分布影响

📕设计原则：

? ? 尽量建立联合索引，针对于数据量大(超百万)，查询多的表建索引，针对于where order by group by后的字段创建索引，如果字段很长，考虑前缀索引，如果索引列不能为NULL，须在数据库字段加上not null约束，这样优化器可以更好的选择更有效的索引。

📕SQL性能分析

1. 执行频次
2. 慢查询日志
3. profile
4. expplain执行计划?

---

二、SQL优化 语句优化

📕 insert语句：

批量插入优化：

• 一次性插入多条数据，但是不建议超过1000条。

insert into user values(1, 'zhangsan'), (2,'lisi');

手动提交事务优化：

• 超过1000条，手动开启提交事务，减少与数据库的交互。

start transaction

insert into user values(1, 'zhagnsan'), (2, 'lisi'), ……
insert into user values(1000, 'wangwu'), (1001, 'zhaoliu') ……
……

commit

主键顺序插入优化：

大批量插入数据优化：

• load：插入百万数据到数据库

• load使用三步走：

1.连接数据库时加上：

--local-infile

2.打开全局参数：

set global local infile = 1;

3.插入数据的脚本：

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

📕 主键优化：

前面提到了主键按顺序插入可提高性能，这里讲解原理。

（这里我不是很明白，摘自GPT的回答）

页分裂：

• 当在一个已满的页（节点）中插入一个新的键时，可能会导致该页不足以容纳新键，因此需要进行页分裂。
• 页分裂的过程涉及将原有的页分成两半，并将其中一半的部分移动到一个新的页中。这样就在原有页和新页之间创建了一个新的分隔键，用于指示两个页之间的分割。
• 页分裂的目的是确保树的平衡，并维护索引的有序性。它通常发生在B树或B+树中。

页合并：

• 与页分裂相反，页合并发生在删除操作后。当一个页的键减少到一个临界点以下时，可以考虑将其与相邻的页合并，从而减少索引树的高度。
• 页合并的过程涉及将两个相邻的页合并成一个，并且删除在合并过程中用于分隔的键。这有助于保持树的平衡，并且减少了树的高度，提高了检索效率。
• 页合并通常也发生在B树或B+树这样的平衡树结构中。

小结：

? ? 索引的设计原则：长度尽量短，尽量有序插入。

---

📕 order by优化：

优化准则：

• 如果创建索引的排序规则和要查询语句的排序规则相同，那么直接返回数据，效率高，如果不同，需要在缓冲区对相应的字段进行排序，效率不高。

注意：

创建索引默认是升序排序，asc

创建索引是指定排序规则

create index id_na_ty on tb_book(name asc, type asc);

例如：

一张tb_book表的索引

• 执行语句1（升序排序查询）：

select id, name, type from tb_book order by name asc, type asc;

-- 直接返回索引下面挂的数据，效率高

查看执行过程：

• ?执行语句2（name 升序 type 降序）

select id, name, type from tb_book order by name asc, type desc;

-- 会在缓冲区进行排序，效率不高。

查看执行过程：

小总结：

order by 查询的字段要与建立索引时字段的排序规则相同，若不同，会在缓冲区排序然后返回数据，可以在创建索引时指定排序规则

📕 group by优化：

跟order by类似，建立好相应的索引，并且保证索引正确的使用规则，比如最左前缀法则。

📕 limit 优化

记住：覆盖索引加子查询：

原理：原本要对数据进行排序，在挑选50条数据，现在使用索引覆盖 + 子查询 先根据id排序，排完之后直接子查询就可以啦。

select * from user where limit 10000, 50;
-- 回表查询性能低

select t.* from user t, (select if from user where order by id limit 10000, 50) s where t.id = s.id;
-- 覆盖索引 + 子查询 性能略好

📕 count 优化

count统计非空字段数量，count无法优化，但是我们要区分count()括号里的字段的含义

1. count(*)：不取值，直接累加。
2. count(主键)：取出主键id，累加
3. count(某个字段:有非空约束)：取值，返回给服务层，服务层直接累加
4. coutn(某个字段：无非空约束)：取值，返回给服务层，服务层判断后累加。
5. count(1)：每行放一个1 并且累加，只要不是null都可以累加

小结：

尽量使用count(*)

📕 update 优化?

• 更新的条件一定要有索引，否则行锁会标为表锁。

例如：user表 name字段带有索引

一个客户端执行：update user set name = 'Zhangsan' where name = 'Lisi';

一个客户端执行：update user set name = 'wangwu' where name = 'zhaoliu';

分析：

此时可以并发执行，因为索引对应的是行级锁，不会锁整张表，相反如果没有索引，或者索引失效，行级锁就会变为表锁，无法高并发。