Mysql事务原理与优化

Mysql事务原理与优化

解决多事物并发问题-->事务隔离机制、锁机制、MVCC多版本并发控制隔离机制、日志机制
事务及其ACID属性

事务是一组操作要么全部成功，要么全部失败，目的是为了保证数据最终的一致性。

• 原子性：当前事务的操作要么同时成功，要么同时失败。原子性由undo log日志来实现。
  
• 一致性 ：使用事务的最终目的，由其它3个特性以及业务代码正确逻辑来实现。
  
• 隔离性 ：在事务并发执行时，他们内部的操作不能互相干扰。隔离性由MySQL的各种锁以及MVCC机制来实现。
  
• 持久性 ：一旦提交了事务，它对数据库的改变就应该是永久性的。持久性由redo log日志来实现。
  

原子性、隔离性、持久性 ==》 一致性

并发事务处理带来的问题

更新丢失(Lost Update)或脏写
当两个或多个事务选择同一行数据修改，有可能发生更新丢失问题，即最后的更新覆盖
了由其他事务所做的更新。
脏读（Dirty Reads）
事务A读取到了事务B已经修改但尚未提交的数据
不可重读（Non-Repeatable Reads）
事务A内部的相同查询语句在不同时刻读出的结果不一致
幻读（Phantom Reads）
事务A读取到了事务B提交的新增数据
事务隔离级别

“脏读”、“不可重复读”和“幻读”,其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制来解决。
隔离级别脏读(Dirty Read)不可重复读(NonRepeatable Read)幻读(Phantom Read)读未提交(Read uncommitted)可能可能可能读已提交(Read committed)不可能可能可能可重复读(Repeatable read)不可能不可能可能可串行化(Serializable)不可能不可能不可能数据库的事务隔离越严格,并发副作用越小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上“串行化”进行,这显然与“并发”是矛盾的。
同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读"和“幻读”并不敏感,可能更关心数据并发访问的能力。
查看当前数据库的事务隔离级别: show variables like 'tx_isolation';
设置事务隔离级别：set tx_isolation='REPEATABLE-READ';
Mysql默认的事务隔离级别是可重复读，用Spring开发程序时，如果不设置隔离级别默认用Mysql设置的隔离级别，如果Spring设置了就用已经设置的隔离级别
事务隔离级别案例分析

