时间:2021-07-01 10:21:17 帮助过:15人阅读
作用:
一般来说,事务是必须满足4个条件ACID:Atomicity(原子性)、Consistency(一致性)、Isolation(隔离性)、Durability(持久性)
术语 | 描述 |
---|---|
Start Transaction | 开启事务 |
End Transaction | 事务结束 |
Commit Transaction | 提交事务 |
Rollback Transaction | 回滚事务 |
BEGIN 或 START TRANSACTION
# 显式地开启一个事务
COMMIT 或者 COMIT WORK
# COMMIT 会提交事务,并使已对数据库进行的所有修改成为永久性的
ROLLBACK 或者 ROLLBACK WORK
# 回滚会结束用户的事务,并撤销正在进行的所有未提交的修改
SAVEPOINT identifier
# SAVEPOINT 允许在事务中创建一个保存点,一个事务中可以有多个 SAVEPOINT
RELEASE SAVEPOINT identifier
# 删除一个事务的保存点,当没有指定的保存点时,执行该语句会抛出一个异常
ROLLBACK TO identifier
# 把事务回滚到标记点
SET TRANSACTION
# 用来设置事务的隔离级别。InnoDB 存储引擎提供事务的隔离级别有READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ 和 SERIALIZABLE
在日常生活中,比如张三有15620元钱(在支付宝上面),李四有240元,现在张三要给李四转600元。这时候我们需要数据库中,在张三的15620上减掉600,在李四的240上面加上600。这是俩个mysql的语句,但是如果我们执行的时候,在减掉张三的语句成功执行之后,第二句语句执行失败(因为某一种原因)。那是不是这600块就凭空消失了呢?很明显,支付宝不可能让这样的事情发生。所以我们要把这俩个语句绑在一块,要么一起执行成功,要么就都执行失败。
# -*- coding: UTF-8 -*-
import MySQLdb
#包的导入
db = MySQLdb.connect("ip地址,本机为localhost","用户名","密码","表名")
#打开数据库的连接
cursor = db.cursor()
#使用cursor()方法获得操作游标
try:
# 执行sql语句
cursor.execute("update account set money=money-600 where name='zhangsan'")
cursor.execute("update account set money=money+600 where name='lisi'")
# 提交到数据库执行
db.commit()
except:
# 发生错误时回滚 回滚到获取游标的位置开始重新执行 看代码上面的文字有说明
db.rollback()
db.close()
#关闭数据库的连接
在MySQL中,实现了这四种隔离级别,分别有可能产生问题如下所示
隔离级别 | 脏读 | 不可重复读 | 幻读 |
---|---|---|---|
Read Uncommitted(读未提交) | T | T | T |
Read Committed(读已提交) | F | T | T |
Repeatable Read(可重复读) | F | F | T |
Serializable(可串行化) | F | F | F |
InnoDB引擎的锁机制:InnoDB支持事务,支持行锁和表锁用的比较多,Myisam不支持事务,只支持表锁
共享锁(S):允许一个事务去读一行,阻止其他事务获得相同数据集的排他锁
排他锁(X):允许获得排他锁的事务更新数据,阻止其他事务取得相同数据集的共享读锁和排他写锁
意向共享锁(IS):事务打算给数据行加行共享锁,事务在给一个数据行加共享锁前必须先取得该表的IS锁
意向排他锁(IX):事务打算给数据行加行排他锁,事务在给一个数据行加排他锁前必须先取得该表的IX锁
说明:
共享锁和排他锁都是行锁,意向锁都是表锁,应用中我们只会使用到共享锁和排他锁,意向锁是mysql内部使用的,不需要用户干预
对于UPDATE、DELETE和INSERT语句,InnoDB会自动给涉及数据集加排他锁(X);对于普通SELECT语句,InnoDB不会加任何锁,事务可以通过以下语句显示给记录集加共享锁或排他锁。
共享锁(S):SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。
排他锁(X):SELECT * FROM table_name WHERE ... FOR UPDATE。
对于锁定行记录后需要进行更新操作的应用,应该使用Select...For update 方式,获取排它锁。(用共享锁,在读了之后再写会阻塞,会导致死锁)
这里说说Myisam:MyISAM在执行查询语句(SELECT)前,会自动给涉及的所有表加读锁,在执行更新操作(UPDATE、DELETE、INSERT等)前,会自动给涉及的表加写锁
InnoDB行锁是通过给索引上的索引项加锁来实现的,因此InnoDB这种行锁实现特点意味着:只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁
悲观锁:悲观锁,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)
使用select…for update会把数据给锁住,不过我们需要注意一些锁的级别,MySQL InnoDB默认Row-Level Lock,所以只有「明确」地指定主键(或有索引的地方),MySQL 才会执行Row lock (只锁住被选取的数据) ,否则MySQL 将会执行Table Lock (将整个数据表单给锁住)
乐观锁:
乐观锁( Optimistic Locking ) 相对悲观锁而言,乐观锁假设认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则让返回用户错误的信息,让用户决定如何去做(一般是回滚事务)。那么我们如何实现乐观锁呢,一般来说有以下2种方式:
总结:两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。
另外,高并发情况下个人认为乐观锁要好于悲观锁,因为悲观锁的机制使得各个线程等待时间过长,极其影响效率,乐观锁可以在一定程度上提高并发度
表级锁(table-level locking):MyISAM和MEMORY存储引擎
行级锁(row-level locking) :InnoDB存储引擎
页面锁(page-level-locking):BDB存储引擎
表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。
行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。
页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。
详见
MySQL事务
标签:行记录 读一行 开始 时间 mic close HERE 共享锁 cursor