mysql事务

一、数据库的隔离级别分类 根据实际需求，通过设置数据库的事务隔离级别可以解决多个事务并发情况下出现的脏读、不可重复读和幻读问题。数据库事务隔离级别由低到高依次为Read uncommitted、Read committed、Repeatable read和Serializable四种。数据库不同，其支持的事务隔离级别亦不相同：MySQL数据库支持上面四种事务隔离级别，默认为Repeatable read；Oracle 数据库支持Read committed和Serializable两种事务隔离级别，默认为Read committed。 1、Read uncommitted(读未提交) 可能出现脏读、不可重复读和幻读。 2、Read committed(读已提交) 可以避免脏读，但可能出现不可重复读和幻读。大多数数据库默认级别就是Read committed，比如Sql Server数据库和Oracle数据库。注意：该隔离级别在写数据时只会锁住相应的行。 3、Repeatable read(可重复读) 可以避免脏读和不可重复读，但可能出现幻读。注意：事务隔离级别为可重复读时，如果检索条件有索引(包括主键索引)的时候，默认加锁方式是next-key锁；如果检索条件没有索引，更新数据时会锁住整张表。一个间隙被事务加了锁，其他事务是不能在这个间隙插入记录的，这样可以防止幻读。 4

  上篇文章给大家详细的介绍Spring中事务的传播行为，在事务中我们需要关注事务的传播行为和事务的隔离级别这两个点，所以本文给大家介绍下事务的隔离级别 事务的隔离级别   事务隔离级别指的是一个事务对数据的修改与另一个并行的事务的隔离程度，当多个事务同时访问相同数据时，如果没有采取必要的隔离机制，就可能发生以下问题： 问题 描述 脏读 一个事务读到另一个事务未提交的更新数据 ，所谓脏读，就是指事务A读到了事务B还没有提交的数据，比如银行取钱，事务A开启事务，此时切换到事务B，事务B开启事务–>取走100元，此时切换回事务A，事务A读取的肯定是数据库里面的原始数据，因为事务B取走了100块钱，并没有提交，数据库里面的账务余额肯定还是原始余额，这就是脏读 幻读 是指当事务不是独立执行时发生的一种现象 ，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。 同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象 发生了幻觉一样。 不可重复读 在一个事务里面的操作中发现了未被操作的数据 比方说在同一个事务中先后执行两条一模一样的select语句，期间在此次事务中没有执行过任何DDL语句，但先后得到的结果不一致，这就是不可重复读 Spring支持的隔离级别 隔离级别 描述

Mysql默认事务隔离级别是：REPEATABLE-READ --查询当前会话事务隔离级别mysql> select @@tx_isolation; +-----------------+ | @@tx_isolation | +-----------------+ | REPEATABLE-READ | +-----------------+ 1 row in set (0.00 sec) --全局查询 mysql> select @@global.tx_isolation; +-----------------------+ | @@global.tx_isolation | +-----------------------+ | REPEATABLE-READ | +-----------------------+ 1 row in set (0.00 sec) mysql> mysql> show variables like 'tx_isolation'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | tx_isolation | REPEATABLE-READ | +---------------+----------

1 Windows服务 -- 启动MySQL net start mysql-- 创建Windows服务 sc create mysql binPath= mysqld_bin_path(注意：等号与值之间有空格) 2 连接与断开服务器 mysql -h 地址 -P 端口 -u 用户名 -p 密码SHOW PROCESSLIST -- 显示哪些线程正在运行SHOW VARIABLES -- 显示系统变量信息 3 数据库操作 -- 查看当前数据库 SELECT DATABASE();-- 显示当前时间、用户名、数据库版本 SELECT now(), user(), version();-- 创建库 CREATE DATABASE[ IF NOT EXISTS] 数据库名 数据库选项 数据库选项： CHARACTER SET charset_name COLLATE collation_name-- 查看已有库 SHOW DATABASES[ LIKE 'PATTERN']-- 查看当前库信息 SHOW CREATE DATABASE 数据库名-- 修改库的选项信息 ALTER DATABASE 库名 选项信息-- 删除库 DROP DATABASE[ IF EXISTS] 数据库名 同时删除该数据库相关的目录及其目录内容 4 表的 操作 -- 创建表 CREATE

接到上级一个生产环境MySQL死锁日志信息文件，需要找出原因并解决问题。我将死锁日志部分贴出如下： 在mysql中使用命令：SHOW ENGINE INNODB STATUS;总能获取到最近一些问题信息，通过搜索deadlock 关键字即可找到死锁的相关日志信息。 2019-09-25 13:28:25 7fc0301ca700InnoDB: transactions deadlock detected, dumping detailed information. 2019-09-25 13:28:25 7fc0301ca700 *** (1) TRANSACTION: TRANSACTION 48000896642, ACTIVE 0 sec starting index read mysql tables in use 1, locked 1 LOCK WAIT 5 lock struct(s), heap size 1184, 3 row lock(s), undo log entries 5 MySQL thread id 1585229, OS thread handle 0x7fc030e7c700, query id 36142536228 100.64.177.170 oms8 updating update tb_elc_forecast set capital

