标签：行记录 读一行 开始 时间 mic close HERE 共享锁 cursor
作用：
一般来说，事务是必须满足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 允许在事务中创建一个保存点，一个事务中可以有多个 SAVEPOINTRELEASE 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存储引擎
表级锁：开销小，加锁快;不会出现死锁;锁定粒度大，发生锁冲突的概率最高,并发度最低。
行级锁：开销大，加锁慢;会出现死锁;锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
页面锁：开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间，并发度一般。
标签：行记录 读一行 开始 时间 mic close HERE 共享锁 cursor
原文地址：https://www.cnblogs.com/pankypan/p/11078913.html
