MySQL基本调度策略浅析

  MySQL允许影响语句的调度特性,这样会使来自几个客户机的查询更好地协作,从而单个客户机不会被锁定太长的时间。更改调度特性还能保证特定的查询处理得更快。我们先来看一下MySQL的缺省调度策略,然后来看看为改变这个策略可使用什么样的选项。出于讨论的目的,假设执行检索( SELECT)的客户机程序为读取程序。执行修改表操作( DELETE,INSERT,REPLACE 或UP DATE)的另一个客户机程序为写入程序。

  MySQL的基本调度策略可总结如下:

  ◆写入请求应按其到达的次序进行处理。

  ◆写入具有比读取更高的优先权。

  在表锁的帮助下实现调度策略。客户机程序无论何时要访问表,都必须首先获得该表的锁。可以直接用LOCK TABLES 来完成这项工作,但一般服务器的锁管理器会在需要时自动获得锁。在客户机结束对表的处理时,可释放表上的锁。直接获得的锁可用UNLOCK TABLES 释放,但服务器也会自动释放它所获得的锁。

  执行写操作的客户机必须对表具有独占访问的锁。在写操作进行中,由于正在对表进行数据记录的删除、增加或更改,所以该表处于不一致状态,而且该表上的索引也可能需要作相应的更新。如果表处于不断变化中,此时允许其他客户机访问该表会出问题。让两个客户机同时写同一个表显然不好,因为这样会很快使该表不可用。允许客户机读不断变化的表也不是件好事,因为可能在读该表的那一刻正好正在对它进行更改,其结果是不正确的。执行读取操作的客户机必须有一把防止其他客户机写该表的锁,以保证读表的过程中表不出现变化。不过,该锁无需对读取操作提供独占访问。此锁还允许其他客户机同时对表进行读取。读取不会更改表,所有没必要阻止其它客户机对该表进行读取。

  MySQL允许借助几个查询限修饰符对其调度策略施加影响。其中之一是DELETE、INSERT、LOAD DATA、REPLACE 和UP DATE 语句的LOW_PRIORITY 关键字。另一个是SELECT 语句的HIGH_PRIORITY 关键字。第三个是INSERT 和REPLACE 语句的DELAYED 关键字。

  LOW_PRIORITY 关键字按如下影响调度。一般情况下,如果某个表的写入操作在表正被读取时到达,写入程序被阻塞,直到读取程序完成,因为一旦某个查询开始,就不能中断。如果另一读取请求在写入程序等待时到达,此读取程序也被阻塞,因为缺省的调度策略为写入程序具有比读取程序高的优先级。在第一个读取程序结束时,写入程序继续,在此写入程序结束时,第二个读取程序开始。

  如果写入请求为LOW_PRIORITY 的请求,则不将该写入操作视为具有比读取操作优先级高的操作。在此情形下,如果第二个读取请求在写入程序等待时到达,则让第二个读取操作排在等待的写入操作之前。仅当没有其他读取请求时,才允许写入程序执行。这种调度的更改从理论上说,其含义为LOW_PRIORITY 写入可能会永远被阻塞。当正在处理前面的读取请求时,只要另一个读取请求到达,这个新的请求允许排在LOW_PRIORITY 写入之前。

  SELECT 查询的HIGH_PRIORITY 关键字作用类似。它使SELECT 插在正在等待的写入操作之前,即使该写入操作具有正常的优先级。INSERT 的ELAYED 修饰符作用如下,在表的一个INSERT DELAYED 请求到达时,服务器将相应的行放入一个队列,并立即返回一个状态到客户机程序,以便该客户机程序可以继续执行,即使这些行尚未插入表中。如果读取程序正在对表进行读取,那么队列中的行挂起。在没有读取时,服务器开始开始插入延迟行队列中的行。服务器不时地停下来看看是否有新的读取请求到达,并进行等待。如果是这样,延迟行队列将挂起,并允许读取程序继续。在没有其他的读取操作时,服务器再次开始插入延迟行。这个过程一直进行到延迟行队列空为止。

  此并非出现在所有MySQL版本中。下面的表列出了这些修饰符和支持这些修饰符的MySQL版本。可利用此表来判断所使用的MySQL版本具有什么样的功能:

  如果其他客户机可能执行冗长的SELECT 语句,而且您不希望等待插入完成,此时INSERT DELAYED 很有用。发布INSERT DELAYED 的客户机可以更快地继续执行,因为服务器只是简单地将要插入的行插入。不过应该对正常的INSERT 和INSERT DELAYED 性能之间的差异有所认识。如果INSERT DELAYED 存在语法错误,则向客户机发出一个错误,如果正常,便不发出信息。例如,在此语句返回时,不能相信所取得的AUTO_INCREMENT 值。也得不到惟一索引上的重复数目的计数。之所以这样是因为此插入操作在实际的插入完成前返回了一个状态。其他还表示,如果INSERT DELAYED 语句的行在等待插入中被排队,并且服务器崩溃或被终止(用kill -9),那么这些行将丢失。正常的TERM 终止不会这样,服务器会在退出前将这些行插入。

时间: 2024-08-03 12:38:35

MySQL基本调度策略浅析的相关文章

