您当前的位置:首页>>技术中心>>数据恢复文章>>正文
 
MySQL查询优化系列讲座之调度和锁定
作者: 来源: 日期:2009-5-11 16:47:11  点击次数:

前面的部分主要是聚焦于如何让单独的查询执行的速度更快。MySQL还允许你改变语句调度的优先级,它可以使来自多个客户端的查询更好地协作,这样单个客户端就不会由于锁定而等待很长时间。改变优先级还可以确保特定类型的查询被处理得更快。这一部分讲解MySQL的默认的调度策略和可以用来影响这些策略的选项。它还谈到了并发性插入操作的使用和存储引擎锁定层次对客户端的并发性的影响。为了讨论的方便,我们把执行检索(SELECT)的客户端称为"读取者",把执行修改操作(DELETE、INSERT、REPLACE或UPDATE)的客户端称为"写入者"。

  MySQL的默认的调度策略可用总结如下:

  · 写入操作优先于读取操作。

  · 对某张数据表的写入操作某一时刻只能发生一次,写入请求按照它们到达的次序来处理。

  · 对某张数据表的多个读取操作可以同时地进行。

  MyISAM和MEMORY存储引擎借助于数据表锁来实现这样的调度策略。当客户端访问某张表的时候,首先必须获取它的锁。当客户端完成对表的操作的时候,锁就会被解除。通过LOCK TABLES和UNLOCK TABLES语句来显式地获取或释放锁是可行的,但是在通常情况下,服务器的锁管理器会自动地在需要的时候获取锁,在不再需要的时候释放锁。获取的锁的类型依赖于客户端是写入还是读取操作。

  对某张表进行写入操作的客户端必须拥有独占的(排他的)访问权的锁。操作在进行的过程中,该数据表处于不一致的(inconsistent)状态,因为数据记录在删除、添加或修改的时候,数据表上的索引也可能需要更新以相互匹配。这个数据表在变化的过程中,如果允许其它的客户端访问,会出现问题。非常明显,允许两个客户端同时写入一张数据表是不利的,因为这样的操作会很快使数据表中的信息成为一堆无用的垃圾。但是允许客户端读取变化之中的数据表也不好,因为正在读取的位置中的数据可能正在变化(修改),读取的结果可能不是真实的。

  对某张表执行读取操作的客户端必须获取一个锁,防止在读取的过程中,其它的客户端写入或改变表。但是这个锁不需要独占的访问权。读取操作不会改变数据,因此没有理由让某个读取者阻止其它的读取者访问这张表。因此读取锁允许其它的客户端在同一时刻读取这张表。

  MySQL提供了几个语句调节符,允许你修改它的调度策略:

  · LOW_PRIORITY关键字应用于DELETE、INSERT、LOAD DATA、REPLACE和UPDATE。

  · HIGH_PRIORITY关键字应用于SELECT和INSERT语句。

  · DELAYED关键字应用于INSERT和REPLACE语句。

  LOW_PRIORITY和HIGH_PRIORITY调节符影响那些使用数据表锁的存储引擎(例如MyISAM和MEMORY)。DELAYED调节符作用于MyISAM和MEMORY数据表。

  改变语句调度的优先级

  LOW_PRIORITY关键字影响DELETE、INSERT、LOAD DATA、REPLACE和UPDATE语句的执行调度。通常情况下,某张数据表正在被读取的时候,如果有写入操作到达,那么写入者一直等待读取者完成操作(查询开始之后就不能中断,因此允许读取者完成操作)。如果写入者正在等待的时候,另一个读取操作到达了,该读取操作也会被阻塞(block),因为默认的调度策略是写入者优先于读取者。当第一个读取者完成操作的时候,写入者开始操作,并且直到该写入者完成操作,第二个读取者才开始操作。

  如果写入操作是一个LOW_PRIORITY(低优先级)请求,那么系统就不会认为它的优先级高于读取操作。在这种情况下,如果写入者在等待的时候,第二个读取者到达了,那么就允许第二个读取者插到写入者之前。只有在没有其它的读取者的时候,才允许写入者开始操作。理论上,这种调度修改暗示着,可能存在LOW_PRIORITY写入操作永远被阻塞的情况。如果前面的读取操作在进行的过程中一直有其它的读取操作到达,那么新的请求都会插入到LOW_PRIORITY写入操作之前。

本新闻共3页,当前在第1页  1  2  3  


上一篇:MYSQL出错代码列表
下一篇:关于MSSQL占用过多内存的问题
  北京总部: 4006-505-808
  天 津 部: 4006-505-808
  上 海 部: 4006-505-808
  深 圳 部: 4006-505-808
  广 州 部: 4006-505-808
  重 庆 部: 4006-505-808
  南 京 部: 4006-505-808
  其它地区: 4006-505-808
经典案例
中国石油管理局-Oracle数据库恢
中国网通-IBM EXP300磁盘阵列数
大连鸿德经贸有限责任公司-SQL
中国地质环境监测院-HP LH3000
藁城市东街百货-EFS文件解密成
工商银行某省分行-AIX删除LV数
中央电视台新闻评论部-苹果分
promise乔鼎硬盘阵列数据恢复成
麒麟童文化-苹果分区无法打开,
NAS 8100服务器数据恢复成功 
解决方案
raid磁盘阵列OFFLINE后的应急方
磁盘未被格式化,是否格式化数据
误GHOST、误一键恢复灾难应急方
误删除、误格式化数据灾难应急
LINUX FSCK数据出错灾难应急方
北亚数据恢复 - 联系我们 - 关于北亚 - 友情链接 - 网站地图 - RSS聚合 
版权所有 北亚数据恢复中心
全国统一客服热线:4006-505-808
北京总部:北京市海淀区中关村大街11号E世界A座8层832B室