MySQL 事务与锁定命令

最新推荐文章于 2024-07-29 09:00:00 发布

iteye_18062

最新推荐文章于 2024-07-29 09:00:00 发布

阅读量80

点赞数

分类专栏： MySql 文章标签： MySQL SQL

MySql 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

MySQL 事务与锁定命令

6.7. １ . BEGIN/COMMIT/ROLLBACK 句法

缺省的， MySQL 运行在 autocommit 模式。这就意味着，当你执行完一个更新时， MySQL 将立刻将更新存储到磁盘上。

如果你使用事务安全表 ( 例如 InnoDB 、 BDB ) ，通过下面的命令，你可以设置 MySQL 为非 autocommit 模式：

SET AUTOCOMMIT=0

在此之后，你必须使用 COMMIT 来存储你的更改到磁盘上，或者使用 ROLLBACK ，如果你希望忽略从你的事务开始所做的更改。

如果你希望为一系列语句从 AUTOCOMMIT 模式转换，你可以使用 START TRANSACTION 或 BEGIN 或 BEGIN WORK 语句：

START TRANSACTION;

SELECT @A:=SUM(salary) FROM table1 WHERE type=1;

UPDATE table2 SET summmary=@A WHERE type=1;

COMMIT;

START TRANSACTION 在 MySQL 4.0.11 中被加入；这是被推荐的开始一个特别 (ad-hoc) 事务的方式，因为这是 ANSI SQL 句法。

注意，如果你使用的是一个非事务安全表，更改会立刻被存储，不受 autocommit 模式状态的约束。

当你更新了一个非事务表后，如果你执行一个 ROLLBACK ，你将得到一个错误 ( ER_WARNING_NOT_COMPLETE_ROLLBACK ) 作为一个警告。所有事务安全表将被恢复，但是非事务安全表将不会改变。

如果你使用 START TRANSACTION 或 SET AUTOCOMMIT=0 ，你应该使用 MySQL 二进制日志做备份以代替老的更新日志。事务处理被以一个大块形式存储在二进制日志中，在 COMMIT 上面，为了保护回滚的事务，而不是被存储的。查看章节 4.9.4 二进制日志。如果您使用起动事务处理或集 AUTOCOMMIT=0 ，您应该使用 MySQL 二进制日志为备份代替更旧的更新日志。事务处理存储在二进制登录一大块，做，保证 , 滚的事务处理不存储。参见部分 4 。 9.4 二进制日志。

下列命令自动的结束一个事务 ( 就好像你在执行这个命令之前，做了一个 COMMIT ) ：

命令	命令	命令
ALTER TABLE	BEGIN	CREATE INDEX
DROP DATABASE	DROP TABLE	RENAME TABLE
TRUNCATE

你可以使用 SET TRANSACTION ISOLATION LEVEL ... 改变事务的隔离级。查看章节 6.7.3 SET TRANSACTION 句法。

6.7.2 LOCK TABLES/UNLOCK TABLES 句法

LOCK TABLES tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE}

[, tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE} ...]

...

UNLOCK TABLES

LOCK TABLES 为当前线程锁定表。 UNLOCK TABLES 释放当前线程拥有的所有锁定。当线程发出另一个 LOCK TABLES ，或当与服务器的连接被关闭时，被当前线程锁定的所有表将被自动地解锁。

为了在 MySQL 4.0.2 使用 LOCK TABLES ，你必须拥有一个全局的 LOCK TABLES 权限和一个在相关表上的 SELECT 权限。在 MySQL 3.23 中，你对该表需要有 SELECT 、 insert 、 DELETE 和 UPDATE 权限。

使用 LOCK TABLES 的主要原因是，仿效事务处理或在更新表时得到更快的速度。此后会有更详细的描述。

如果一个线程在一个表上得到一个 READ 锁，该线程 ( 和所有其它线程 ) 只能从表中读取。如果一个线程在一个表上得到一个 WRITE 锁，那么只有拥有这个锁的线程可以从表中读取和写表。其它的线程被阻塞。

READ LOCAL 和 READ 之间的不同就在于，当锁被加载时， READ LOCAL 允许非冲突 (non-conflicting) INSERT 语句执行。如果当你加载着锁时从 MySQL 外部操作数据库文件，这将仍不能被使用。

当你使用 LOCK TABLES 是地，你必须锁定所有你将使用的表，并且必须使用与你的查询中将使用的别名相同！如果你在一个查询中多次使用一个表 ( 用别名 ) ，你必须为每一个别名获得一个锁。

WRITE 锁通过比 READ 锁有更高的权限，以确保更新被尽快地处理。这就意味着，如果一个线程获得一个 READ 锁，而同时另外一个线程请求一个 WRITE 锁，并发的 READ 锁请求将等待直到 WRITE 线程得到了锁并释放了它。你可以使用 LOW_PRIORITY WRITE 锁，当该线程在等待 WRITE 锁时，它将允许其它的线程获得 READ 锁。你应该只使用 LOW_PRIORITY WRITE 锁，如果你确信这将是最后一次，当没有线程将拥有 READ 锁。

LOCK TABLES 工作如下：

以内部定义的次序排序所有被锁定的表 (从用户立场说，该次序是不明确的)。
如果一个表被以一个读锁和一个写锁锁定，将写锁放在读锁之前。
一次只锁定一个表，只到线程得到所有的锁定。

这个方案是为了确保，表锁定死锁释放。对于这个模式你仍然有些其它事情需要知道：

如果你对一个表使用一个 LOW_PRIORITY WRITE 锁定，这就意味着， MySQL 将等待这个锁，直到没有线程请求一个 READ 锁。当线程得到了 WRITE 锁，并等待获得锁定表列表中的下一个表的锁定时，其它所有的线程将等待 WRITE 锁被释放。如果这在你的应用程序中会引起一个严重的问题，你应该考虑将你的某些表转换为事务安全表。

你可以使用 KILL 安全地杀死一个正在表锁定的线程。查看章节 4.5.5 KILL 句法。

注意，你不应该锁定你正在对其使用 INSERT DELAYED 的表。这是因为，在这种情况下， INSERT 是通过单独的线程完成的。

通常，你不需要锁定任何表，因为所有单 UPDATE 语句都是原子的；其它的线程无法干扰当前执行的 SQL 语句。当你无论如何希望锁定表时，这里有一些情况：

如果你在一束表上运行许多操作，锁定你将要使用的表，这会更快一些。当然有不利的方面，其它线程将不能更新一个READ锁的表，并且没有其它线程要以读取一个WRITE锁的表。在LOCK TABLES下，某些事运行得更快一些的原因是，MySQL 将不会转储清除被锁定表键高速缓冲，直到UNLOCK TABLES被调用 (通常键高速缓冲在每个 SQL 语句后都会被转储清除)。这将加速在MyISAM表上的插入、更新、删除。
如果你在 MySQL 中正在使用一个不支持事务的存储引擎，如果你希望能确保没有其它的线程会出现在一个SELECT和一个UPDATE之间，你必须使用LOCK TABLES。下面的示例显示为了安全地执行，这里需要LOCK TABLES：