Mysql sql优化

Posted 2023-04-06 Blurred me

这里引用深入mysql实战

为什么要优化

1. 提高资源利用率
2. 避免短板效应
3. 提高系统吞吐量
4. 同时满足更多用户的在线需求

简单来说，优化的目的是为了提高资源的利用率，让资源充分发挥价值。常见场景下，一台服务器有四大资源：cup、内存网络和磁盘，一旦其中某个资源出现问题，整个服务器提供服务的能力就会变差，优化的最终目的是为了同时满足更多用户的的在线需求

Mysql优化目标

Mysql 优化的目标主要有三个：

1. 减少磁盘IO，在数据库中主要是来自于像全表扫描这种扫描大量数据快的场景，然后就是日志以及数据块的写入所带俩的压力。
2. 减少网络带宽主要是包括两个方面，第一，sql查询时，返回太多数据；第二，插入场景下交互次数过多。
3. 降低cpu的消耗，主要包括三个方面，第一，Mysql本身的逻辑(join多表链接)，第二，额外的技术操作，比如排序分组（order by、group by）第三，是聚合函数（max、min、sum）

下面是我对sql优化的一些总结，如有错误欢迎指出来

减少IO磁盘优化

1. 可以通过加索引来避免全表扫描。
2. select查询的时候不使用select * ，新增的时候同理
3. 尽量避免使用子查询（原因写在子查询优化）

减少网络带宽优化

1. sql查询时使用limit减少查询返回的数据

2. 减少插入情况下交互次数（如下）

批量插入语句：

insert into test (id,name) values(1,'张山')
insert into test (id,name) values(2,'李四')
insert into test (id,name) values(3,'王五')

可改写成如下形式：

insert into test (id,name) values(1,'张山'),(2,'李四'),(3,'王五')

降低cpu消耗

1. order by 优化，给order by 字段添加索引避免额外的排序，减少cup资源的消耗
2. group by 优化，也可以给group by 添加索引
3. 是聚合函数（max、min、sum）可以创建一张统计表，用定时任务把数据更新到统计表，之后直接查询统计表即可

---

其他 Select优化

子查询优化

为什么要对子查询进行优化:
第一点：执行子查询时，MySQL 需要为内层查询语句的查询结果建立一个临时表 ，然后外层查询语句从临时表中查询记录。查询完毕后，再撤销这些临时表 。这样会消耗过多的 CPU 和 IO 资源，产生大量的慢查询。
第二点：子查询的结果集存储的临时表，不论是内存临时表还是磁盘临时表都 不会存在索引 ，所以查询性能会受到一定的影响；对于返回结果集比较大的子查询，其对查询性能的影响也就越大。
优化方案Join替代
如下sql：

select * from test where id in (select test1_id from test2)

改写成：

select * from test t1 left join test2 t2 on t1.id = t2.test1_id

Limit 优化

为什么要对Limit进行优化:
当数据库有10w条数据，此时我要查出最后10条就得 limit 99990,10此时Mysql排序出前99990条记录后仅仅需要返回最后10条记录，前99990条记录造成额外的代价消耗
优化方案一使用覆盖索引，记录直接从索引中获得，效率最高，但是这种情况只适合查询字段比较少的情况（毕竟你也不可能给所有字段添加索引） ·

什么是覆盖索引：
第一，非主键查询，入口是二级索引（就是你平时定义的普通索引），通过二级索引，第一个过程返回聚集索引的id（主键id）因为二级索引里面存的就是聚集索引的id；第二个过程是回表，相当于再做一次数据检索，然后从聚集索引中获取数据
第二，主键查询，入口是直接通过聚集索引的id，可以在聚集索引中获取数据
第三，覆盖索引，入口是二级索引，直接从二级索引当中获取数据，前提是你所查询的字段都带有索引
优化方案二sql改写
优化前提是create_time字段有索引，思路是从索引中取出20条满足条件的主键值，然后回表获取记录

select * from test t1 inner join (select id from test order by create_time limit 99990,10) t2 on t1.id = t2.id

Join 优化

1. 当你使用left join 或者right join 时使用小表驱动原则减少循环查询次数，或者可以使用inner join 替代，inner join 会默认使用小表驱动
2. 关联字段添加索引
   
   如上图所示，这两个表join关联。sql语句执行计划，出现了join_buffer，执行计划部分Bloack Nested-Loop
   join_buffer（Bloack Nested-Loop）表示不能通过索引去做关联条件的匹配
   我们可以看到，通过b表关联访问a时，rows是127042，整个访问过程的代价特别大，对于这种场景是给关联条件添加索引，加好索引后我们再看执行计划
   
   可以看到rows从127042降到了125，前面执行时间接近2分钟，后面只需要0.31秒

MySQL优化

SQL优化背景

开发项目上线初期，由于业务数据量相对较少，一些SQL的执行效率对程序运行效率的影响不太明显，而开发和运维人员也无法判断SQL对程序的运行效率有多大，故很少针对SQL进行专门的优化，而随着时间的积累，业务数据量的增多，SQL的执行效率对程序的运行效率的影响逐渐增大，此时对SQL的优化就很有必要。

• SQL优化发生在业务量达到一定规模的时候
• 目的是优化SQL的执行效率

MySQL 优化