1. CREATE TABLE `account` (
2.         `id` int(11) NOT NULL AUTO_INCREMENT,
3.         `name` varchar(255) DEFAULT NULL,
4.         `balance` int(11) DEFAULT NULL,
5.         PRIMARY KEY (`id`)
6. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
7. INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('lilei', '450');
8. INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('hanmei', '16000');
9. INSERT INTO `test`.`account` (`name`, `balance`) VALUES ('lucy', '2400');

复制代码

读未提交

B事务的更新还未提交，A事务已经读取到B的更新了。属于脏读
graph TD    A1[事务A：设置隔离级为read-uncommitted
set tx_isolation='read-uncommitted'] --> A2[事务A：查询account初始值（如id=1余额400）]    A2 --> B1[事务B：更新account（如id=1余额改为450）
事务未提交]    B1 --> A3[事务A：查询到B未提交的更新（余额450）
→ 产生脏数据]    A3 --> B2[事务B：事务回滚（更新被撤销）]    B2 --> A4[事务A：执行update id=1余额-50
实际用回滚后的值400计算，结果350
→ 暴露脏读导致的数据一致性问题]    style A3 fill:#FFE6E6,stroke:#FF4444,stroke-width:1px    style A4 fill:#FFF3E0,stroke:#FF9800,stroke-width:1px    读已提交

事务B的更新提交之后，事务A就立刻可以查询到。但是产生了不可重复读问题，在同一事务的不同时间段查询到的值不一样
graph TD    A1[事务A：设置隔离级为read-committed
set tx_isolation='read-committed'] --> A2[事务A：查询account所有记录（如id=1余额400）]    A2 --> B1[事务B：更新account（id=1改为450）
事务未提交]    B1 --> A3[事务A：再次查询
→ 读不到B未提交的更新（仍显示400）
解决脏读问题]    A3 --> B2[事务B：事务提交]    B2 --> A4[事务A：第三次查询
→ 读到B提交的更新（显示450）
→ 产生不可重复读问题]    style A3 fill:#E8F5E9,stroke:#4CAF50,stroke-width:1px    style A4 fill:#FFF3E0,stroke:#FF9800,stroke-width:1px    可重复读

事务B不管更新多少次，事务A读取到的值，一直都是事务A刚开始的版本。
此时事务A是快照读，但是在事务A中的更新操作是当前读
graph TD    A1[事务A：设置隔离级为repeatable-read
set tx_isolation='repeatable-read'] --> A2[事务A：查询account（id=1余额400）]    A2 --> B1[事务B：更新account（id=1改为350）并提交]    B1 --> A3[事务A：再次查询
→ 仍显示400（快照读，历史版本）
解决不可重复读问题]    A3 --> A4[事务A：执行update id=1余额-50
→ 用当前版本350计算，结果300（当前读）
数据一致性未破坏]    A4 --> B2[事务B：插入新数据（如id=4余额500）并提交]    B2 --> A5[事务A：查询所有记录
→ 读不到新增的id=4（快照读）
未出现查询幻读]    A5 --> A6[事务A：执行update id=4余额=888
→ 更新成功，再次查询能看到id=4
→ 幻读在更新时可见]    style A3 fill:#E8F5E9,stroke:#4CAF50,stroke-width:1px    style A5 fill:#E8F5E9,stroke:#4CAF50,stroke-width:1px    串行化

不同事物之间的读写操作都是串行执行，需要排队
graph TD    A1[事务A：设置隔离级为serializable
set tx_isolation='serializable'] --> A2[事务A：查询account初始值（如id=1余额400）]    A2 --> B1{事务B：更新操作}    B1 -->|更新id=1记录| B1a[事务B：操作被阻塞
→ 因A查询加行锁]    B1 -->|更新id=2记录| B1b[事务B：操作成功
→ 不同记录无锁冲突]    A2 --> B2[事务A：执行范围查询（如id B3[事务B：在范围内插入新数据（如id=3）
→ 操作被阻塞
解决幻读问题]    B3 --> A3[事务A：事务提交
→ 客户端B阻塞解除]    style B1a fill:#FFE6E6,stroke:#FF4444,stroke-width:1px    style B3 fill:#FFE6E6,stroke:#FF4444,stroke-width:1px    style A3 fill:#E8F5E9,stroke:#4CAF50,stroke-width:1px    事务问题定位

查询执行时间超过1秒的事务

1. SELECT * FROM information_schema.innodb_trx
2. WHERE TIME_TO_SEC( timediff( now(), trx_started ) ) > 1;

复制代码

强制结束事务
kill 事务对应的线程id(就是上面语句查出结果里的trx_mysql_thread_id字段的值)
大事务的影响

• 并发情况下，数据库连接池容易被撑爆
  
• 锁定太多的数据，造成大量的阻塞和锁超时
  
• 执行时间长，容易造成主从延迟
  
• 回滚所需要的时间比较长
  
• undo log膨胀
  
• 容易导致死锁
  

事务优化

• 将查询等数据准备操作放到事务外
  
• 事务中避免远程调用，远程调用要设置超时，防止事务等待时间太久
  
• 事务中避免一次性处理太多数据，可以拆分成多个事务分次处理
  
• 更新等涉及加锁的操作尽可能放在事务靠后的位置
  
• 能异步处理的尽量异步处理
  
• 应用侧(业务代码)保证数据一致性，非事务执行
  

来源：豆瓜网用户自行投稿发布，如果侵权，请联系站长删除