内容提取自 58沈剑公众号：架构师之路 1、共享锁和排他锁 因为普通锁不能并发，所以出现了共享和排它锁 共享锁（Share Locks,记为S锁），读取数据时加S锁 排他锁（exclusive Locks）修改数据时加X锁 兼容互斥表 S X S 兼容 互斥 X 互斥 互斥 这种情况下，如果写数据的任务没有完成，数据不能被任务读取的。这回阻塞读取任务。 画外音：对应到数据库，可以理解为，写事务没有提交，读取相关数据的select会被阻塞 2、数据多版本 核心原理： 1）写任务发生时，将数据克隆一份，以版本号区分 2）写任务操作新克隆的数据，直至提交；（提交时覆盖原来版本？提交方式有待思考） 3）并发读任务可以继续读取旧版本的数据，不至于阻塞 3、redo，undo，回滚段 在进一步介绍InnoDB如何使用“读取旧版本数据”极大提高任务的并发度之前，有必要先介绍下redo日志，undo日志，回滚段（rollback segment）。 为什么要有redo 日志？ 数据库事务提交后，必须将更新后的数据刷到磁盘上，以保证ACID特性。磁盘 随机写 性能较低，如果每次都刷盘，会极大影响数据库的吞吐量。 优化方式是，将修改行为先写到redo日志里（此时变成了 顺序写 ），再定期将数据刷到磁盘上，这样能极大提高性能。 画外音：这里的架构设计方法是， 随机写优化为顺序写 ，思路更重要。

问题背景： 假设MySQL数据库有一张会员表vip_member（InnoDB表），结构如下： 当一个会员想续买会员（只能续买1个月、3个月或6个月）时，必须满足以下业务要求： •如果end_at早于当前时间，则设置start_at为当前时间，end_at为当前时间加上续买的月数 •如果end_at等于或晚于当前时间，则设置end_at=end_at+续买的月数 •续买后active_status必须为1（即被激活） 问题分析： 对于上面这种情况，我们一般会先SELECT查出这条记录，然后根据查出记录的end_at再UPDATE start_at和end_at，伪代码如下（为uid是1001的会员续1个月）： 代码如下: vipMember = SELECT * FROM vip_member WHERE uid=1001 LIMIT 1 # 查uid为1001的会员 if vipMember.end_at < NOW(): UPDATE vip_member SET start_at=NOW(), end_at=DATE_ADD(NOW(), INTERVAL 1 MONTH), active_status=1, updated_at=NOW() WHERE uid=1001 else: UPDATE vip_member SET end_at=DATE_ADD(end_at,

问题背景： 假设MySQL数据库有一张会员表vip_member（InnoDB表），结构如下： 当一个会员想续买会员（只能续买1个月、3个月或6个月）时，必须满足以下业务要求： 如果end_at早于当前时间，则设置start_at为当前时间，end_at为当前时间加上续买的月数 如果end_at等于或晚于当前时间，则设置end_at=end_at+续买的月数 续买后active_status必须为1（即被激活） 问题分析： 对于上面这种情况，我们一般会先SELECT查出这条记录，然后根据查出记录的end_at再UPDATE start_at和end_at，伪代码如下（为uid是1001的会员续1个月）： vipMember = SELECT * FROM vip_member WHERE uid=1001 LIMIT 1 # 查uid为1001的会员 if vipMember.end_at < NOW(): UPDATE vip_member SET start_at=NOW(), end_at=DATE_ADD(NOW(), INTERVAL 1 MONTH), active_status=1, updated_at=NOW() WHERE uid=1001 else: UPDATE vip_member SET end_at=DATE_ADD(end_at, INTERVAL

关键要点 仅从ACID或非ACID角度考虑问题是不够的，你应知道你的数据库支持何种事务隔离级别。 一些数据库宣称自己具有“最终一致性”，但却可能对重复查询返回不一致的结果。 相比于你所寻求的数据库，一些数据库提供更高的事务隔离级别。 脏读可导致同一记录得到两个版本，或是完全地丢失一条记录。 在同一事务中多次重新运行同一查询后，可能会出现幻读。 最近MongoDB登上了Reddit的头条，因为MongoDB的核心开发者David Glasser痛苦地认识到MongoDB默认会执行脏读( https://engineering.meteor.com/mongodb-queries-dont-always-return-all-matching-documents-654b6594a827 )。 在本文中，我们将解释什么是事务隔离级别和脏读，并给出一些广受欢迎的数据库是如何实现它们的。ANSI SQL给出了四种标准的事务隔离级别：可序列化(Serializable)（应该翻译为串行化的事务）、可重复读(Repeatable reads)、提交读(Read committed)和未提交读(Read uncommitted)。 许多数据库缺省是提交读的，这保证了在事务运行期间用户看不到转变中的数据。提交读的实现通过在读取时暂时性地获取锁，并持有写入锁直至事务提交

本篇讲诉数据库中事务的四大特性（ACID），并且将会详细地说明事务的隔离级别。 　　如果一个数据库声称支持事务的操作，那么该数据库必须要具备以下四个特性： ⑴ 原子性（Atomicity） 　　原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚，这和前面两篇博客介绍事务的功能是一样的概念，因此事务的操作如果成功就必须要完全应用到数据库，如果操作失败则不能对数据库有任何影响。 ⑵ 一致性（Consistency） 　　一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。 　　拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。 ⑶ 隔离性（Isolation） 　　隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 　　即要达到这么一种效果：对于任意两个并发的事务T1和T2，在事务T1看来，T2要么在T1开始之前就已经结束，要么在T1结束之后才开始，这样每个事务都感觉不到有其他事务在并发地执行。 　　关于事务的隔离性数据库提供了多种隔离级别，稍后会介绍到。 ⑷ 持久性（Durability）