SQL执行与优化

Posted 2023-04-28

参考技术A

SQL优化

执行计划,表关联查询顺序,优化策略与思路

下面再向前走一些，容我根据自己的认识说一下查询执行的流程是怎样的：

1.连接

1.1客户端发起一条Query请求，监听客户端的‘连接管理模块’接收请求

1.2将请求转发到‘连接进/线程模块’

1.3调用‘用户模块’来进行授权检查

1.4通过检查后，‘连接进/线程模块’从‘线程连接池’中取出空闲的被缓存的连接线程和客户端请求对接，如果失败则创建一个新的连接请求

2.处理

2.1先查询缓存，检查Query语句是否完全匹配，接着再检查是否具有权限，都成功则直接取数据返回

2.2上一步有失败则转交给‘命令解析器’，经过词法分析，语法分析后生成解析树

2.3接下来是预处理阶段，处理解析器无法解决的语义，检查权限等，生成新的解析树

2.4再转交给对应的模块处理

2.5如果是SELECT查询还会经由‘查询优化器’做大量的优化，生成执行计划

2.6模块收到请求后，通过‘访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限

2.7有则调用‘表管理模块’，先是查看table cache中是否存在，有则直接对应的表和获取锁，否则重新打开表文件

2.8根据表的meta数据，获取表的存储引擎类型等信息，通过接口调用对应的存储引擎处理

2.9上述过程中产生数据变化的时候，若打开日志功能，则会记录到相应二进制日志文件中

3.结果

3.1Query请求完成后，将结果集返回给‘连接进/线程模块’

3.2返回的也可以是相应的状态标识，如成功或失败等

3.3‘连接进/线程模块’进行后续的清理工作，并继续等待请求或断开与客户端的连接

接下来再走一步，让我们看看一条SQL语句的前世今生。

首先看一下示例语句

示例语句

执行顺序

SQL解析

1. FROM

当涉及多个表的时候，左边表的输出会作为右边表的输入，之后会生成一个虚拟表VT1。

(1-J1)笛卡尔积

计算两个相关联表的笛卡尔积(CROSS JOIN) ，生成虚拟表VT1-J1。

两次全表扫描

哈希索引,查找复杂度都是 O(1) 。

2. WHERE

对VT1过程中生成的临时表进行过滤，满足WHERE子句的列被插入到VT2表中。

注意：

此时因为分组，不能使用聚合运算；也不能使用SELECT中创建的别名；

与ON的区别：

如果有外部列，ON针对过滤的是关联表，主表（保留表）会返回所有的列；

如果没有添加外部列，两者的效果是一样的；

应用：

对主表的过滤应该放在WHERE；

对于关联表，先条件查询后连接则用ON，先连接后条件查询则用WHERE；

hash join 哈希连接 驱动表和被驱动表都只会访问0次或1次

应用场景:一个大表一个小表/表上没有索引/返回结果集比较大

3. GROUP BY

这个子句会把VT2中生成的表按照GROUP BY中的列进行分组。生成VT3表。

注意：

其后处理过程的语句，如SELECT,HAVING，所用到的列必须包含在GROUP BY中，对于没有出现的，得用聚合函数；

原因：

GROUP BY改变了对表的引用，将其转换为新的引用方式，能够对其进行下一级逻辑操作的列会减少；

原作者的理解是：

根据分组字段，将具有相同分组字段的记录归并成一条记录，因为每一个分组只能返回一条记录，除非是被过滤掉了，而不在分组字段里面的字段可能会有多个值，多个值是无法放进一条记录的，所以必须通过聚合函数将这些具有多值的列转换成单值；

GROUP BY 重新聚合查询

4. HAVING

这个子句对VT3表中的不同的组进行过滤，只作用于分组后的数据，满足HAVING条件的子句被加入到VT4表中。

7.LIMIT

LIMIT子句从上一步得到的VT6虚拟表中选出从指定位置开始的指定行数据。

注意：

offset和rows的正负带来的影响；

当偏移量很大时效率是很低的，可以这么做：

采用子查询的方式优化，在子查询里先从索引获取到最大id，然后倒序排，再取N行结果集

采用INNER JOIN优化，JOIN子句里也优先从索引获取ID列表，然后直接关联查询获得最终结果

当前未用到索引,

三次full scan , table1 AS a / table2 AS b / GROUP BY

尽量少做重复的工作

控制同一语句的多次执/减少多次的数据转换/

杜绝不必要的子查询和连接表，子查询在执行计划一般解释成外连接，多余的连接表带来额外的开销

关于临时表和表变量的选择

临时表产生使用SELECT INTO和CREATE TABLE + INSERT INTO的选择，一般情况下，SELECT INTO会比CREATE TABLE + INSERT INTO的方法快很多，但是SELECT INTO会锁定TEMPDB的系统表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用户并发环境下，容易阻塞其他进程，所以建议，在并发系统中，尽量使用CREATE TABLE + INSERT INTO，而大数据量的单个语句使用中，使用SELECT INTO。

子查询的用法

相关子查询可以用IN、NOT IN、EXISTS、NOT EXISTS引入

NOT IN、NOT EXISTS的相关子查询可以改用LEFT JOIN代替写法

如果保证子查询没有重复 ，IN、EXISTS的相关子查询可以用INNER JOIN 代替

IN``的相关子查询用EXISTS代替

