mysql事务

mysql事务的四大特性： 原子性： 组成事务处理的语句形成了一个逻辑单元，不能只执行其中的一部分。换句话说，事务是不可分割的最小单元。比如：银行转帐过程中，必须同时从一个帐户减去转帐金额，并加到另一个帐户中，只改变一个帐户是不合理的。 一致性： 在事务处理执行前后，数据库是一致的。也就是说，事务应该正确的转换系统状态。比如：银行转帐过程中，要么转帐金额从一个帐户转入另一个帐户，要么两个帐户都不变，没有其他的情况。 隔离性： 一个事务处理对另一个事务处理没有影响。就是说任何事务都不可能看到一个处在不完整状态下的事务。比如说，银行转帐过程中，在转帐事务没有提交之前，另一个转帐事务只能处于等待状态。 持续性： 事务处理的效果能够被永久保存下来。反过来说，事务应当能够承受所有的失败，包括服务器、进程、通信以及媒体失败等等。比如：银行转帐过程中，转帐后帐户的状态要能被保存下来。 MyISAM不支持事物，InnoDB支持事物。 MYSQL的事务处理主要有两种方法 1、用begin,rollback,commit来实现 START TRANSACTION 开始一个事务 ROLLBACK 事务回滚 COMMIT 事务确认 2、直接用set来改变mysql教程的自动提交模式 MYSQL默认是自动提交的，也就是你提交一个QUERY，它就直接执行！我们可以通过 set autocommit=0

简答题 1.MySQL常见的三种存储引擎（InnoDB、MyISAM、MEMORY）的区别(至少5点)？ l InnoDB存储引擎 InnoDB是事务型数据库的首选引擎，支持事务安全表（ACID），其它存储引擎都是非事务安全表，支持行锁定和外键，MySQL5.5以后默认使用InnoDB存储引擎。 InnoDB主要特性 为MySQL提供了具有提交、回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在 SELECT语句中提供一个类似Oracle的非锁定读。这些功能增加了多用户部署和性能。在SQL查询中，可以自由地将InnoDB类型的表和其他MySQL的表类型混合起来，甚至在同一个查询中也可以混合。 。 l MyISAM存储引擎 MyISAM基于ISAM存储引擎，并对其进行扩展。它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一。MyISAM拥有较高的插入、查询速度，但不支持事务，不支持外键。 MyISAM主要特性： 被大文件系统和操作系统支持。 当把删除和更新及插入操作混合使用的时候，动态尺寸的行产生更少碎片。这要通过合并相邻被删除的块，若下一个块被删除，就扩展到下一块自动完成。 每个MyISAM表最大索引数是64，这可以通过重新编译来改变。每个索引最大的列数是16。 最大的键长度是1000字节，这也可以通过编译来改变

分布式事务 通过MQ解决分布式事务的思路 1) 业务和消息生成耦合在一起 2) 业务和消息解耦 RocketMQ 中的事务消息 1) 目前RMQ3.2.6中事务消息的实现原理及存在的问题 2) 问题解决思路 本文介绍RocketMQ提供的第三种类型的消息——Transaction Message(事务消息)。在说事务消息之前，我们先来说说分布式事务的那些事！ 分布式事务 什么是分布式事务，我的理解是一半事务。怎么说，比如有2个异构系统，A异构系统要做T1，B异构系统要做T2，要么都成功，要么都失败。 要知道异构系统，很显然，不在一个数据库实例上，它们往往分布在不同物理节点上，本地事务已经失效 2阶段提交 2阶段提交协议，Two-Phase Commit，是处理分布式事务的一种常见手段。2PC，存在2个重要角色：事务协调器（TC），事务执行者。 2PC，可以看到节点之间的通信次数太多了，时间很长！时间变长了，从而导致，事务锁定的资源时间也变长了，造成资源等待时间变长！在高并发场景下，存在严重的性能问题！ 通过MQ解决分布式事务的思路 下面，我们来看看MQ在高并发场景下，是如何解决分布式事务的。 考虑生活中的场景： 我们去北京庆丰包子铺吃炒肝，先去营业员那里付款（Action1），拿到小票（Ticket），然后去取餐窗口排队拿炒肝（Action2）。思考2个问题：第一

