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

您的位置：上海毫米网络优化公司 > 小程序 > 百度小程序 >

一、索引优化回顾：

📕索引分类：

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

注意：

主键索引只能有一个且必须有一个，二级索引可以有多个，如果没有主键，选唯一索引作为主键索引，如果没有唯一索引，那么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()括号里的字段的含义
        
        count(*)：不取值，直接累加。
        count(主键)：取出主键id，累加
        count(某个字段:有非空约束)：取值，返回给服务层，服务层直接累加
        coutn(某个字段：无非空约束)：取值，返回给服务层，服务层判断后累加。
        count(1)：每行放一个1 并且累加，只要不是null都可以累加
        
        小结：
        
        尽量使用count(*)
        
        📕 update 优化
        
        更新的条件一定要有索引，否则行锁会标为表锁。
        例如：user表 name字段带有索引
        
        一个客户端执行：update user set name = 'Zhangsan' where name = 'Lisi';
        
        一个客户端执行：update user set name = 'wangwu' where name = 'zhaoliu';
        
        分析：
        
        此时可以并发执行，因为索引对应的是行级锁，不会锁整张表，相反如果没有索引，或者索引失效，行级锁就会变为表锁，无法高并发。