mysql事务

我是一个半路出家的PHP程序员，到目前为止，不算在培训班学习的时间，已经写代码整整两年了。可能由于工作业务的原因，在这两年中我没有用到过MySQL事务。就在昨天有个关于支付宝转账的业务不得不使用MySQL事务来完成，别人说了很多，还是不明白MySQL事务到底是个啥，于是就开始了新一轮的补课，出来混，欠下的知识账总是要还的。 先简单说一下我昨天遇到的那个业务，我要在移动端发起一个支付宝提现的业务，这个业务我之前是分三步写的： 第一步： 首先提现的话，我先要在提现表里写入一条提现记录，再更新一下用户余额表，这两条数据的记录都是个预提现的记录，就是说他们的状态都是处理中； 第二步： 然后在请求支付宝的第三方接口； 第三步： 如果接口请求成功，用户已经收到支付宝付给用户的钱后，我们在更新提现记录表的状态和用户余额表的数据。 如果接口请求失败，用户没有收到支付宝转给用户的钱，则提现记录表的状态为提现失败。 但是如果用户发起了提现，用户预提现业务已经进行，但是第三方支付宝接口请求失败，此时突然断电，则数据库状态无法更改，然后结果就不是我们预想的结果了。此时MySQL事务在这种业务中就显现出了自己的价值。 MySQL事务：一系列要执行的操作称为事务，而事务管理就是管理这些操作要么完全执行，要么完全不执行，就是说我上面的提现业务，要么全部要执行成功，要么全部不成功，不会出现执行半截的情况

DB：Database:数据库，指保存数据的文件集合。 DBMS：DataBaseManagementSystem:数据库管理系统（数据库软件），常见的数据库软件：Oracle,MySQL,SqlServer,DB2,sqlite等 SQL：StructuredQueryLanguage:结构化查询语言，用于程序员和数据库软件交互。 数据库相关SQL show databases; create database db1; show crate database db1; create database db1 character set utf8/gbk; drop database db1; use db1; 表相关SQL create table t_user(id int ,name varchar(10) ,email varchar(10)); show tables; show create table t_user; create table t_user(id int,name varchar(10),age int) engine=innodb/myisam charset=utf8/gbk; desc t_user; drop table t_user; 修改表相关 rename table t_user to t1; alter table t1

一、MySQL可重复读级别下，因为MVCC引起的BUG，下图1为相应的Java代码，其中事务1的生命周期最长，循环开启的事务2、3、4。。。与事务1存在并发问题 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　图1 解决方案：将方法userRemoteService.addUser和UserBaseContext.getUserBaseByUserId放在两个方法中，避免事务的并发问题 READ COMMITTED REPEATABLE READ READ UNCOMMITTED SERIALIZABLE 三、数据行隐藏字段 6字节的DATA_TRX_ID 标记了最新更新这条行记录的transaction id，每处理一个事务，其值自动+1 7字节的DATA_ROLL_PTR 指向当前记录项的rollback segment的undo log记录，找之前版本的数据就是通过这个指针 6字节的DB_ROW_ID，当由innodb自动产生聚集索引时，聚集索引包括这个DB_ROW_ID的值，否则聚集索引中不包括这个值.，这个用于索引当中 DELETE BIT位用于标识该记录是否被删除，这里的不是真正的删除数据，而是标志出来的删除。真正意义的删除是在commit的时候 对于有有三个字段id、name、balance的表，其中id为主键，实际的拥有的列如下 四

事务就是一组应该一起成功或一起失败的sql语句 事务具有四个属性（ACID）: 原子性：所有的sql语句要么全部成功，要么全部失败，不会存在部分更新。 一致性：事务只能以允许的方式改变受其影响的数据。 隔离性：同时发生的事务（并发事务）不应该导致数据库处于不一致的状态中。系统中每个事务都应该像唯一事务一样执行。任何事务都不应影响其他事务的存在。 持久性：无论数据库或系统是否发生故障，数据都会永久保存在磁盘上，并且不会丢失。 执行事务 先创建一个示例表并插入数据： create TABLE account ( account_number VARCHAR ( 10 ) PRIMARY KEY , balance INT ); INSERT INTO account VALUES ( 'A' , 600 ),( 'B' , 400 ); 要启动一个事务（一组sql），请执行start transaction 或 begin 语句 BEGIN ; SELECT balance INTO @a . bal FROM account WHERE account_number = 'A' UPDATE account SET balance = @a . bal - 100 WHERE account_number = 'A' ; SELECT balance INTO @b . bal

