MySQL事务和锁04

• 持有锁的会话可以读取表(但不能写入表)。

• 多个会议可获得READ 同时锁好桌子。

• 其他会议可以阅读表格,而不需要显式获取READ 锁定。

• …LOCAL 使不冲突 INSERT 由其他会话执行的语句(并发插入),在锁举行期间执行。(见 8.11.3节,”并发插入” .) However, READ LOCAL 如果您要使用服务器外部的进程操作数据库,则无法使用此锁。用于 InnoDB 表格,READ LOCAL 就像READ .

• 持有锁的会话可以读写表.

• 只有持有锁的会话才能访问表.在释放锁之前,任何其他会话都无法访问它。

• 将表格的请求按其他会话进行锁定,同时WRITE 上锁了。

• …LOW_PRIORITY 修饰不起作用。在以前的mysql版本中,它影响了锁定行为,但这不再是真的。现在它被弃用了,它的使用产生了一个警告。使用WRITE 没有 LOW_PRIORITY 相反。

mysql> LOCK TABLES t1 READ;
mysql> SELECT COUNT(*) FROM t1;
+----------+
| COUNT(*) |
+----------+
|        3 |
+----------+
mysql> SELECT COUNT(*) FROM t2;
ERROR 1100 (HY000): Table 't2' was not locked with LOCK TABLES

mysql> LOCK TABLE t WRITE, t AS t1 READ;
mysql> INSERT INTO t SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> INSERT INTO t SELECT * FROM t AS t1;

mysql> LOCK TABLE t READ;
mysql> SELECT * FROM t AS myalias;
ERROR 1100: Table 'myalias' was not locked with LOCK TABLES

mysql> LOCK TABLE t AS myalias READ;
mysql> SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> SELECT * FROM t AS myalias;

LOCK TABLES 或UNLOCK TABLES 当应用到分区表时,总是锁定或打开整个表;这些语句不支持分区锁修剪。看 第22.6.4节,”分隔和锁定” .

• 会话可以显式地释放锁 UNLOCK TABLES .

• 如果会议发布了ALOCK TABLES 声明在已经持有锁的情况下获取锁,在授予新锁之前,它的现有锁会被隐式释放。

• 如果一个会话开始一个事务(例如 START TRANSACTION ),一个隐含的 UNLOCK TABLES 执行,这导致释放现有的锁。(有关表锁定与事务之间的互动的其他信息,请参阅 表锁定和事务的相互作用 .)

如果你用ALTER TABLE 在上锁的桌子上,它可能会被打开。例如,如果你试图ALTER TABLE 操作,结果可能是错误 .要处理这个,在第二个更改之前再次锁定表。另见 B.3.6.1节,”更改表格的问题” . Table 'tbl_name' was not locked with LOCK TABLES

• LOCK TABLES在试图锁定表之前,没有事务安全地隐式提交任何活动事务。

• UNLOCK TABLES 隐式提交任何活动事务,但仅限于LOCK TABLES 是用来获取表锁的。例如,在下面的一组声明中, UNLOCK TABLES 释放全局读锁,但不提交事务,因为没有表锁有效:

  FLUSH TABLES WITH READ LOCK;
  START TRANSACTION;
  SELECT ... ;
  UNLOCK TABLES;

• 开始交易(例如,用 START TRANSACTION )隐式提交任何当前事务并释放现有表锁。

• FLUSH TABLES WITH READ LOCK 获取全局读锁而不是表锁,因此它不受与表锁相同的行为约束。 LOCK TABLES 和 UNLOCK TABLES 关于表锁定和隐式提交。例如, START TRANSACTION 不释放全局读锁。看 第13.7.6.3节,”齐平陈述” .

• 其他隐式导致事务被提交的语句不会释放现有的表锁。此类声明的清单见 第13.3.3节,”造成默示犯罪的声明” .

• 正确的使用方式LOCK TABLES 和 UNLOCK TABLES 有事务表,例如 InnoDB 表,是开始交易SET autocommit = 0 (非) START TRANSACTION )然后LOCK TABLES ,以及不打电话 UNLOCK TABLES 直到您显式地提交事务。例如,如果你需要写到表上 t1 从餐桌上读到 t2 ,你可以这样做:

  SET autocommit=0;
  LOCK TABLES t1 WRITE, t2 READ, ...;
  ... do something with tables t1 and t2 here ...
  COMMIT;
  UNLOCK TABLES;

  当你打电话的时候LOCK TABLES , InnoDB 内部使用自己的表锁,mysql使用自己的表锁。 InnoDB 下一次提交时释放其内部表锁,但要释放其表锁,必须调用。 UNLOCK TABLES .你不应该 autocommit = 1 ,因为那时InnoDB 在呼叫后立即释放其内部表锁。LOCK TABLES ,而且死锁很容易发生。 InnoDB 不需要获得内部表锁autocommit = 1 ,帮助旧的应用程序避免不必要的死锁。

• ROLLBACK 不释放表锁。

• 这些锁的使用时间与那些显式的LOCK TABLES 声明。

• 触发器中使用的表上的锁取决于表是否仅用于读取。如果是这样,读锁就足够了。否则,将使用写入锁。

• 如果一个表被明确锁定用于阅读 LOCK TABLES ,但需要为编写锁定,因为它可能在触发器中被修改,而不是被读取锁定。(也就是说,由于表在触发器中的外观而需要隐式写锁,这将导致表的显式读锁请求转换为写锁请求。)

LOCK TABLES t1 WRITE, t2 READ;

CREATE TRIGGER t1_a_ins AFTER INSERT ON t1 FOR EACH ROW
BEGIN
  UPDATE t4 SET count = count+1
      WHERE id = NEW.id AND EXISTS (SELECT a FROM t3);
  INSERT INTO t2 VALUES(1, 2);
END;

• t1 已锁定用于写作 WRITE 锁定请求。

• t2 是锁定的,即使请求是READ 锁定。出现这种情况是因为t2 是插入到触发器中的,所以READ 请求被转换成WRITE 请求。

• t3因为它只能从触发器内部读取。

• t4因为它可能在触发器中更新。

mysql.help_category
mysql.help_keyword
mysql.help_relation
mysql.help_topic
mysql.proc
mysql.time_zone
mysql.time_zone_leap_second
mysql.time_zone_name
mysql.time_zone_transition
mysql.time_zone_transition_type

• 如果你要在一组 MyISAM 表,锁定你将要使用的桌子要快得多。锁定的 MyISAM 表加速了插入、更新或删除的速度,因为mysql在锁定表之前不会冲洗密钥缓存 UNLOCK TABLES 是叫。通常,键缓存在每个SQL语句之后进行刷新。

  锁定表的缺点是没有一个会话可以更新READ -上锁桌(包括持有锁的桌),任何会议都无法进入A WRITE -上锁的桌子不是拿锁的那张。

• 如果您正在使用非事务性存储引擎的表,则必须使用LOCK TABLES 如果您想确保没有其他会话修改表 SELECT 以及 UPDATE .这里的例子要求LOCK TABLES 安全执行:

  LOCK TABLES trans READ, customer WRITE;
  SELECT SUM(value) FROM trans WHERE customer_id=some_id;
  UPDATE customer
    SET total_value=sum_from_previous_statement
    WHERE customer_id=some_id;
  UNLOCK TABLES;

  没有LOCK TABLES ,另一个会话可能会在 trans 执行之间的表格 SELECT 和 UPDATE 声明。