Mysql：语法：事务管理

mysql的存储引擎有：事务型、非事务型 之分。

mysql支持本地事务——即 各个连接会话 可以自由控制事务的处理，mysql默认是事务自动提交模式。

不同的事务型引擎能够支持的事务功能 也不相同。

基本上mysql的innodb引擎是功能全面，支持事务特性最多的引擎！


set autocommit = {1 | 0} ：1为默认值——自动提交

start transaction | begin 开始事务

commit 提交事务

rollback 回滚事务

xa事务

保存点

SET TRANSACTION

Syntax

SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
{
READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SERIALIZABLE
}

This statement sets the transaction isolation level globally, for the current session, or for the next transaction:

With the

GLOBAL

keyword, the statement sets the default transaction level globally for all subsequent sessions. Existing sessions are unaffected.

With the

SESSION

keyword, the statement sets the default transaction level for all subsequent transactions performed within the current session.

Without any

SESSION

or

GLOBAL

keyword, the statement sets the isolation level for the next (not started) transaction performed within the current session.

A change to the global default isolation level requires the

SUPER

privilege. Any session is free to change its session isolation level (even in the middle of a transaction), or the isolation level for its next transaction.

To set the global default isolation level at server startup, use the

--transaction-isolation=
level
[/i]

option to mysqld[/b] on the command line or in an option file. Values of

level

[/i] for this option use dashes rather than spaces, so the allowable values are

READ-UNCOMMITTED

,

READ-COMMITTED

,

REPEATABLE-READ

, or

SERIALIZABLE

. For example, to set the default isolation level to

REPEATABLE READ

, use these lines in the

[mysqld]

section of an option file:

[mysqld]
transaction-isolation = REPEATABLE-READ

To determine the global and session transaction isolation levels at runtime, check the value of the

tx_isolation

system variable:

SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

InnoDB

supports each of the translation isolation levels described here using different locking strategies. The default level is

REPEATABLE READ

. For additional information about

InnoDB

record-level locks and how it uses them to execute various types of statements, see Section 13.6.8.4, “

InnoDB

Record, Gap, and Next-Key Locks”, and Section 13.6.8.6, “Locks Set by Different SQL Statements in

InnoDB

”.

The following list describes how MySQL supports the different transaction levels:

READ UNCOMMITTED

SELECT

statements are performed in a nonlocking fashion, but a possible earlier version of a row might be used. Thus, using this isolation level, such reads are not consistent. This is also called a “dirty read.” Otherwise, this isolation level works like

READ COMMITTED

.

READ COMMITTED

A somewhat Oracle-like isolation level with respect to consistent (nonlocking) reads: Each consistent read, even within the same transaction, sets and reads its own fresh snapshot. See Section 13.6.8.2, “Consistent Nonlocking Reads”.

For locking reads (

SELECT

with

FOR UPDATE

or

LOCK IN SHARE MODE

),

InnoDB

locks only index records, not the gaps before them, and thus allows the free insertion of new records next to locked records. For

UPDATE

and

DELETE

statements, locking depends on whether the statement uses a unique index with a unique search condition (such as

WHERE id = 100

), or a range-type search condition (such as

WHERE id > 100

). For a unique index with a unique search condition,

InnoDB

locks only the index record found, not the gap before it. For range-type searches,

InnoDB

locks the index range scanned, using gap locks or next-key (gap plus index-record) locks to block insertions by other sessions into the gaps covered by the range. This is necessary because “phantom rows” must be blocked for MySQL replication and recovery to work.

Note

In MySQL 5.1, if the

READ COMMITTED

isolation level is used or the

innodb_locks_unsafe_for_binlog

system variable is enabled, there is no

InnoDB

gap locking except for foreign-key constraint checking and duplicate-key checking. Also, record locks for nonmatching rows are released after MySQL has evaluated the

WHERE

condition.

As of MySQL 5.1, if you use

READ COMMITTED

or enable

innodb_locks_unsafe_for_binlog

, you must use row-based binary logging.

REPEATABLE READ

This is the default isolation level for

InnoDB

. For consistent reads, there is an important difference from the

READ COMMITTED

isolation level: All consistent reads within the same transaction read the snapshot established by the first read. This convention means that if you issue several plain (nonlocking)

SELECT

statements within the same transaction, these

SELECT

statements are consistent also with respect to each other. See Section 13.6.8.2, “Consistent Nonlocking Reads”.

For locking reads (

SELECT

with

FOR UPDATE

or

LOCK IN SHARE MODE

),

UPDATE

