参考极客时间专栏<MySQL实战45讲>学习笔记 一.基础篇(8讲) MySQL实战45讲学习笔记:第一讲 MySQL实战45讲学习笔记:第二讲 MySQL实战45讲学习笔记:第三讲 MySQL实战45讲学习笔记:第四讲 MySQL实战45讲学习笔记:第五讲 MySQL实战45讲学习笔记:第六讲 MySQL实战45讲学习笔记:第七讲 MySQL实战45讲学习笔记:第八讲 二.实践篇-索引(8讲) MySQL实战45讲学习笔记:第九讲 MySQL实战45讲学习笔记:第十讲 MySQL实战45讲学…

一.本节概况 MySQL实战45讲学习笔记:自增主键为什么不是连续的?(第39讲) 在第 4 篇文章中,我们提到过自增主键,由于自增主键可以让主键索引尽量地保持递增顺序插入,避免了页分裂,因此索引更紧凑. 之前我见过有的业务设计依赖于自增主键的连续性,也就是说,这个设计假设自增主键是连续的.但实际上,这样的假设是错的,因为自增主键不能保证连续递增. 今天这篇文章,我们就来说说这个问题,看看什么情况下自增主键会出现 “空洞”? 为了便于说明,我们创建一个表 t,其中 id 是自增主键字段.c 是唯…

一.引子 在前面的文章中,我不止一次地和你提到了 binlog,大家知道 binlog 可以用来归档,也可以用来做主备同步,但它的内容是什么样的呢?为什么备库执行了 binlog 就可以跟主库保持一致了呢?今天我就正式地和你介绍一下它. 毫不夸张地说,MySQL 能够成为现下最流行的开源数据库,binlog 功不可没. 在最开始,MySQL 是以容易学习和方便的高可用架构,被开发人员青睐的.而它的几乎所有的高可用架构,都直接依赖于 binlog.虽然这些高可用架构已经呈现出越来越复杂的趋势,但都…

一.引子 在今天这篇答疑文章更新前,MySQL 实战这个专栏已经更新了 14 篇.在这些文章中,大家在评论区留下了很多高质量的留言.现在,每篇文章的评论区都有热心的同学帮忙总结文章知识点,也有不少同学提出了很多高质量的问题,更有一些同学帮忙解答其他同学提出的问题. 在浏览这些留言并回复的过程中,我倍受鼓舞,也尽我所知地帮助你解决问题.和你讨论.可以说,你们的留言活跃了整个专栏的氛围.提升了整个专栏的质量,谢谢你们.评论区的大多数留言我都直接回复了,对于需要展开说明的问题,我都拿出小本子记了下来.…

一.隔离性与隔离级别 1.事务的特性 原子性 一致性 隔离性 持久性 2.不同事务隔离级别的区别 读未提交:别人改数据的事务尚未提交,我在我的事务中也能读到.读已提交:别人改数据的事务已经提交,我在我的事务中才能读到.可重复读:别人改数据的事务已经提交,我在我的事务中也不去读.串行:我的事务尚未提交,别人就别想改数据.这4种隔离级别,并行性能依次降低,安全性依次提高. 3.读提交”和“可重复读” 假设数据表T中只有一列,期中一行的值为1,下面是按照时间顺序执行两个事物的行为 mysql> cre…

一.引子 在上一篇文章中,我和你介绍了 binlog 的基本内容,在一个主备关系中,每个备库接收主库的 binlog 并执行. 正常情况下,只要主库执行更新生成的所有 binlog,都可以传到备库并被正确地执行,备库就能达到跟主库一致的状态,这就是最终一致性. 但是,MySQL 要提供高可用能力,只有最终一致性是不够的.为什么这么说呢?今天我就着重和你分析一下. 这里,我再放一次上一篇文章中讲到的双 M 结构的主备切换流程图.  图 1 MySQL 主备切换流程 -- 双 M 结构 二.主备延迟…

一.引子 在上一篇文章中,我和你介绍了几种可能导致备库延迟的原因.你会发现,这些场景里,不论是偶发性的查询压力,还是备份,对备库延迟的影响一般是分钟级的,而且在备库恢复正常以后都能够追上来. 但是,如果备库执行日志的速度持续低于主库生成日志的速度,那这个延迟就有可能成了小时级别.而且对于一个压力持续比较高的主库来说,备库很可能永远都追不上主库的节奏. 这就涉及到今天我要给你介绍的话题:备库并行复制能力. 二.备库并行复制能力 1.在官方的 5.6 版本之前,MySQL 只支持单线程复制 为了便于…

一.引子 不知道你在实际运维过程中有没有碰到这样的情景:业务高峰期,生产环境的 MySQL 压力太大,没法正常响应,需要短期内.临时性地提升一些性能. 我以前做业务护航的时候,就偶尔会碰上这种场景.用户的开发负责人说,不管你用什么方案,让业务先跑起来再说. 但,如果是无损方案的话,肯定不需要等到这个时候才上场.今天我们就来聊聊这些临时方案,并着重说一说它们可能存在的风险 二.短连接风暴 正常的短连接模式就是连接到数据库后,执行很少的 SQL 语句就断开,下次需要的时候再重连.如果使用的是短连接,…

一.本节概要 今天这篇文章,我会继续和你介绍在业务高峰期临时提升性能的方法.从文章标题“MySQL 是怎么保证数据不丢的?”,你就可以看出来,今天我和你介绍的方法,跟数据的可靠性有关. 在专栏前面文章和答疑篇中,我都着重介绍了 WAL 机制(你可以再回顾下第 2 篇.第 9篇.第 12 篇和第 15 篇文章中的相关内容),得到的结论是:只要 redo log 和 binlog保证持久化到磁盘,就能确保 MySQL 异常重启后,数据可以恢复. 评论区有同学又继续追问,redo log 的写入流程是…

一.引子 我在第25和27篇文章中,和你介绍了主备切换流程.通过这些内容的讲解,你应该已经很清楚了:在一主一备的双 M 架构里,主备切换只需要把客户端流量切到备库:而在一主多从架构里,主备切换除了要把客户端流量切到备库外,还需要把从库接到新主库上. 主备切换有两种场景,一种是主动切换,一种是被动切换.而其中被动切换,往往是因为主库出问题了,由 HA 系统发起的. 这也就引出了我们今天要讨论的问题:怎么判断一个主库出问题了? 你一定会说,这很简单啊,连上 MySQL,执行个 select 1 就好…