mysql事务

在SQL标准中定义了四中隔离级别，每一种级别都规定了一个事务中所做的修改，哪些在事务内和事务间是可见的，哪些是不可见的。较低级别的隔离通常可以执行更高的并发，系统开销也更低。 四种隔离级别： READ UNCOMMITTED（未提交读） READ COMMITTED (提交读) 这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。 REPEATABLE READ(可重复读) MySQL默认的隔离级别 SERIALIZABLE (可串行化) 脏读 ：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。 不可重复读 ：在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。 幻读 :在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。

一：个人看法 又一个“真正” 的群集，怎么做到“真正” ？ 怎么做到解决复制的延迟，怎么做到强数据一致性？yGTID的全局事务就能 围绕这些问题进行了一些mgr 的实践， 为未来的数据库高可用设计多条选择。 mysql5.7手册17章可以看到其原理，网络上也很多同志写了关于其技术原理，这里自己对比rac理解下： 作为shared nothing (mgr)架构，其数据一致性实现较 shared everything(RAC) 架构要难， MGR 对于 sharad nothing 架构，必须要了解分布式协议PAXOS，分布式状态机 理论，而在这块我翻阅了很多资料，发现其实并不是很成熟的。从上图可以看出来MGR 的冲突检测机制 类似于 rac 的gird 群集组件 也具备通告广播的群集服务。但本质架构上有所不同。一切依赖于 复制组的软件实现。如果这里出了问题，那么整个群集一致性难以得到保证。 二：搭建过程 这个过程比较粗糙，网络上有不少写的比较细的可以参考 1：MGR 必须3节点以上，这个道理不在解释，先配置my.cnf port=3306 basedir=/home/mysql datadir=/home/mysql/data3 socket = /home/mysql/data3/mysql3.sock log_error=/home/mysql/data3/mysql3

索引 1、概述 MySQL索引的建立对于MySQL的高效运行是很重要的，索引可以大大提高MySQL的检索速度。 虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。 建立索引会占用磁盘空间的索引文件。 2、索引种类 普通索引：仅加速查询 唯一索引：加速查询 + 列值唯一（可以有null） 主键索引：加速查询 + 列值唯一 +　表中只有一个（不可以有null） 组合索引：多列值组成一个索引， 索引合并：使用多个单列索引组合查询搜索 覆盖索引：select的数据列只用从索引中就能够取得，不必读取数据行，换句话说查询列要被所建的索引覆盖 a、普通索引 普通索引仅有一个功能：加速查询 create table in1( nid int not null auto_increment primary key, name varchar(32) not null, email varchar(64) not null, extra text, index ix_name (name) ) 创建表+索引 create index index_name on table_name(column_name) 创建索引 drop index_name on table_name;

mysql事务 mysql的事务必须要Innodb数据库引擎的数据库或表才支持事务 事务是必须满足4个条件（ACID） 原子性 ：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 一致性 ：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则，这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。 隔离性 ：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。 持久性 ：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。 事务的控制语句 BEGIN 或 START TRANSACTION 显式地开启一个事务； COMMIT 也可以使用 COMMIT WORK，不过二者是等价的。COMMIT 会提交事务，并使已对数据库进行的所有修改成为永久性的； ROLLBACK 也可以使用 ROLLBACK

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

转自：https://www.cnblogs.com/boblogsbo/p/5602122.html mysql锁机制分为表级锁和行级锁，本文就和大家分享一下我对mysql中行级锁中的共享锁与排他锁进行分享交流。 共享锁又称为读锁，简称S锁，顾名思义，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。 排他锁又称为写锁，简称X锁，顾名思义，排他锁就是不能与其他所并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。 对于共享锁大家可能很好理解，就是多个事务只能读数据不能改数据，对于排他锁大家的理解可能就有些差别，我当初就犯了一个错误，以为排他锁锁住一行数据后，其他事务就不能读取和修改该行数据，其实不是这样的。排他锁指的是一个事务在一行数据加上排他锁后，其他事务不能再在其上加其他的锁。mysql InnoDB引擎默认的修改数据语句，update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，如果加排他锁可以使用select ...for update语句，加共享锁可以使用select ... lock in share mode语句。所以加过排他锁的数据行在其他事务种是不能修改数据的，也不能通过for