, and

DELETE

statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition,

InnoDB

locks only the index record found, not the gap before it. For other search conditions,

InnoDB

locks the index range scanned, using gap locks or next-key (gap plus index-record) locks to block insertions by other sessions into the gaps covered by the range.

SERIALIZABLE

This level is like

REPEATABLE READ

, but

InnoDB

implicitly converts all plain

SELECT

statements to

SELECT ... LOCK IN SHARE MODE

if autocommit is disabled. If autocommit is enabled, the

SELECT

is its own transaction. It therefore is known to be read only and can be serialized if performed as a consistent (nonlocking) read and need not block for other transactions. (This means that to force a plain

SELECT

to block if other transactions have modified the selected rows, you should disable autocommit.)

不能被事务回滚的语句 ：一般DDL语句不能被事务回滚，你不应该在事务中包含此类语句

隐式提交的语句：一句话，如果没有什么特特殊的地方，mysql总是隐式提交，除非你想自行控制事务

The statements listed in this section (and any synonyms for them) implicitly end a transaction, as if you had done a

COMMIT

before executing the statement.

定义 或 修改 数据库对象的 DDL语句

ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME

,

ALTER EVENT

,

ALTER PROCEDURE

,

ALTER TABLE

,

CREATE DATABASE

,

CREATE EVENT

,

CREATE INDEX

,

CREATE PROCEDURE

,

CREATE TABLE

,

DROP DATABASE

,

DROP EVENT

,

DROP INDEX

,

DROP PROCEDURE

,

DROP TABLE

,

RENAME TABLE

,

TRUNCATE TABLE

.

ALTER FUNCTION

,

CREATE FUNCTION

and

DROP FUNCTION

also cause an implicit commit when used with stored functions, but not with UDFs. (

ALTER FUNCTION

can only be used with stored functions.)

ALTER TABLE

,

CREATE TABLE

,

DROP TABLE

临时表不会引起隐式提交

The

CREATE TABLE

statement in

InnoDB

is processed as a single transaction. This means that a

ROLLBACK

from the user does not undo

CREATE TABLE

statements the user made during that transaction.

Beginning with MySQL 5.1.3,

ALTER VIEW

,

CREATE TRIGGER

,

CREATE VIEW

,

DROP TRIGGER

, and

DROP VIEW

cause an implicit commit.

Beginning with MySQL 5.1.15,

CREATE TABLE ... SELECT

causes an implicit commit before and after the statement is executed when you are creating nontemporary tables. (No commit occurs for

CREATE TEMPORARY TABLE ... SELECT

.) This is to prevent an issue during replication where the table could be created on the master after a rollback, but fail to be recorded in the binary log, and therefore not replicated to the slave. For more information, see Bug#22865.

会修改系统库

mysql

的操作. Beginning with MySQL 5.1.3,

CREATE USER

,

DROP USER

, and

RENAME USER

cause an implicit commit. Beginning with MySQL 5.1.23,

GRANT

,

REVOKE

, and

SET PASSWORD

statements cause an implicit commit.

事务控制和锁定语句.

BEGIN

,

LOCK TABLES

,

SET autocommit = 1

(if the value is not already 1),

START TRANSACTION

,

UNLOCK TABLES

.

UNLOCK TABLES

commits a transaction only if any tables currently have been locked with

LOCK TABLES

. This does not occur for

UNLOCK TABLES

following

FLUSH TABLES WITH READ LOCK

because the latter statement does not acquire table-level locks.

Transactions cannot be nested. This is a consequence of the implicit commit performed for any current transaction when you issue a

START TRANSACTION

statement or one of its synonyms.

Statements that cause an implicit commit cannot be used in an XA transaction while the transaction is in an

ACTIVE

state.

The

BEGIN

statement differs from the use of the

BEGIN

keyword that starts a

BEGIN ... END

compound statement. The latter does not cause an implicit commit. See Section 12.8.1, “

BEGIN ... END

Compound Statement Syntax”.

数据装载.

LOAD DATA INFILE

. Before MySQL 5.1.12,

LOAD DATA INFILE

caused an implicit commit for all storage engines. As of MySQL 5.1.12, it causes an implicit commit only for tables using the

NDB

storage engine. For more information, see Bug#11151.

系统管理语句.

CACHE INDEX

,

LOAD INDEX INTO CACHE

. Beginning with MySQL 5.1.10,

ANALYZE TABLE

,

CHECK TABLE

,

OPTIMIZE TABLE

, and

REPAIR TABLE

cause an implicit commit.