1.隔离级别介绍 　　隔离级别并不是某个SQL数据库所特有的，而所有SQL数据库都要实现的一种并发事务隔离机制。隔离性其实比想象的要复杂。在SQL标准中定义了四种隔离级别，每一种隔离级别都规定了一个事务中所作的修改，哪些在事务内和事务间是可见的，哪些是不可见的。较低的级别的隔离通常可以执行更高的并发，系统的开销也更低，然而数据的改变在事务间几乎是透明，也更容易引发各种无法预估的问题。下面简单介绍下四种隔离级别： Read Uncommitted（未提交读） 　　在Read Uncommitted级别，事务的修改，即使没有提交，对其他事务也是可见的。事务可以读取其它事务未提交的数据，这也被称为脏读（Dirty Read）。这个级别会导致很多问题，从性能上说，Read Uncommitted不会比其他级别好太多，但缺乏其他级别的很多好处。除非真的有非常必要的理由，在实际应用中一般很少使用。 Read Committed（已提交读） 　　大多数数据库的默认隔离级别都是Read Committed（但MySQL 不是）。Read Committed满足隔离性的简单定义：一个事务开始时，只能看见已经提交的事务所作的修改。换句话说，一个事务从开始知道提交之前，所作的任何修改对其它事务是不可见的。这个级别有时候也叫做不可重复读（Nonrepeatable Read）

什么是MVVC？ MVVC (Multi-Version Concurrency Control) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)是一种基于多版本的并发控制协议，只有在InnoDB引擎下存在。MVCC是为了实现事务的隔离性，通过版本号，避免同一数据在不同事务间的竞争，你可以把它当成基于多版本号的一种乐观锁。当然，这种乐观锁只在事务级别未提交锁和已提交锁时才会生效。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能。具体见下面介绍。 MVVC的实现机制 InnoDB在每行数据都增加两个隐藏字段，一个记录创建的版本号，一个记录删除的版本号。 在多版本并发控制中，为了保证数据操作在多线程过程中，保证事务隔离的机制，降低锁竞争的压力，保证较高的并发量。在每开启一个事务时，会生成一个事务的版本号，被操作的数据会生成一条新的数据行（临时），但是在提交前对其他事务是不可见的，对于数据的更新（包括增删改）操作成功，会将这个版本号更新到数据的行中，事务提交成功，将新的版本号更新到此数据行中，这样保证了每个事务操作的数据，都是互不影响的，也不存在锁的问题。 MVVC下的CRUD SELECT： 当隔离级别是REPEATABLE

锁粒度 MySQL 不同的存储引擎支持不同的锁机制，所有的存储引擎都以自己的方式显现了锁机制，服务器层完全不了解存储引擎中的锁实现： InnoDB 存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 MyISAM 和 MEMORY 存储引擎采用的是表级锁（table-level locking） BDB 存储引擎采用的是页面锁（page-level locking），但也支持表级锁 默认情况下，表锁和行锁都是自动获得的， 不需要额外的命令。 但是在有的情况下， 用户需要明确地进行锁表或者进行事务的控制， 以便确保整个事务的完整性，这样就需要使用事务控制和锁定语句来完成。 不同粒度锁的比较 表级锁 开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 存储引擎通过总是一次性同时获取所有需要的锁以及总是按相同的顺序获取表锁来避免死锁。 表级锁更适合于以查询为主，并发用户少，只有少量按索引条件更新数据的应用，如Web 应用 行级锁 开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。 最大程度的支持并发，同时也带来了最大的锁开销。 在 InnoDB 中，除单个 SQL 组成的事务外，锁是逐步获得的，这就决定了在 InnoDB 中发生死锁是可能的。 行级锁只在存储引擎层实现