转载于： https://www.iteye.com/blog/chenzhou123520-1860954 最近学习了一下数据库的悲观锁和乐观锁，根据自己的理解和网上参考资料总结如下： 悲观锁介绍（百科）： 悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。 使用场景举例：以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; 上面这种场景在高并发访问的情况下很可能会出现问题。

转载： 对于我们开发的网站，如果网站的访问量非常大的话，那么我们就需要考虑相关的并发访问问题了。而并发问题是绝大部分的程序员头疼的问题， 但话又说回来了，既然逃避不掉，那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧。 为了更好的理解并发和同步，我们需要先明白两个重要的概念: 同步和异步 1、同步和异步的区别和联系 　　所谓同步，可以理解为在执行完一个函数或方法之后，一直等待系统返回值或消息，这时程序是出于阻塞的，只有接收到 返回的值或消息后才往下执行其它的命令。 异步，执行完函数或方法后，不必阻塞性地等待返回值或消息，只需要向系统委托一个异步过程，那么当系统接收到返回 值或消息时，系统会自动触发委托的异步过程，从而完成一个完整的流程。 同步在一定程度上可以看做是单线程，这个线程请求一个方法后就待这个方法给他回复，否则他不往下执行(死心眼)。 异步在一定程度上可以看做是多线程的(废话，一个线程怎么叫异步)，请求一个方法后，就不管了，继续执行其他的方法。 　　 同步就是一件事，一件事情一件事的做。 异步就是，做一件事情，不引响做其他事情。 例如：吃饭和说话，只能一件事一件事的来，因为只有一张嘴。 但吃饭和听音乐是异步的，因为，听音乐并不引响我们吃饭。 对于Java程序员而言，我们会经常听到同步关键字synchronized，假如这个同步的监视对象是类的话

Redis事务及锁应用 一，事务的应用 事务: 即逻辑上的一组操作，要么全部成功，要么全部失败。 参考mysql中的事务，redis为了处理实际业务同样提供了事务操作，下面我们参照mysql中的事务学习redis事务。 MySQL Redis 开启事务 begin multi 语句/命令 sql语句 普通命令 失败 rollback 回滚 discard 取消 关闭事务 commit exec 通过比较我们可以看到redis的事务命令，我们先参照mysql中的事务 模拟tom给jerry转账业务 begin; update account set money=money-1000 where username='tom'; update account set money=money+1000 where username='jerry'; commit; redis事务 启动事务 multi 回滚事务，在redis中准确的说是取消事务。而不是回滚事务 discard 提交事务 exec 案例 模拟tom给jerry转账业务 127.0.0.1:6379> multi OK 127.0.0.1:6379> set tom 300 QUEUED 127.0.0.1:6379> set jerry 300 QUEUED 127.0.0.1:6379> exec 1) OK 2) OK

导读 本文转载自MySQL解决方案工程师 作者：徐铁韬 这篇文章将详细地介绍MySQL的高可用解决方案—— MySQL InnoDB Cluster。 说到高可用性，首先要了解一下什么是高可用性？ 高可用性要求的实际上是对可靠性的要求，从本质上来说，是通过技术和工具来提高可靠性，尽可能长时间保持数据的可用和系统的正常运行时间。实现高可用性的原则为排除单点故障、通过冗余实现快速恢复，并且具有容错机制。 上面一页主要介绍了几个关键词汇，以及相关的定义，这些有助于理解可靠性和高可用性。 MySQL的高可用性解决方案目前大致分为5种，按照高可用的级别（99.9999%为最高级）排序依次为，主从复制、具有自动故障转移功能的主从复制、利用共享存储、OS或虚拟化软件实现主备架构、MySQL Group Replication 群组复制，以及MySQL NDB Cluster。 MySQL Replication：允许数据从一台实例上复制到一台或多台其它的实例上。 MySQL Group Replication：群组复制提供更好的冗余性、自动恢复以及写入扩展。 MySQL InnoDB Cluster：基于群组复制，提供了易于管理的API、应用故障转移和路由、易于配置，提供比群组复制更高级别的可用性。 MySQL NDB Cluster：容易与MySQL InnoDB Cluster混淆