参考转载： https://blog.csdn.net/yehuang_0801/article/details/75246413 事务定义深究： https://blog.csdn.net/amghost/article/details/17651891 事务：数据库应用中完成单一逻辑功能的操作集合，是一个既具有原子性又具有一致性的功能，我们要求事务不违反任何数据库的一致性约束，也就是说，如果事务启动时数据是一致的，那么当这个事务成功结束的时候数据库也应该是一致的 事务有四大特征 1.原子（ 原子性： 事务的所有操作在数据库中要么全部正确反映，要么全部不反映。 ） try{ }catch(AnyException){ } 2.一致 一致就涉及到事务了，定义为事务结束后，所有的人拿到的数据、索引都应该是一致的。 个人理解：就是原子操作完之后，所有的人拿到的数据、索引都应该是一致的。 3.隔离 保证不同的事务相互独立、透明地执行。 级联废弃：如果事务T1读到了事务T2未提交（没有commit，虽然操作数据库成功）的数据，如果T2提 交失败，那么T1也要回滚。 隔离级别： Read Uncommitted（读未提交） Read Committed（读已提交） Repeatable Read（可重复读）（MySQL默认隔离级别) Serializable（串行化） 脏读、不可重复读、幻读

最近做项目使用到了分布式事务，下面这篇文章将给大家介绍一下对分布式事务的一些见解，并讲解分布式事务处理框架TX-LCN的执行原理，初学入门，错误之处望各位不吝指正。 使用的场景很多，先举一个常见的：在微服务系统中，如果一个业务需要使用到不同的微服务，并且不同的微服务对应不同的数据库。 打个比方：电商平台有一个客户下订单的业务逻辑，这个业务逻辑涉及到两个微服务，一个是库存服务（库存减一），另一个是订单服务（订单数加一），示意图如下： 如果在执行这个业务逻辑时没有使用分布式事务，当库存与订单其中一个出现故障时，就很可能出现这样的情况：库存数据库的值减少了1，但是订单数据库没有变化；或是库存没变化，多了一个订单，也就是出现了数据不一致现象。 所以在类似的场合下我们要使用分布式事务，保证数据的一致性。 在谈分布式事务的解决思路之前，我们先来看看单一数据源是如何做事务处理的，我们可以从中获取一些启发。 我们以mysql的InnoDB引擎为例，由于mysql中有两套日志机制，一套是存储层的redo log，另一套是server层的binlog，每次更新数据都要对两个日志进行更新。为了防止写日志时只写了其中一个而没有写另外一个，mysql使用了一个叫 两阶段提交 的方式保证事务的一致性。具体是这样的： 假设创建一个这样的数据库： mysql> create table T(ID int

https://www.cnblogs.com/chinesern/p/7592537.html 1 MVCC基本原理 MVCC：多版本并发控制（MVCC,Multiversion Currency Control）。一般情况下，事务性储存引擎不是只使用表锁，行加锁的处理数据，而是结合了MVCC机制，以处理更多的并发问题。Mvcc处理高并发能力最强， 但系统开销 比最大（较表锁、行级锁），这是最求高并发付出的代价。 ** InnoDB实现MVCC的方法是，它存储了每一行的三个额外的隐藏字段:** 1.DB_TRX_ID：一个6byte的标识，每处理一个事务，其值自动+1 #下面提到的“创建时间”和“删除时间”记录的就是这个DB_TRX_ID的值 #如insert、update、delete操作时，删除操作用1个bit表示。 #DB_TRX_ID是最重要的一个，可以通过语句“show engine innodb status”来查找 2.DB_ROLL_PTR: 大小是7byte,指向写到rollback segment（回滚段）的一条undo log记录 （update操作的话，记录update前的ROW值） 3.DB_ROW_ID: 大小是6byte,该值随新行插入单调增加。 #当由innodb自动产生聚集索引时聚集索引(即没有主键时,因为MYSQL默认聚簇表

独占锁、共享锁、更新锁，乐观锁、悲观锁 1、锁的两种分类方式 （1）从数据库系统的角度来看，锁分为以下三种类型： 独占锁（Exclusive Lock） 　　独占锁锁定的资源只允许进行锁定操作的程序使用，其它任何对它的操作均不会被接受。执行数据更新命令，即INSERT、 UPDATE 或DELETE 命令时，SQL Server 会自动使用独占锁。但当对象上有其它锁存在时，无法对其加独占锁。独占锁一直到事务结束才能被释放。 共享锁（Shared Lock） 　　共享锁锁定的资源可以被其它用户读取，但其它用户不能修改它。在SELECT 命令执行时，SQL Server 通常会对对象进行共享锁锁定。通常加共享锁的数据页被读取完毕后，共享锁就会立即被释放。 更新锁（Update Lock） 　　更新锁是为了防止死锁而设立的。当SQL Server 准备更新数据时，它首先对数据对象作更新锁锁定，这样数据将不能被修改，但可以读取。等到SQL Server 确定要进行更新数据操作时，它会自动将更新锁换为独占锁。但当对象上有其它锁存在时，无法对其作更新锁锁定。 （2）从程序员的角度看，锁分为以下两种类型： 悲观锁（Pessimistic Lock） 　　悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此在整个数据处理过程中