不要用 COUNT (*)的子查询判断是否存在记录，最好用 LEFT` `JOIN 或者EXISTS，比如有人写这样的语句：

建立索引后，并不是每个查询都会使用索引，在使用索引的情况下，索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引，

不要对索引字段进行运算，而要想办法做变换

不要对索引字段进行格式转换

不要对索引字段使用函数

不要对索引字段进行多字段连接

join关联查询的计算是很复杂的，特别是数据量比较大的情况下，实际情况还是拆解较快的

Join拆解的核心就是利用In关键字

要么用空间换时间，要么用时间换空间

多表连接的连接条件对索引的选择有着重要的意义，所以我们在写连接条件条件的时候需要特别注意。

A、多表连接的时候，连接条件必须写全，宁可重复，不要缺漏。

B、连接条件尽量使用聚集索引

C、注意ON、WHERE和HAVING部分条件的区别

ON是最先执行， WHERE次之，HAVING最后，因为ON是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，WHERE也应该比 HAVING快点的，因为它过滤数据后才进行SUM，在两个表联接时才用ON的，所以在一个表的时候，就剩下WHERE跟HAVING比较了

考虑联接优先顺序：

(1)INNER JOIN

(2)LEFT JOIN (注：RIGHT JOIN 用 LEFT JOIN 替代)

(3)CROSS JOIN

索引并不适用于所有情况：a.少量数据；b.频繁进行改动的字段，不适合做索引；c.很少使用的字段，不需要加索引

索引会提高数据查询效率，但是会降低“增、删、改”的效率。当不使用索引的时候，我们进行数据的增删改，只需要操作源表即可，但是当我们添加索引后，不仅需要修改源表，也需要再次修改索引，很麻烦。

先执行顺序, 是否走索引, 有无类型转换

18000 字的SQL优化大全

步步深入：mysql架构总览->查询执行流程->SQL解析顺序

MySQL索引总结（4）——btree与hash区别

Sql Server 优化----SQL语句的执行方式与锁以及阻塞的关系

　　阻塞原因之一是不同的Session在访问同一张表的时候因为不兼容锁的原因造成的， 　　当前执行的SQL语句是否被阻塞（或者死锁），不仅跟当前表上的已有的锁有关，也会跟当前执行的SQL语句的执行方式有关 　　简单来说，对于表的访问方式，SQL语句的执行无非是表扫描，索引扫描，（聚集索引或者非聚集索引）索引查找等等 　　如果SQL语句的执行方式不当或者没有合理的索引，会造成没必要的阻塞，如果逻辑控制不当，甚至造成更严重的问题，造成数据逻辑的错误

 

建个测试表，下面测试演示一下

create table testIndexAndLock
(
    id int identity(1,1),
    col2 varchar(50)
)
GO

insert into testIndexAndLock values (NEWID())
GO 100000

 

　　很常见的业务就是，当前Session中开启了事物，执行更新或者删除某一行数据，然后再进行一系列其他的操作，当前事物提交之前，该排它锁一致保持，直到事物提交

　　比如下面截图：

　　第一个Session中利用事物和排他性操作锁定一行数据，，进行业务逻辑处理，按道理来说：目的仅仅是锁定当前行的数据（id = 6666），进行排他性操作，并没有锁定其的数据行

　　

　　然后再第二个Session中，查询其他的无关的Id，按道理，上面一个Session只是锁定了id = 6666的行，怎么当前Session查询Id = 7777的行的时候会被阻塞呢？

　　

　　这里就是上面说的对当前表的访问方式了，因为当前查询的表上没有任何索引，在查询id = 7777的时候，虽然id = 7777的行上没有任何锁，为什么查询还是被阻塞？ 　　这里在执行查询id = 7777的时候，用的是全表扫描的方式执行的，此时遇到Id = 6666的这行数据的时候，因为这行数据上有排它锁，当前Session被阻塞 　　可以简单理解为当前Session会逐行扫描表中的数据行，在扫描的过程中，不管是表也好，数据行也好，如果遇到兼容的锁，可以正常访问， 　　如果遇到不兼容的锁，比如这里的查询是共享锁（s锁），遇到第一个Session中的id = 6666的这行数据的时候，发现上面是排它锁， 　　此时，当前Session要对该行加的锁（共享锁）与该行上的排它锁（x锁）不兼容，就只能等待，知道id = 6666这行数据上的排它锁释放或者变化与当前请求的共享锁兼容的锁，才能执行 　　如果id = 6666上面的排它锁一直没有释放或者变化为兼容共享锁的锁类型，当前Session就一直等待 　　表现为当前Session被阻塞 　　这种问题解决办法也很简单，类似现象如果要不被阻塞，要么等到第一个Session的排它锁释放，要么就换一种查询的方式 　　尝试在表的Id列上建立一个索引，当然聚集索引也可以，目的是防止查询的时候以全表扫描的方式进行

　　

　　在第二个Session中执行上面的查询，查询Id = 7777的数据行，可以发现这个查询可以顺利完成

　　

　　这个就是通过索引改变查询的执行计划，避免全表扫描的时候遇到任何一行数据上有排它锁造成阻塞的情况。 　　这里说的索引，并不仅仅是为了提高效率，更重要的是改变了查询的执行方式，避免遇到表上有排他性锁的锁在成阻塞的情况。

 

索引的作用不仅仅是提高查询效率，更重要的是避免全表扫描的过程中遇到排它锁被阻塞的情况，对减少阻塞有一定的帮助作用。