SQL优化 短命女 2024-04-28 13:05 2阅读 0赞 ## SQL语句优化 ## ### SELECT语句执⾏顺序 ### #### 代码编写顺序 #### 1. select distinct 查询字段 2. from 表名 3. JOIN 表名 4. ON 连接条件 5. where 查询条件 6. group by 分组字段 7. having 分组后条件 8. order by 排序条件 9. limit 查询起始位置, 查询条数 #### Mysql读取顺序 #### 1. from 表名 2. ON 连接条件 3. JOIN 表名 4. where 查询条件 5. group by 分组字段 6. having 分组后条件 7. select distinct 查询字段 8. order by 排序条件 9. limit 查询起始位置, 查询条数 ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNzIyODI3_size_16_color_FFFFFF_t_70_pic_center] #### SQL的执行过程 #### 1. 客户端发送一条查询给服务器; 2. 服务器通过权限检查之后,先会检查查询缓存,如果命中了缓存,则立即返回存储在缓存中的结果。否则进入下一阶段; 3. 服务器端进行SQL解析、预处理,再由优化器根据该SQL所涉及到的数据表的统计信息进行计算,生成对应的执行计划; 4. MySQL根据优化器生成的执行计划,调用存储引擎的API来执行查询; 5. 将结果返回给客户端。 ### SQL语句 优化 ### 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。 3.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描, 如: select id from t where num is null 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select id from t where num=0 4.应尽量避免在 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 5.下面的查询也将导致全表扫描: select id from t where name like '%abc%' 若要提高效率,可以考虑全文检索。 6.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 7.如果在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描: select id from t where num=@num 可以改为强制查询使用索引: select id from t with(index(索引名)) where num=@num 8.应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如: select id from t where num/2=100 应改为: select id from t where num=100*2 9.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如: select id from t where substring(name,1,3)='abc' --name以abc开头的id select id from t where datediff(day,createdate,'2005-11-30')=0 --'2005-11-30'生成的id 应改为: select id from t where name like 'abc%' select id from t where createdate>='2005-11-30' and createdate<'2005-12-1' 10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。 11.在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。 13.很多时候用 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) 14.并不是所有索引对查询都有效,SQL是根据表中数据来进行查询优化的,当索引列有大量数据重复时,SQL查询可能不会去利用索引,如一表中有字段sex,male、female几乎各一半,那么即使在sex上建了索引也对查询效率起不了作用。 15.索引并不是越多越好,索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有必要。 16.应尽可能的避免更新 clustered 索引数据列,因为 clustered 索引数据列的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列,那么需要考虑是否应将该索引建为 clustered 索引。 17.尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。 18.尽可能的使用 varchar/nvarchar 代替 char/nchar ,因为首先变长字段存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些。 19.任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。 20.尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。 21.避免频繁创建和删除临时表,以减少系统表资源的消耗。 22.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。 ### 存储过程 ### 存储过程(Stored Procedure)是⼀种在数据库中存储复杂程序,以便外部程序调⽤的⼀种 数据库对象。 存储过程是为了完成特定功能的SQL语句集,经编译创建并保存在数据库中,⽤户可通过指定存储过程的名字并给定参数(需要时)来调⽤执⾏。 存储过程思想上很简单,就是数据库 SQL 语⾔层⾯的代码封装与重⽤。 优点 存储过程可封装,并隐藏复杂的商业逻辑。 存储过程可以回传值,并可以接受参数。 存储过程⽆法使⽤ SELECT 指令来运⾏,因为它是⼦程序,与查看表,数据表或⽤户定义函数不同。 存储过程可以⽤在数据检验,强制实⾏商业逻辑等。 缺点 存储过程,往往定制化于特定的数据库上,因为⽀持的编程语⾔不同。当切换到其他⼚商的数据库系统时,需要重写原有的存储过程。 存储过程的性能调校与撰写,受限于各种数据库系统。 ### MySQL锁机制 ### 锁是计算机协调多个进程或线程并发访问某一资源的机制。锁保证数据并发访问的一致性、有效性; 锁冲突也是影响数据库并发访问性能的一个重要因素。锁是Mysql在服务器层和存储引擎层的的并发控制。 加锁是消耗资源的,锁的各种操作,包括获得锁、检测锁是否是否已解除、释放锁等。 #### 粒度锁 #### MySQL的锁机制比较简单,其最 显著的特点是不同的存储引擎支持不同的锁机制。 比如,MyISAM和MEMORY存储引擎采用的是表级锁(table-level locking); BDB存储引擎采用的是页面锁(page-level locking),但也支持表级锁; InnoDB存储引擎既支持行级锁(row-level locking),也支持表级锁,但默认情况下是采用行级锁。 #### 不同粒度锁的比较 #### 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般 MySQL主要的两种锁的特性可大致归纳如下: 表级锁: 开销小,加锁快;不会出现死锁(因为MyISAM会一次性获得SQL所需的全部锁);锁定粒度大,发生锁冲突的概率最高,并发度最低。 行级锁: 开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。 考虑上述特点,表级锁使用与并发性不高,以查询为主,少量更新的应用,比如小型的web应用;而行级锁适用于高并发环境下,对事务完整性要求较高的系统,如在线事务处理系统。 #### 共享锁与排他锁 #### 共享锁(读锁):其他事务可以读,但不能写。 排他锁(写锁) :其他事务不能读取,也不能写。 #### 如何加表锁 #### MyISAM在执行查询语句(SELECT)前,会自动给涉及的所有表加读锁,在执行更新操作 (UPDATE、DELETE、INSERT等)前,会自动给涉及的表加写锁,这个过程并不需要用户干预,因此,用户一般不需要直接用LOCK TABLE命令给MyISAM表显式加锁。 #### 事务 #### ##### 事务(Transaction)及其ACID属性 ##### 事务是由一组SQL语句组成的逻辑处理单元,事务具有4属性,通常称为事务的ACID属性。 原子性(Actomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。 一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以 操持完整性;事务结束时,所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。 隔离性(Isolation):数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。 持久性(Durable):事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。 ##### 并发事务带来的问题 ##### 相对于串行处理来说,并发事务处理能大大增加数据库资源的利用率,提高数据库系统的事务吞吐量,从而可以支持可以支持更多的用户。但并发事务处理也会带来一些问题,主要包括以下几种情况。 更新丢失(Lost Update):当两个或多个事务选择同一行,然后基于最初选定的值更新该行时,由于每个事务都不知道其他事务的存在,就会发生丢失更新问题——最后的更新覆盖了其他事务所做的更新。例如,两个编辑人员制作了同一文档的电子副本。每个编辑人员独立地更改其副本,然后保存更改后的副本,这样就覆盖了原始文档。最后保存其更改保存其更改副本的编辑人员覆盖另一个编辑人员所做的修改。如果在一个编辑人员完成并提交事务之前,另一个编辑人员不能访问同一文件,则可避免此问题。 脏读(Dirty Reads):一个事务正在对一条记录做修改,在这个事务并提交前,这条记录的数据就处于不一致状态;这时,另一个事务也来读取同一条记录,如果不加控制,第二个事务读取了这些“脏”的数据,并据此做进一步的处理,就会产生未提交的数据依赖关系。这种现象被形象地叫做“脏读”。 不可重复读(Non-Repeatable Reads):一个事务在读取某些数据已经发生了改变、或某些记录已经被删除了!这种现象叫做“不可重复读”。 幻读(Phantom Reads):一个事务按相同的查询条件重新读取以前检索过的数据,却发现其他事务插入了满足其查询条件的新数据,这种现象就称为“幻读”。 ### 死锁(Deadlock Free) ### #### 死锁产生 #### 死锁是指两个或多个事务在同一资源上相互占用,并请求锁定对方占用的资源,从而导致恶性循环。 当事务试图以不同的顺序锁定资源时,就可能产生死锁。多个事务同时锁定同一个资源时也可能会产生死锁。 锁的行为和顺序和存储引擎相关。以同样的顺序执行语句,有些存储引擎会产生死锁有些不会——死锁有双重原因:真正的数据冲突;存储引擎的实现方式。 #### 检测死锁 #### 数据库系统实现了各种死锁检测和死锁超时的机制。InnoDB存储引擎能检测到死锁的循环依赖并立即返回一个错误。 #### 死锁恢复 #### 死锁发生以后,只有部分或完全回滚其中一个事务,才能打破死锁,InnoDB目前处理死锁的方法是,将持有最少行级排他锁的事务进行回滚。所以事务型应用程序在设计时必须考虑如何处理死锁,多数情况下只需要重新执行因死锁回滚的事务即可。 #### 外部锁的死锁检测 #### 发生死锁后,InnoDB 一般都能自动检测到,并使一个事务释放锁并回退,另一个事务获得锁,继续完成事务。但在涉及外部锁,或涉及表锁的情况下,InnoDB 并不能完全自动检测到死锁, 这需要通过设置锁等待超时参数 innodb_lock_wait_timeout 来解决 #### InnoDB避免死锁 #### 为了在单个InnoDB表上执行多个并发写入操作时避免死锁,可以在事务开始时通过为预期要修改的每个元祖(行)使用SELECT … FOR UPDATE语句来获取必要的锁,即使这些行的更改语句是在之后才执行的。 在事务中,如果要更新记录,应该直接申请足够级别的锁,即排他锁,而不应先申请共享锁、更新时再申请排他锁,因为这时候当用户再申请排他锁时,其他事务可能又已经获得了相同记录的共享锁,从而造成锁冲突,甚至死锁 如果事务需要修改或锁定多个表,则应在每个事务中以相同的顺序使用加锁语句。 在应用中,如果不同的程序会并发存取多个表,应尽量约定以相同的顺序来访问表,这样可以大大降低产生死锁的机会 通过SELECT … LOCK IN SHARE MODE获取行的读锁后,如果当前事务再需要对该记录进行更新操作,则很有可能造成死锁。 改变事务隔离级别 如果出现死锁,可以用 SHOW INNODB STATUS 命令来确定最后一个死锁产生的原因。返回结果中包括死锁相关事务的详细信息,如引发死锁的 SQL 语句,事务已经获得的锁,正在等待什么锁,以及被回滚的事务等。据此可以分析死锁产生的原因和改进措施。 [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNzIyODI3_size_16_color_FFFFFF_t_70_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/28/a9ca8ee328a045ea9fec36ce044adda1.png
相关 SQL优化(三):SQL优化实战 前两节基本是讲了SQL优化重要的工具大概思路,你连explain都看不明白,遇到慢查询一个SQL执行半天的情况,估计优化起来肯定无处着手。 这节主要是SQL优化的具体实战,常 小灰灰/ 2022年10月19日 04:18/ 0 赞/ 176 阅读
相关 【sql】sql优化 1. 要尽量避免 NULL 要尽可能地把字段定义为 NOT NULL。即使应用程序无须保存 NULL(没有值),也有许多表包含了可空列(Nullable Col ゝ一纸荒年。/ 2022年06月14日 20:48/ 0 赞/ 247 阅读
相关 SQL优化 网上关于SQL优化的教程很多,但是比较杂乱。近日有空整理了一下,写出来跟大家分享一下,其中有错误和不足的地方,还请大家纠正补充。 这篇文章我花费了大量的时间查找资料、修 男娘i/ 2021年11月09日 21:52/ 0 赞/ 339 阅读
相关 SQL优化 数据库优化的层次 SQL与索引 存储引擎与表结构 数据库架构/缓存 MySQL/Oracle配置 硬件与操作系统 引起全表扫描和低效率的SQL 约定不等于承诺〃/ 2021年11月04日 22:20/ 0 赞/ 329 阅读
相关 sql优化 1, 对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 2,应尽量避免在 where 子句中对字段进行 null 值判 蔚落/ 2021年09月28日 00:58/ 0 赞/ 349 阅读
相关 SQL优化 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断 落日映苍穹つ/ 2021年09月21日 01:26/ 0 赞/ 376 阅读
相关 sql优化 记录一下看到的适用于mysql语句的优化 1、查询 SQL 尽量不要使用 select \,而是 select 具体字段 反例子: select from e 曾经终败给现在/ 2021年09月01日 08:59/ 0 赞/ 396 阅读
相关 sql优化 1、all: 全表扫描,遍历全表找到匹配的行 index:索引全扫描,遍历整个索引来查询匹配的行 range:索引范围扫描,常见于<,>,>=,between等操作符 ... 系统管理员/ 2021年03月30日 16:03/ 0 赞/ 589 阅读
相关 sql优化 文章连接 [https://blog.csdn.net/jie\_liang/article/details/77340905][https_blog.csdn.net_... 朱雀/ 2021年01月24日 18:01/ 0 赞/ 637 阅读
还没有评论,来说两句吧...