mysql事务

今天是学习计划的第三天，今天打算继续昨天探讨的事务问题。 所以，今天的学习内容是事务特性及隔离问题。 那事务都具有哪些特性呢？ 原子性：原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。 一致性：事务前后数据的完整性必须保持一致。 隔离性：事务的隔离性是指多个用户并发访问数据库时，一个用户的事务不能被其它用户的事务所干扰，多个并发事务之间数据要相互隔离。 持久性：持久性是指一个事务一旦提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响。 多个线程开启各自事务操作数据库中的数据时，数据库系统要负责隔离操作，以保证各个线程在获取数据时的准确性。如果不考虑隔离，可能会引发如下问题。 脏读 指一个事务读取了另外一个事务未提交的数据。 这是非常危险的。举个例子：假设A向B转账100元，对应的sql语句如下 update account set money = money - 100 where name = 'a'; update account set money = money + 100 where name = 'b'; 当第一条sql语句执行完，第二条还没执行(A未提交时)，如果此时B查询自己的账户，就会发现自己多了100元钱，如果A等B走后再回滚，B就会以为转账成功了，但是钱又返还给了A，从而导致B损失100元

学习计划的第四天，仍然是对数据库事务方面进行学习。毕竟数据库操作在后端开发中有着举足轻重的作用。 那么，今天的学习内容是：事务丢失更新问题及乐观锁、悲观锁机制。 话不多说，进入正题。 什么是事务的丢失更新问题？ 两个或多个事务更新同一行，但这些事务彼此之间都不知道其它事务进行的修改，因此第二个更改覆盖了第一个修改 。 这样说太抽象，举个例子：在数据库表中存在一条数据 id：100 name：张散 age：20 此时，两个管理员同时查询到了这条数据，此时，A管理员发现该数据的名字出错了，于是更新数据，将该数据改为 id：100 name：张三 age：20 然后A管理员提交了更新操作。这个时候，B管理员也发现该数据的年龄出错了，于是准备进行更改，但是B管理员根本就不知道A管理员进行了姓名的更改，于是B管理员进行了如下修改 id：100 name：张散 age：21 然后B管理员提交了更新操作。操作完成后，数据库表的数据变为了 id：100 name：张散 age：21 这时候问题就出现了，A管理员发现姓名出错进行了修改，而B管理员却把正确的名字给改了回去，B管理员的修改就覆盖了A管理员的修改，这种现象就是丢失更新。 贴张图方便大家理解。 那么该如何解决丢失更新问题呢？(丢失更新问题的解决) 悲观锁(Pessimistic Locking) 乐观锁(Optimistic Locking

事务的ACID特性: 原子性(atomicity):一个事务是一个不可分割的最小工作单位，事务中的所有操作要么都做，要么都不做。 一致性(consistency):事务前后数据的完整性必须保持一致.事务必须是使数据库从一个一致性状态变到另一个一致性状态,一致性与原子性是密切相关的。 隔离性(isolation):一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的,并发执行的各个事务之间不能互相干扰。有四种隔离级别 持久性(durability):指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。 隔离性的四种级别 来源： https://www.cnblogs.com/viczhang/p/11410388.html

Pymysql介绍 PyMySQL 是在 Python3.x 版本中用于连接 MySQL 服务器的一个库，而Python2中则使用mysqldb。 PyMySQL 遵循 Python 数据库 API v2.0 规范，并包含了 pure-Python MySQL 客户端库。 通用步骤: 1.引入模块 2.获取与数据库的连接 3.执行SQL语句和存储过程 4.关闭数据库连接 PyMySQL 安装 1.打开cmd命令 cd C:\Users\Administrator\AppData\Local\Programs\Python\Python37\Scripts #切换目录 pip install pymysql 数据库连接 import pymysql #模块导入 #打开数据库连接 db = pymysql.connect( host='数据库ip', user='用户名, passwd='密码', db='数据库名', port=3306, charset='utf8' ) #使用 cursor() 方法创建一个游标对象 cursor cursor = db.cursor() #使用 execute() 方法执行 SQL 查询 cursor.execute("SELECT VERSION()") #使用 fetchone() 方法获取单条数据. data = cursor

在并发环境，一个数据库系统会同时为各种各样的客户程序提供服务，也就是说，在同一时刻，会有多个客户程序同时访问数据库系统，这多个客户程序中的失误访问数据库中相同的数据时，如果没有采取必要的隔离机制，就会导致各种各样的并发问题的发生，这些并发问题可归纳为以下几类 多个事务并发引起的问题： 1)第一类丢失更新：撤消一个事务时，把其它事务已提交的更新的数据覆盖了。 2)脏读：一个事务读到另一个事务未提交的更新数据。 3) 幻读：一个事务执行两次查询，但第二次查询比第一次查询多出了一些数据行。 4)不可重复读：一个事务两次读同一行数据，可是这两次读到的数据不一样。 5)第二类丢失更新：这是不可重复读中的特例，一个事务覆盖另一个事务已提交的更新数据。 事务隔离级别 为了解决多个事务并发会引发的问题。数据库系统提供了四种事务隔离级别供用户选择。 1) Serializable：串行化。隔离级别最高 2) Repeatable Read：可重复读。--MySQL默认是这个 3) Read Committed：读已提交数据。--Oracle默认是这个 4) Read Uncommitted：读未提交数据。隔离级别最差。--sql server默认是这个 数据库系统采用不同的锁类型来实现以上四种隔离级别，具体的实现过程对用户是透明的。用户应该关心的是如何选择合适的隔离级别。 对于多数应用程序

SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。 Read Uncommitted（读取未提交内容） 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。 Read Committed（读取提交内容） 这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。 Repeatable Read（可重读） 这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion

最近学习了一下数据库的悲观锁和乐观锁，根据自己的理解和网上参考资料总结如下： 悲观锁介绍（百科）： 悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中， 将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了 加锁机制，也无法保证外部系统不会修改数据）。 使用场景举例 ：以MySQL InnoDB为例 商品goods表中有一个字段status，status为1代表商品未被下单，status为2代表商品已经被下单，那么我们对某个商品下单时必须确保该商品status为1。假设商品的id为1。 1如果不采用锁，那么操作方法如下： //1.查询出商品信息 select status from t_goods where id=1; //2.根据商品信息生成订单 insert into t_orders (id,goods_id) values (null,1); //3.修改商品status为2 update t_goods set status=2; 上面这种场景在高并发访问的情况下很可能会出现问题。 前面已经提到，只有当goods status为1时才能对该商品下单，上面第一步操作中

锁的类型 共享锁(S) 共享锁可以被多个事务持有，事务T1获取了行r的共享锁，那么事务T2也可以获得行r的共享锁，但是获取不到事务T1的排它锁 显示的加共享锁：select * from xx lock in share mode; 排它锁(X) 排他锁只能被一个事务持有，事务T1持有了行r的排它锁，那么事务T2获取不到行r的排它锁，也获取不到行r的共享锁 显式的加排它锁：select * from xx for update; S X S 兼容 不兼容 X 不兼容 不兼容 创建一张测试表a,id是主键，a2为唯一索引，a3为普通所以 CREATE TABLE `a` ( `id` int(11) NOT NULL AUTO_INCREMENT , a1 int(11) NOT NULL , a2 int(11) not NULL, a3 int(11) not null, PRIMARY KEY (`id`), unique key uniq_a2(a2), index idx_a3(a3) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 ; insert into a(a1,a2,a3) values(1,2,3),(2,4,6),(3,6,12); 事务1获取共享锁，事务2获取排它锁，事务2将获取失败 事务1 事务2 start

前一段时间好好研究了秒杀的问题，我把里面的问题好好总结了，可以说是比较全面的了，真的是吐血整理了。 由于我先是在word中整理的，格式都整理得比较好，放到博客上格式挺难调，暂时按word的格式来吧，有时间了在好好排版下。 主要需要解决的问题有两个： 高并发对数据库产生的压力 竞争状态下如何解决库存的正确减少（超卖问题） 优化的思路： 1） 尽量将请求拦截在系统上游 2）读多写少经量多使用缓存 3) redis缓存 +RabbitMQ+ mysql 批量入库 1. 初始秒杀设计 1.1 业务分析 秒杀系统业务流程如下: 由图可以发现，整个系统其实是针对库存做的系统。用户成功秒杀商品，对于我们系统的操作就是: 1. 减库存。2. 记录用户的购买明细。 下面看看我们用户对库存的业务分析: 记录用户的秒杀成功信息，我们需要记录: 1. 谁购买成功了。2. 购买成功的时间/ 有效期 。这些数据组成了用户的秒杀成功信息，也就是用户的购买行为。 为什么我们的系统需要事务 ? 1.若是用户成功秒杀商品我们记录了其购买明细却没有减库存。导致商品的 超卖 。 2.减了库存却没有记录用户的购买明细。导致商品的 少卖 。对于上述两个故障，若是没有事务的支持，损失最大的无疑是我们的用户和商家。在MySQL中，它内置的事务机制，可以准确的帮我们完成减库存和记录用户购买明细的过程。 1.2 难点分析

原文: http://blog.gqylpy.com/gqy/454 置顶：来自一名75后老程序员的武林秘籍——必读 （博主推荐） 来，先呈上武林秘籍链接： http://blog.gqylpy.com/gqy/401/ 你好，我是一名极客！一个 75 后的老工程师！ 我将花两分钟，表述清楚我让你读这段文字的目的！ 如果你看过武侠小说，你可以把这个经历理解为，你失足落入一个山洞遇到了一位垂暮的老者！而这位老者打算传你一套武功秘籍！ 没错，我就是这个老者！ 干研发 20 多年了！我也年轻过，奋斗过！我会画原理图，会画 PCB，会模拟，会数字！玩过 PLC，玩过单片机，会用汇编，会用 C！玩过 ARM，比如 PLC，STM32，和时下正在起飞的 NXP RT1052！搞过 DSP，比如 TMS320F28335！搞过 FPGA，不管 Xilinx 还是 Altera，也不管是 Verilog 还是 VHDL，或者直接画数字电路图！我懂嵌入式系统，比如 uCOS 和 Linux！我懂开源的硬件，比如 Arduino 和树莓派!我也搞软件，学了一堆上位机的语言C#，JAVA，Python，Kotlin，Swift！会写爬虫工具，又自学写APP，不管Android 还是 IOS！ 可是这一切有什么用呢？土鸡瓦狗！不值一提！干技术的永远就是最苦逼的那个人！ 我相信看到这里的你，应该是个 IT