mysql事务

最新推荐文章于 2025-06-06 13:42:58 发布

原创最新推荐文章于 2025-06-06 13:42:58 发布 · 159 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#MYSQL

mysql 专栏收录该内容

6 篇文章

订阅专栏

Mysql服务器逻辑架构图

最上层不是Mysql所独有的，大多数客服端/服务端工具都有类似架构。比如连接处理，授权认证，安全等。
大多数mysql核心服务都在这一层，包括查询解析，分析，优化，缓存以及所有的内置函数（例如，日期，时间，数学和加密函数等）。所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等
存储引擎。

事务的四个特性：

原子性(Atomicity)
一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功要么全部失败回滚。
一致性(consistency)
数据库总是从一个一致性状态装换到另一个一致性状态。
隔离性(isolation)
一个事务所做的修改在最终提交之前，对其他事务是不可见的。
持久性(durability)
一旦事务提交所做的修改就会永久保存到数据库中。
mysql的事务是由下层的存储引擎实现的，所以在同一个事务中，使用多种存储引擎是不可靠的，如果事务需要回滚非事务类型的变更就没办法撤销，会导致数据不一致状态

事务的例子

START TRANSACTION
SELECT balance FROM checking WHERE customer_id =123
UPDATE checking SET balance= balance-200.00 WHERE customer_id = 123
UPDATE saving SET balance = balance+200.00 WHERE customer_id = 123
COMMIT

隔离级别

1. READ UNCOMMITED(读未提交)
事务可以读取未提交的数据，也被称为脏读。
2. READ CIOMMITED(读提交)
一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别也称为不可重复读，因为两次执行同样的查询可能会得到不同的结果。
3. REPEATABLE READ(可重复读)
解决了脏读问题，但是无法解决幻读问题。所谓幻读，指的是当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取记录该范围的记录就会产生幻行。innodb和XtraDB通过多版本并发控制（MVCC，multiversion concurrency control）解决了这个问题。
5. SERIALIZABLE(可串行化)
最高的隔离级别，解决了幻读。强制事务串行执行。

隔离级别	脏读可能性	不可重复读可能性	幻读可能性	加锁读
READ UNCOMMITED	Yes	Yes	Yes	No
READ CIOMMITED	No	Yes	Yes	No
REPEATABLE READ	No	No	Yes	No
SERIALIZABLE	No	No	No	Yes

设置当前会话的隔离级别：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

死锁

死锁是两个或多个事务在同一个资源上相互占用，并请求对方占用的资源导致的恶性循环现象。
例如：

事务1：
START TRANSACTION;
UPDATE stockprice SET close = 16 WHERE stock_id = 4 and date = '2019-01-10';
UPDATE stockprice SET close = 15 WHERE stock_id = 3 and date = '2019-01-11';
COMMIT;
事务2：
START TRANSACTION;
UPDATE stockprice SET close = 25 WHERE stock_id = 3 and date = '2019-01-11';
UPDATE stockprice SET close = 26 WHERE stock_id = 4 and date = '2019-01-10';
COMMIT;

当两个事务都执行到第一条update语句时，更新了一条数据，也锁定了这一行，再每个事务都尝试执行第二条数据，发现已经被锁定，然后两个事务都等待对方释放锁，就会造成死锁。
为了解决这个问题，数据库都设有死锁检测和死锁超时机制。innodb目前的处理死锁方法是，将持有最少行级排他锁的事务进行回滚。

事务日志

事务日志可以帮助事务提高效率。使用事务日志，存储引擎在修改表数据时，只需要修改其内存拷贝，再把修改的记录持久化到硬盘的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用追加，因此写日志操作是磁盘上一小块区域的顺序io，不像随机io需要在磁盘多次移动磁头，所以相对来说，速度回快的多。事务日志持久化之后可以慢慢在后台写回磁盘。如果数据修改已记录到事务日志中并持久化，这时系统奔溃，重启后存储引擎可以自动恢复这一部分修改的数据。