MySQL 高可用浅析

MySQL 高可用浅析 对于多数应用来说,MySQL都是作为最关键的数据存储中心的,所以,如何让MySQL提供HA服务,是我们不得不面对的一个问题.当master当机的时候,我们如何保证数据尽可能的不丢失,如何保证快速的获知master当机并进行相应的故障转移处理,都是需要我们好好思考的.这里,笔者将结合这段时间做的MySQL proxy以及toolsets相关工作,说说我们现阶段以及后续会在项目中采用的MySQL HA方案. (题图来自:comprendrechoisir.com) Repli

MySQL查询优化器浅析

1.定义 Mysql查询优化器的工作是为查询语句选择合适的执行路径.查询优化器的代码一般是经常变动的,这 和存储引擎不太一样.因此,需要理解最新版本的查询优化器是如何组织的,请参考相应的源代码.整体 而言,优化器有很多相同性,对mysql一个版本的优化器做到整体掌握,理解起mysql新版本以及其他数据 库的优化器都是类似的. 优化器会对查询语句进行转化,转化等价的查询语句.举个例子,优化器会将下面语句进行转化: SELECT - WHERE 5=a; 转化后的等价语句为: SELECT - WH

MySQL参数对比浅析(r11笔记第97天)

  今天按照计划,决定得总结下MySQL的参数了,说来想来,立即就做. 大体算了下,手头的环境主要还是使用了Percona分支,官方的相对较少,就暂且按照Percona的版本来统计参数的情况,可能和官方的会有一些出入.    数据版本会有一个较大的跨度,从5.0到5.7都有,这也能够间接反映出一个系统的变迁过程.   涉及的数据库版本如下,基本版本就是5.0, 5.5, 5.6, 5.7 5.0.67-percona-highperf-log 5.5.33-31.1-log 5.6.14-rel

MySQL replace into 语句浅析(一)

  这篇文章主要介绍了MySQL replace into 语句浅析(一),本文讲解了replace into的原理.使用方法及使用的场景和使用示例,需要的朋友可以参考下 一 介绍 在笔者支持业务过程中,经常遇到开发咨询replace into 的使用场景以及注意事项,这里做个总结.从功能原理,性能和注意事项上做个说明. 二 原理 2.1 当表中存在主键但是不存在唯一建的时候. 表结构 代码如下: CREATE TABLE `yy` ( `id` bigint(20) NOT NULL, `na

MySQL replace into 语句浅析(二)

  这篇文章主要介绍了MySQL replace into 语句浅析(二),本文着重给出了几个特殊案例分析,需要的朋友可以参考下 一 介绍 上一篇文章介绍了replace into的基本原理.本章内容通过一个例子说明 replace into 带来的潜在的数据质量风险,当涉及replace into操作的表含有自增主键时,主备切换后会造成数据覆盖等不一致的情况发生. 二 案例分析 在主库上操作 代码如下: root@test 12:36:51>show create table t1 G ***

【MySQL】sync_binlog innodb_flush_log_at_trx_commit 浅析

 innodb_flush_log_at_trx_commit和sync_binlog 两个参数是控制MySQL 磁盘写入策略以及数据安全性的关键参数.本文从参数含义,性能,安全角度阐述两个参数为不同的值时对db 性能,数据的影响. 一 参数意义 innodb_flush_log_at_trx_commit 如果innodb_flush_log_at_trx_commit设置为0,log buffer将每秒一次地写入log file中,并且log file的flush(刷到磁盘)操作同时进行.该

为PostgreSQL讨说法 - 浅析《UBER ENGINEERING SWITCHED FROM POSTGRES TO MYSQL》

背景 最近有一篇文档,在国外闹得沸沸扬扬,是关于UBER使用mysql替换postgres原因的文章. 英文原文https://eng.uber.com/mysql-migration/ 来自高可用架构的 中文翻译 文章涉及到 PG数据库的部分,背后的原理并没有深入的剖析,导致读者对PostgreSQL的误解 . uber在文章阐述的遇到的PG问题 We encountered many Postgres limitations: Inefficient architecture for wri

浅析MySQL中的Index Condition Pushdown (ICP 索引条件下推)和Multi-Range Read(MRR 索引多范围查找)查询优化

原文:浅析MySQL中的Index Condition Pushdown (ICP 索引条件下推)和Multi-Range Read(MRR 索引多范围查找)查询优化   本文出处:http://www.cnblogs.com/wy123/p/7374078.html(保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他)     ICP优化原理 Index Condition Pushdown (ICP),也称为索引条件下推

RDS for MySQL CPU 性能问题浅析

RDS for MySQL CPU 性能问题浅析 1. 原因 1.1 应用负载高 1.2 查询执行成本高 2. 解决方法2.1 相关工具 2.2 应用负载高 2.3 查询语句执行成本高 3. 避免出现的一般原则 RDS for MySQL 实例在日常使用中,会碰到 CPU 使用率达到 100% 的情况.比如: 1. 原因 根本原因:应用提交的查询访问的 逻辑读(逻辑 IO) 总量 (需要访问的 表 数据) 过高. 大量逻辑读会导致数据缓存 Buffer Pool 中用于维护数据一致性的 Latc