优化范围

• 硬件资源
• 操作系统参数，数据库参数配置
• SQL语句，索引优化

SQL优化

• 数据库设计优化【规范，前期设计】
• SQL语句优化
• 索引优化
• 读写分离，分库分表

慢查询语句

慢查询：10s无返回结果，定义为慢查询

SHOW STATUS LIKE "slow_queries";

SHOW VARIABLES LIKE "long_query_time";//可以显示当前慢查询时间

set long_query_time=1 ;//可以修改慢查询时间

常用优化方法

查询优化

• 避免全表扫描（考虑在 where 及 order by 涉及的列上建立索引）

• 尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描

  select id from t where num is null    
  可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：    
  select id from t where num=0    
  

• 应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描

• 应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描

  select id from t where num=10 or num=20    
  可以这样查询：    
  select id from t where num=10    
  union all    
  select id from t where num=20    
  

• in 和 not in 也要慎用，否则会导致全表扫描

  select id from t where num in(1,2,3)    
  对于连续的数值，能用 between 就不要用 in 了：    
  select id from t where num between 1 and 3    
  

• 应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描

  select id from t where num/2=100    
  应改为:    
  select id from t where num=100*2    
  

• 应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描

  select id from t where substring(name,1,3)=\'abc\'--name以abc开头的id    
  应改为:    
  select id from t where name like \'abc%\'    
  

• 很多时候用 exists 代替 in 是一个好的选择

  select num from a where num in(select num from b)    
  用下面的语句替换：    
  select num from a where exists(select 1 from b where num=a.num)    
  

• 索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率(5)

• 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销

• 尽可能的使用 varchar 代替 char ，因为首先变长字段存储空间小，可以节省存储空间

• 任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段

• 尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写

后记——了解MySQL索引

什么是索引？

索引是一种数据结构，具体表现在查找算法上。

索引分为主键索引和辅助索引，辅助索引又分为唯一性索引，普通索引，复合索引，覆盖索引。

索引的本质：以空间换时间。

索引目的

提高查询效率

【类比字典和借书】

如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。如果没有索引，那么你可能需要把所有单词看一遍才能找到你想要的。

去图书馆借书也是一样，如果你要借某一本书，一定是先找到对应的分类科目，再找到对应的编号，这是生活中活生生的例子，通用索引，可以加快查询速度，快速定位。

二叉树

每个节点最多含有两个子树的树称为二叉树。

二叉查找树ADT Tree

左子树的键值小于根的键值，右子树的键值大于根的键值。

平衡二叉树AVL Tree

在符合二叉查找树的条件下，还满足任何节点的两个子树的高度最大差为1。

BTree

BTree也称为平衡多路查找树

B-Tree是为磁盘等外存储设备设计的一种平衡查找树。

B+Tree

B+Tree是在B-Tree基础上的一种优化

• 非叶子结点只存储键值信息，不存储数据
• 所有的叶子结点都有一个链指针
• 数据记录都存放在叶子结点中

----------------2019/10/9

参考《MySQL DBA工作笔记》中杨建荣老师举得一个非常形象的例子：

“比如某公司里面有一个开发小组，组长管理一些程序员，自己也参与开发工作”——B树

“扁平化管理，彼此之间都是平行的，换句话说就是指责分离，组长不再敲代码了，专注于管理”——B+树

B树的非叶子节点同样担任着存储信息的功能，而在B+树中只有叶子节点存储信息。

MySQL默认使用B+Tree索引

索引本身也很大，所以存储在磁盘中,需要加载到内存中执行。

故：索引结构优劣标准：磁盘I/O次数

BTree是为了充分利用磁盘预读功能而创建出来的一种数据结构。

局部性原理和磁盘预读

局部性原理：当一个数据被用到，其附近的数据很可能会马上用到

磁盘预读：由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入主存。

为什么平衡二叉树无法利用磁盘预读功能而BTree可以？

平衡二叉树也称为红黑数，在逻辑上是平衡二叉树，但是在物理存储上使用的是数组，逻辑上相近的节点可能在物理上相差很远。

BTree如何利用磁盘预读功能？

将节点大小设为等于一个页，BTree新建节点时，也是按照页为单位申请，同时计算机存储分配也是按页对齐，那么一个节点只需一次IO就可以读取全部节点数据。

【如果节点大小和BTree大小不对齐，那么同一页节点可能需要两次IO读取】

综上所述，用B-Tree作为索引结构效率是非常高的。

为什么B+Tree比BTree更适合作为索引结构?

BTree解决了磁盘IO的问题但没有解决元素遍历复杂的问题。

B+Tree的叶子节点用链指针相连，极大提高区间访问速度。【比如查询50到100的记录，查出50后，顺着指针遍历即可】

为什么不使用Hash索引而使用B+Tree索引？

Hash索引本质上是Hash表，是一种KV键值对的存储结构。

无法提高区间访问速度。

B+Tree的叶子结点可以存哪些东西？

可能是整行数据，也可能是主键的值。

前者被称为聚簇索引，后者称为非聚簇索引。

聚簇索引更快！！！

为什么？？？聚簇索引已经查到整行数据了，而非聚簇索引还可能根据主键值再进行查询一次。

例外：覆盖索引——数据直接从索引中取得。