MySQL 支持对 MyISAM 和 MEMORY 存储引擎的表进行表级锁定，对 BDB 存储引擎的表进行页级锁定，对 InnoDB 存储引擎的表进行行级锁定。默认情况下，表锁和行锁都是自动获得的，不需要额外的命令。但是在有的情况下，用户需要明确地进行锁表或者进行事务的控制，以便确保整个事务的完整性，这样就需要使用事务控制和锁定语句来完成。
1) LOCK TABLE 和 UNLOCK TABLE
LOCK TABLES 可以锁定用于当前线程的表。如果表被其他线程锁定，则当前线程会等待，直到可以获取所有锁为止。
UNLOCK TABLES 可以释放当前线程获得的任何锁定。当前线程执行另一个 LOCK TABLES 时，或当与服务器的连接被关闭时，所有由当前线程锁定的表被隐含的解锁，具体语法如下
LOCK TABLES
tbl_name [AS alias] {READ [LOCAL]|[LOW_PRIORITY] WRITE}
[,tbl_name [AS alias] {READ [LOCAL]|[LOW_PRIORITY] WRITE}] ...
UNLOCK TABLES
2) 事务控制
MySQL 通过 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等语句支持本地事务，具体语法如下
START TRANSACTION|BEGIN [WORK]
COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
SET AUTOCOMMIT={0|1}
START TRANSACTION 或 BEGIN 语句可以开始一项新的事务。
COMMIT 和 ROLLBACK 用来提交或者回滚事务
CHAIN 和 RELEASE 子句分别用来定义在事务提交或者回滚之后的操作，CHAIN 会立即启动一个新事物，并且和刚才的事务具有相同的隔离级别，RELEASE 则会断开和客户端的连接。
SET AUTOCOMMIT 可以修改当前连接的提交方式，如果设置了 SET AUTOCOMMIT = 0 ，则设置之后的所有事务都需要通过明确地命令进行提交或者回滚。
- 默认情况下，MySQL是自动提交的，如果需要通过明确的 Commit 和 Rollback 来提交和回滚事务，那么就需要通过明确地事务控制命令来开始事务，这是和 Oracle 的事务管理明显不同的地方。如果应用是从 Oracle 数据库迁移到 MySQL 数据库，则需要确保应用中是否对事务进行了明确地管理。
- 如果只是对某些语句需要进行事务控制，则使用 START TRANSACTION 语句开始一个事务比较方便，这样事务结束之后可以自动回到自动提交的方式，如果希望所有事务都不是自动提交的，那么通过修改 AUTOCOMMIT 来控制事务比较方便，这样不用在每个事务开始的时候再执行 START TRANSACTION 语句。
- 如果在锁表期间，用 START TRANSACTION 命令开始一个新事物，会造成一个隐含的 UNLOCK TABLES 被执行。
- 在同一个事务中，最好不使用不同存储引擎的表，否则 ROLLBACK 时需要对非事务类型的表进行特别的处理，因为 COMMIT、ROLLBACK 只能对事务类型的表进行提交和回滚。
- 对 LOCK 方式加的表锁，不能通过 ROLLBACK 进行回滚。
- 通常情况下，只对提交的事务记录到二进制的文件中，但是如果一个事务中包含非事务类型的表，那么回滚操作也会被记录到二进制日志中，以确保非事务类型表的更新可以被复制到从数据库(Slave)中。
- 和 Oracle 的事务管理相同，所有的 DDL 语句是不能回滚的，并且部分的 DDL 语句会造成隐式的提交。
- 在事务中可以通过定义 SAVEPOINT，指定回滚事务的一个部分，但是不能指定提交事务的一个部分。对于复杂的应用，可以定义多个不同的 SAVEPOINT，满足不同的条件时，回滚不同的 SAVEPOINT。需要注意的是，如果定义了相同名字的 SAVEPOINT，则后面定义的 SAVEPOINT 会覆盖之前的定义。对于不再需要使用的 SAVEPOINT，可以通过 RELEASE SAVEPOINT 命令删除 SAVEPOINT，删除后的 SAVEPOINT 不能再执行 ROLLBACK TO SAVEPOINT 命令。
3) 分布式事务
- MySQL 从5.0.3开始支持分布式事务，当前分布式事务只支持 InnoDB 存储引擎。一个分布式事务会涉及多个行动，这些行动本身是事务性的。所有行动都必须一起成功完成，或者一起被回滚。
- 在 MySQL 中，使用分布式事务的应用程序设计一个或多个资源管理器和一个事务管理器。
资源管理器(RM)用于提供通向事务资源的途径。数据库服务器是一种资源管理器，该管理器必须可以提交或回滚由 RM 管理的事务。例如，多台 MySQL 数据库作为多台资源管理器或者几台 MySQL 服务器和几台 Oracle 服务器作为资源管理器。
事务管理器(TM)用于协调作为一个分布式事务一部分的事务。TM 与管理每个事务的 RMs 进行通信。在一个分布式事务中，各个单个事务均是分布式事物的“分支事务”。分布式事务和各分支通过一种命名方法进行标识。
- MySQL 执行 XA MySQL 时，MySQL 服务器相当于一个用于管理分布式事务中的 XA 事务的资源管理器。与 MySQL 服务器连接的客户端相当于事务管理器。
- 要执行一个分布式事务，必须知道这个分布式事务涉及了哪些资源管理器，并且把每个资源管理器的事务执行到事务可以被提交或回滚时。根据每个资源管理器报告的有关执行情况的内容，这些分支事务必须作为一个原子性操作全部提交或回滚。要管理一个分布式事务，必须要考虑任何组件或连接网络可能会出现的故障。
- 用于执行分布式事务的过程使用两阶段进行提交，发生时间由分布式事务的各个分支需要进行的行动已经被执行之后。
在第一阶段，所有的分支被预备好。即他们被 TM 告知要准备提交。通常，这意味着用于管理分支的每个 RM 会记录对于被稳定保存的分支的行动。分支指示是否他们可以这么做。这些结果被用于第二阶段。
在第二阶段，TM 告知 RMs 是否要提交或回滚。如果在预备分支时，所有的分支指示他们能够提交，则所有的分支被告知要提交。如果在预备时，有任何分支指示它将不能提交，则所有的分支被回滚。
在有些情况下，一个分布式事务可能会使用一阶段提交。例如，当一个事务管理器发现，一个分布式事务只由一个事务资源组成(即单一分支)，则该资源可以被告知同时进行预备和提交。
- 分布式事务(XA 事务)的语法
启动：
XA {START|BEGIN} xid [JOIN|RESUME]
XA START xid 用于启动一个带给定 xid 值的 XA 事务。每个 XA 事务必须有一个唯一的 xid 值，因此该值当前不能被其他的 XA 事务使用。xid 是一个 XA 事务标识符，用来唯一标识一个分布式事务。xid 值有客户端提供，或由 MySQL 服务器生成。xid 值包含 1~3个部分：
xid: gtrid[, bqual[, formatID]]
gtrid是一个分布式事务标识符，相同的分布式事务应该使用相同的 gtrid，这样可以明确知道 XA 事务属于哪个分布式事务。
bqual 是一个分支限定符，默认值是空串。对于一个分布式事务中的每个分支事务，bqual 值必须是唯一的。
formatID 是一个数字，用于标识由 gtrid 和 bqual 值使用的格式，默认值是1。
使事务进入 PREPARE 状态，也就是两阶段提交的第一个提交阶段：
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid
提交或者回滚具体的事务分支，也就是两阶段提交的第二个提交阶段，分支事务被实际的提交或者回滚：
XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
返回当前数据库终于处于 PREPARE 状态的分支事务的详细信息：
XA RECOVER
- 分布式的关键在于如何确保分布式事务的完整性，以及在某个分支出现问题时的故障解决。XA 的相关命令就是提供给应用如何在多个独立的数据库之间进行分布式事务的管理，包括启动一个分布式事务、使事务进入准备阶段以及事务的实际提交回滚操作等。
- 虽然 MySQL 支持分布式事务，但是如果分支事务在达到 PREPARE 状态时，数据库异常重新启动，服务器重新启动以后，可以继续对分支事务进行提交或回滚操作，但是提交的事务没有写 binlog，存在一定的隐患，可能导致使用 binlog 恢复丢失部分数据。如果存在复制的数据库，则有可能导致主从数据库的数据不一致。
- 使用 mysqlbinlog 查看 binlog，可以确认最后提交的这个分支事务并没有记录到 binlog 中，因为复制和灾难恢复都是依赖于 binlog的，所以 binlog 的确实会导致复制环境的不同步，以及使用 binlog 恢复丢失部分数据。