前言: 事务处理的本质 在学习事务处理前,需要明确一点: 数据库操作最终都要使用到JDBC,那么无论上层如何封装,底层都是调用Connection的commit,rollback来完成 烦人的事务处理: 在日常开发中,数据访问层(DAO)必然需要进行事务的处理,但是我们会发现,事务处理的代码通常是简单的重复的,编写这样的重复代码会浪费大量的时间,所以我们需要找到一种方案可以将这些重复的代码进行抽取,以便与管理维护和复用, 我们的需求:在一系列数据库操作上的方法上增加额外的事务处理代码,让原来的方法中只关注具体的数据处理,即在原本以及存在的数据库操作方法上添加额外的事务处理逻辑 到这里你应该想到AOP了,没错! 这样的场景下AOP是最好的解决方案; 解决方案:AOP 回顾一下Spring的AOP:在结合目前的需求 1.将目标对象(DAO)放入Spring容器 2.告知Spring你的通知代码是什么(事务处理) 3.告知Spring 哪些方法(DAO的CRUD)要应用那些通知(不同的事务处理代码) 4.从Spring中获取代理对象来完成原本的CRUD,代理对象会自动完成事务处理 Spring 事务处理API Spring作为框架,需要进行详细的设计,全方位的考虑事务处理的各个方面,而不仅是简单的帮你执行commit,rollback; Spring对事务处理进行了抽象定义

MySQL-锁 文章目录 MySQL-锁 锁的分类 按照功能分 按照锁的粒度分 全局锁 表锁 表读锁 表写锁 行锁 快照读与当前读 加锁方式 加锁方式选择 间隙锁 MVCC和间隙锁 元数据锁 元数据锁导致的阻塞 锁的分类 按照功能分 共享锁(读锁/S锁) 其他不可获得X锁 所有连接均可读取，所有连接均不可修改 排他锁(写锁/X锁) 其他不可获得S/X锁 加锁连接可以读取可以修改，其他连接均不可读写 按照锁的粒度分 全局锁 、 表锁 、 行锁 等… 全局锁 MySQL全局锁会使用 读锁 锁定 所有库中所有的表 。 加锁： FLUSH TABLES WITH READ LOCK； 解锁： UNLOCK TABLES; 全局锁加锁后，所有的连接只能读表，加锁的连接进行表中数据的修改会报错。其他连接进行数据修改会阻塞，直到全局锁解锁后返回。一般用在整个库做备份时。 表锁 MySQL表锁在事务需要 更新大表的大部分或全部数据时 。如果使用行锁加锁效率极低，因此这种情况下一般使用表锁，事务涉及多个表时可能会因此死锁，也可以考虑使用表锁来避免死锁。 表锁分为 表读锁 和 表写锁 ： 表读锁 lock tables t read; 表读锁时所有连接都可以读，本连接修改会报错，其他连接修改会阻塞，直到锁释放才返回。 表写锁 lock tables t write; 表写锁时，本连接可以读和写

MySQL-事务 事务定义 事务就是一组原子性的SQL查询语句，要么全部执行成功、要么全部执行失败。 ACID 一个良好的事务数据库系统，必须具备ACID特性。 原子性(Atomicity) 要么全部执行、要么全部不执行 一致性(Consistency) 事务开始和结束时，数据必须保证一致性 隔离性(Isolation) 事务处理过程中、中间状态对其他事务不可见 持久性(Durability) 事务完成后、它对数据的修改时永久性的 事务隔离级别 MySQL有四种隔离级别。 Read Uncommitted读未提交 所有事务可以看到其他未提交事务的执行结果 Read Committed读已提交 事务只能看到已提交事务所做的改动 Repeatable Read可重复读 默认的隔离级别 Serializable串行 强制事务排序、一次只执行一个事务 并发问题 脏读 事务读到了其他未提交的事务修改的数据，此数据可能因回滚而作废。 不可重复读 事务多次读取同一数据，返回的结果不同。 幻读 事务多次读取同一数据，返回的结果条数不同。 不可重复读和幻读区别： 不可重复读：针对其他事务提交前后，对行的修改来说。 幻读：针对其他事务提交前后，对行的增删来说。 不同隔离级别下的并发问题 脏读 不可重复读 幻读 读未提交 √ √ √ 读已提交 × √ √ 可重复读 × × x(注) 串行 × × ×