默认的隔离级别是可重复读 REPEATABLE-READ , 在这个模式下出现幻读的例子一般是这两种情况:
随着系统用户访问量的不断增加，数据库的频繁访问将成为我们系统的一大瓶颈之一。由于项目前期用户量不大，我们实现单一的数据库就能完成。但是后期单一的数据库根本无法支撑庞大的项目去访问数据库，那么如何解决这个问题呢？
大家多少了解过架构，也听说过使用架构后，代码和可维护性和重用性能大大提升。这里我们来通过一些关于事务的实例，来感性地体会下架构带来的在可维护性方面的便利。本文来是从 java web轻量级开发面试教程从摘录的。 1 JDBC中的事务是方法层面的 ①通过setAutoCommit，设置非自动提交。在JDBC里，一般默认是自动提交，即有任何增删改的SQL语句都会当场执行。如果大家设置了非自动提交，记得在用好事务后设置回“自动提交”。 ②在合适的地方用connection.comm
业务系统通过一个数据库连接发给MySQL，经过SQL接口、解析器、优化器、执行器，解析SQL语句，生成执行计划，接着由执行器负责执行该计划，调用InnoDB的接口去实际执行。
大多数人，都会开两个窗口，分别起两个事务，然后 update 同一条记录，在发起第二次 update 请求时，block，这样就说明这行记录被锁住了：
至少有两种方法可用： 方法一，查询MySQL日志。 如果MySQL实例自从初始化后的日志一直留存着的话，自然可以查到当时的时间。
长期以来，在 MySQL 的开发规范里一般都会这么写：禁止大事务！话题转到 TiDB ，依然应该是：禁止大事务！
本文先提供一个没有采用的方式--采用事务加select for update的形式
根据报错的信息，通过mysqlbinlog解析binlog日志，找到对应的数据，然后查看从库是否缺失数据或者已存在对应主键的数据，然后手动在从库处理对应记录的数据。处理完毕后再次开启同步。
哈喽，我是狗哥。小伙伴都知道我最近换工作了，薪资、工作内容什么的都是我比较满意的。五月底也面试了有 6、7 家公司，应该拿了有 5 个 offer。这段时间也被问了很多面试题，我打算写一个专题分享出来，希望对你们有所帮助～
马克-to-win：我 们现在回到春节高并发买票的问题。我们假设有一百万个人买一百张票，其中买票程序一百万个线程同时运行。不用改变mysql的缺省事务隔离级别。任何人在 买之前都用普通的select * from table来访问数据库获得目前的票数。假如现在是一百，之后大家一起点“下单”钮。这个钮所对应的程序可以这样：先select * from table for update，这样所有别人的select * from table for update这句话都会被挡住，这个时刻选出的数据库的票的存量是准确的。你可以加一个判断，比如如果存量大于1，我就买一张票。（有很多高并发程序，会 在这里加一个乐观锁版本的判断，如果还是老版本就做更新。马克-to-win：原理和目的和我们的例子是一样的）注意这里加判断，虽然耗时，但至关重要，（这也是很多公司的通 用做法）而且必须像这样独占排他挡住别人大张旗鼓的做。假如你不下决心独占排他的去做判断，当你真正更新的时候，也许数据已经被别人更改了。也许一秒前看 存量是一百，一秒之后已经变成零了。不判断就直接更新的话，数据库票数也许会变成负数。完成判断之后就是更新数据库票数减一张，当然还需做一些其他的工 作，比如订单表中需要增加一行记录是谁买的之类的，最后提交。之后队列中下一个事务就会被开始执行。这只是程序的一个总的思路，真正做项目还需考虑用户体 验比如超时问题，（connection query有超时timeout异常）或用户等得不耐烦，主动关闭窗口。这时数据库服务器就会照顾下一个select * from table for update。马克-to-win：真正做项目时，我们可以选择用select * from t for update nowait （不等待行锁释放，提示锁冲突，不返回结果）或select * from t for update wait 5 （等待5秒，若行锁仍未释放，则提示锁冲突，不返回结果）给用户提供三个选择，可以死等，不等，或等5秒。同时告诉用户现在多少人在队列中你的前面（每有 一个人发出请求，在ServletContext中就加1，完成就减1），大概多长时间可以到你，因为数据库完成一个用多长时间可以算出来。下面我们就给 出一个并发买票的简单实现。（本例子我们还用上章的register数据库表，用age变量代表车票数，道理是一样的）
最近有一些活动，于是会对系统做一些平时量比较小的路径做一些打压，这不打压还好，这一打压就出现了奇怪的问题，居然有一段陈年老代码出现了死锁的问题，日志如下：
这几年O2O火爆，10个创业公司里就有9个是O2O的电商，相信支付抢购什么的以前听起来高大上的东西现在很多码农都会需要自己去实现。
今天发现有一个备份的mysql数据文件夹异常变大，一查发现是多了三个文件：ibdata1 ib_logfile0 ib_logfile1，前者18m，后两个各5m，原来是迁移的时候从mysql5.0迁移到了5.5，而5.5关闭innodb启动不起来，于是我就开启了innodb，由于innodb会默认增加这几个数据文件和日志文件，导致变大。尝试设置数据文件的大小，结果告诉我最小10m，还是太大，于是探索关闭innodb的方法。 看日志发现说由于mysql程序升级了，需要运行mysql_upgrade升级一下mysql里面的数据库，这个比较简单，和mysql命令用法是一样的，运行一遍就ok了。然后发现还是无法关闭innodb，很奇怪，查了下发现原来mysql5.5默认使用innodb了，所以无法简单的关闭掉，还要设置一下默认使用的引擎为myisam才可以，在my.cnf里加上如下两句： 复制代码 代码如下: default-storage-engine=MYISAM innodb=OFF 重启mysql，然后删掉那三个讨厌的文件即可。 MySQL 5.6 禁用INNODB INNODB是MySQL被ORACLE收购后开发的，支持事务和行级锁等高级功能，但是并不是所有人都需要INNODB的，对大部分人来说，以前的MYISAM引擎就够了，一般会选择将默认引擎改为MYISAM，但是INNODB还是会耗费内存和硬盘，这时候，就需要把INNODB彻底禁用。 在以前的MySQL中，一般可以这么设置就行了： 复制代码 代码如下: default-storage-engine=MYISAM skip-innodb 但是在最新的MySQL5.6里，这么设置是没法启动的，需要再增加一句设置： 复制代码 代码如下: default-tmp-storage-engine=MYISAM 不仅如此，还需要添加以下配置，否则程序会很容易退出的： 复制代码 代码如下: loose-innodb-trx=0 loose-innodb-locks=0 loose-innodb-lock-waits=0 loose-innodb-cmp=0 loose-innodb-cmp-per-index=0 loose-innodb-cmp-per-index-reset=0 loose-innodb-cmp-reset=0 loose-innodb-cmpmem=0 loose-innodb-cmpmem-reset=0 loose-innodb-buffer-page=0 loose-innodb-buffer-page-lru=0 loose-innodb-buffer-pool-stats=0 loose-innodb-metrics=0 loose-innodb-ft-default-stopword=0 loose-innodb-ft-inserted=0 loose-innodb-ft-deleted=0 loose-innodb-ft-being-deleted=0 loose-innodb-ft-config=0 loose-innodb-ft-index-cache=0 loose-innodb-ft-index-table=0 loose-innodb-sys-tables=0 loose-innodb-sys-tablestats=0 loose-innodb-sys-indexes=0 loose-innodb-sys-columns=0 loose-innodb-sys-fields=0 loose-innodb-sys-foreign=0 loose-innodb-sys-foreign-cols=0 摘自http://docs.oracle.com/cd/E17952_01/refman-5.6-en/innodb-turning-off.html 另外MYSQL 5.6 比 5.5占用了更多的物理内存，虚拟内存跟5.5使用差不多（5.5也是一个虚拟内存消耗大户）。性能上比5.5提升了30%左右（根据官方文档，没作具体测试）。
今天发现有一个备份的mysql数据文件夹异常变大，一查发现是多了三个文件：ibdata1 ib_logfile0 ib_logfile1，前者18m，后两个各5m，原来是迁移的时候从mysql5.0迁移到了5.5，而5.5关闭innodb启动不起来，于是我就开启了innodb，由于innodb会默认增加这几个数据文件和日志文件，导致变大。尝试设置数据文件的大小，结果告诉我最小10m，还是太大，于是探索关闭innodb的方法。 看日志发现说由于mysql程序升级了，需要运行mysql_upgrade升级一下
1、打开主库和从库的MySQL服务，然后安装插件，半同步复制插件在目录/usr/local/mysql/lib/plugin下
大家可以看到，线程1，同样都是读 age >= 3 的数据。第一次读到1条数据，这个是原始状态。这之后线程2将id=2的age字段也改成了3。
所谓幻读，即一个事务在前后两次查询同一个范围的时候，后一次查询看到了前一次查询没有看到的行，这个回答估计大伙儿已经背烂了，但是它具体有什么后果呢？为什么会被 MySQL 单独拎出来解决呢？MySQL 又是如何解决的呢？
前段时间接触到腾讯云的一个新数据库产品 CynosDB 是基于 Amazon Aurora 数据库的Paper实现的。我比较感兴趣就来看看它和之前看过的 Spanner 之类有什么不同，也许部分设计也能用在我们游戏业务的服务器中。它的主要的创新点在于重新设计了binlog和存储的部分，所以我也主要就看了两篇Paper： 《Amazon Aurora - Design Considerations for High Throughput Cloud-Native Relational Databases》 是一个整体性质的介绍和概述； 《Amazon Aurora: On Avoiding Distributed Consensus for I/Os,Commits, and Membership Changes》 是对其重点部分的存储服务的。
一个线程在Serivcie时Select时选择的是从库，DynamicDataSourceHolder中ThreadLocal对应线程存储的是slave，然后调用Manager时进入事务，事务使用默认的transacatinManager关联的dataSource，而此时会不会获取到的是slave？
秒杀的场景有很多，比如：抢购、抢票、抢红包等等。总之，就是在极短时间内有大量的请求。
应该是处理此条消息的时候，实体类未序列化？然后我重试下，将实体类序列化去掉，这在运行时会直接异常的，目前原因不详。
脏读：当事务A正在访问数据并且做了修改（‘工资2000元’改成‘工资3000元’），但是还没来得及提交，这是事务B来访问数据并且使用了该数据（‘工资2000元’）
InnoDB串行化隔离级别使用间隙锁（gap lock）解决幻读（事务并发情况下两次查询的数据量不同）问题
mysql查询为什么会慢，关于这个问题，在实际开发经常会遇到，而面试中，也是个高频题。
昨天在CentOS 7上遇到MySQL 5.6遇到乱码问题，特此总结一下： 一、登录MySQL，用SHOW VARIABLES LIKE ‘character%’;查看下字符集，显示如下：
FTWRL执行时，要刷脏页数据到磁盘，因为要保持数据一致性，所以执行FTWRL的时机是所有事务都提交完毕后。
主库在提交事务时，在客户端接收到查询结束反馈前必须保证二进制日志已经传输到至少一台备库上。
TPS就是每秒钟所处理的事务数，那么到底什么是事务呢？ 事务是用户自定义的一个标识，是一个或多个操作完成一个业务所花费的时间，事务时间反映的是一个操作过程的响应时间。
来源：https://www.aneasystone.com/archives/2018/06/insert-locks-via-mysql-source-code.html
之前的一篇文章 《深入理解MySQL的MVCC原理》中总结了一下MySQL中的MVCC，它主要利用隐藏字段、版本链、ReadView来实现，可以用来更好地解决多个事务的并发【读+写】问题，但是如果在多个事务并发【写+写】的情况下，就必须要用到锁了，一般情况下，数据库的锁都是在有数据库操作的过程中自动添加的。
早期SUN公司想编写一套可以连接天下所有数据库的API，但是当他们刚刚开始时就发现这是不可完成的任务，因为各个厂商的数据库服务器差异太大了。后来SUN开始与数据库厂商们讨论，最终得出的结论是，由SUN提供一套访问数据库的规范（就是一组接口），并提供连接数据库的协议标准，然后各个数据库厂商会遵循SUN的规范提供一套访问自己公司的数据库服务器的API出现。SUN提供的规范命名为JDBC，而各个厂商提供的，遵循了JDBC规范的，可以访问自己数据库的API被称之为驱动。
2、登录MySQL，使用 show variables like ‘character%’;
财务替代中常用到的两种替代和一种检验，BTE与OBBH替代与OB28校验.在新系统里这些替代和校验调用的程序都要自己新建并且通过配置来分配，才能实现在标准程序运行的时候调用这些替代或者校验。以下是其建立步骤：
InnoDB采用MVCC来支持高并发，并且实现了4个标准的隔离级别。其默认的隔离级别是可重复读。当隔离级别是可重复读的时候，是会发生幻读的问题的。那么MySQL如何解决这个问题呢？
RU/RC 情况下加锁情况基本一致, 在加锁情况下脏读和不可重复读在任何一个隔离级别下都不会发生（因为读-写操作需要排队进行)
业务实践中，采购申请由需求部门提出来，需求部门不关心所需要的东西是从哪里购买的，他们只关心能不能在指定的日期获得指定的物品，所以他们创建的采购申请里是可以不指定source of supply的。等采购申请完成审批之后，再由采购人员转成采购订单，此时可以在采购订单上指派供应商了。
在《一文解析数据库的三生三世》这篇文章中，我们站在历史的角度认识了数据库的「前世今生」。文中提到在线事务处理等关键场景，那究竟什么是数据库的事务？为什么数据库需要支持事务？为了实现数据库事务，各种数据库是如何设计的？让我们一起来看看数据库事务的三个元问题吧！
TCC 是Try、Confirm、Cancel三个词语的缩写，TCC要求每个分支事务实现三个操作：预处理Try、确认Confirm、撤销Cancel。Try操作做业务检查及资源预留，Confirm做业务确认操作，Cancel实现一个与 Try或者 Commit相反的操作即回滚操作。TM首先发起所有的分支事务的 try操作，任何一个分支事务的 try操作执行失败，TM将会发起所有分支事务的 Cancel操作，若 Try操作全部成功，TM将会发起所有分支事务的 Confirm操作，其中 Confirm/Cancel 操作若执行失败，TM会进行重试。
我想再讨论一下上次的这篇文章《哎，被这个叫做at least once的玩意坑麻了》
preview[1] 如上图所示，路由器其实就是实现了网关的功能，网关是一个逻辑概念，指的是网络的出口和入口「网络边界」，而路由器则是一个物理概念，实现了网关的功能，是不同网关的沟通桥梁和物理基础。
对了，如果是宝塔面板安装，记得是在左侧菜单栏中改mysql的root账户的密码哦~
GreatSQL是由万里数据库维护的MySQL分支，开源、免费。GreatSQL基于Percona Server，在其基础上进一步提升MGR（MySQL Group Replication）的性能及可靠性。此外，GreatSQL合并了华为鲲鹏计算团队贡献的Patch，实现了InnoDB并行查询特性，以及对InnoDB事务锁的优化。
今天在用批处理进行MySQL自动备份的过程中遇到一个问题，错误提示：mysqldump: Got error: 2003: Can't connect to mysql server on '127.0.0.1' (10060)
键的管理： type del object encoding exists expire dbsize
mysqldump对于导出10G以下的数据库或几个表，还是适用的，而且更快捷。一旦数据量达到100-500G，无论是对原库的压力还是导出的性能，mysqldump就力不从心了。Percona-Xtrabackup备份工具，是实现MySQL在线热备工作的不二选择，可进行全量、增量、单表备份和还原。（但当数据量更大时，可能需要考虑分库分表，或使用 LVM 快照来加快备份速度了）。 2.2版本xtrabackup能对InnoDB和XtraDB存储引擎的数据库非阻塞地备份，innobackupex通过perl封装了一层xtrabackup，对MyISAM的备份通过加表读锁的方式实现。2.3版本xtrabackup命令直接支持MyISAM引擎。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