索引： 1、普通索引： create index 自定义索引名称 on 库名.表名（表中的字段); 如：create index student on aa.学生表(学号); 2、唯一性索引： create unique index 自定义索引名称 on 库名.表名(表中的字段)； 如：create unique index tudent on aa.学生表(学号); 注：删除索引 DROP INDEX 索引名称 ON 表名 3、主键索引： create table 表名(字段1,字段2……，PRIMARY KEYS(前面的某个字段))； alter table 库名.表名 add PRIMARY KEYS(表的某个字段); 如：create table studentss(id int(4), name char(6),age int(4),PRIMARY KEY(id)); 如：alter table studentss add primary key(id) 注：主键索引和唯一性索引的区别是，唯一性索引可以允许有空值。 注： 删除主键 如果一个主键是自增长的，不能直接删除该列的主键索引， 应当先取消自增长，再删除主键特性 alter table 表名 drop primary key; 【如果这个主键是自增的，先取消自增长.】 具体方法如下: alter table

1. 如何设计一个高并发的系统 ① 数据库的优化，包括合理的事务隔离级别、SQL语句优化、索引的优化 ② 使用缓存，尽量减少数据库 IO ③ 分布式数据库、分布式缓存 ④ 服务器的负载均衡 2. 锁的优化策略 ① 读写分离 ② 分段加锁 ③ 减少锁持有的时间 ④ 多个线程尽量以相同的顺序去获取资源 等等，这些都不是绝对原则，都要根据情况，比如不能将锁的粒度过于细化，不然可能会出现线程的加锁和释放次数过多，反而效率不如一次加一把大锁。这部分跟面试官谈了很久 3. 索引的底层实现原理和优化 B+树，经过优化的B+树 主要是在所有的叶子结点中增加了指向下一个叶子节点的指针，因此InnoDB建议为大部分表使用默认自增的主键作为主索引。 ① 以“%”开头的LIKE语句，模糊匹配 ② OR语句前后没有同时使用索引 ③ 数据类型出现隐式转化（如varchar不加单引号的话可能会自动转换为int型） order by要怎么处理 alter尽量将多次合并为一次 insert和delete也需要合并 等等 6. 实践中如何优化MySQL 我当时是按以下四条依次回答的，他们四条从效果上第一条影响最大，后面越来越小。 ① SQL语句及索引的优化 ② 数据库表结构的优化 ③ 系统配置的优化 ④ 硬件的优化 变种极多，攻击简单，危害极大 未经授权操作数据库的数据 恶意纂改网页

事务是访问并更新数据库中各个数据项的一个程序执行单元。在事务操作中，要不都做修改，要么都不做。 事务具有ACID四个特性，分别是：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。 原子性是指要么不做，要么都做。 原子性是指数据库中不可分割的工作单位，只有使事务中所有的数据库操作都执行成功，才算整个事务成功。 事务中任何一个SQL语句执行失败，已经执行成功的SQL语句必须撤销，数据库状态应该退回到执行事务前的状态。 是指数据库从一种状态转变为下一种一致的状态，具体来说就是在事务开始前和事务结束以后，数据库的完整性约束没有被破坏。 事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。 重做日志 与原子性一样，事务的持久性也是通过日志来实现的，MySQL 使用重做日志（redo log）实现事务的持久性，重做日志由两部分组成，一是内存中的重做日志缓冲区，因为重做日志缓冲区在内存中，所以它是易失的，另一个就是在磁盘上的重做日志文件，它是持久的。 当我们在一个事务中尝试对数据进行修改时，它会先将数据从磁盘读入内存，并更新内存中缓存的数据，然后生成一条重做日志并写入重做日志缓存，当事务真正提交时，MySQL 会将重做日志缓存中的内容刷新到重做日志文件，再将内存中的数据更新到磁盘上，图中的第 4、5