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

<MySQL实战45讲>笔记 目录 <MySQL实战45讲>笔记 第一节: 基础架构:一条SQL查询语句是如何执行的? 连接器 查询缓存 分析器 优化器 执行器 第二节:日志系统:一条SQL更新语句是如何执行的? 重要的日志模块:redo log 重要的日志模块:binlog 两阶段提交 总结 第三节:03.事务隔离:为什么你改了我还看不见? 隔离性与隔离级别 事务隔离的实现 事务的启动方式 如何避免长事务 第四节: 深入浅出索引(上) 第五节: 深入浅出索引(下) 第六节: 全局

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

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

MySQL实战45讲 目录 MySQL实战45讲 第八节: 事务到底是隔离的还是不隔离的? 在MySQL里,有两个"视图"的概念: "快照"在MVCC里是怎么工作的? 我们继续看一下图1中的三个事务,分析下事务A的语句返回的结果,为什么是k=1. 更新逻辑 事务的可重复读的能力是怎么实现的? 小结 第九节: 普通索引和唯一索引,应该怎么选择? 查询过程 更新过程 change buffer的使用场景 索引选择和实践 change buffer 和 redo log

拜读了林晓斌大佬的<MySQL实战45讲>,特意做个知识点总结,以便后期回忆. 01.基础架构:一条SQL查询语句是如何执行的? Server 层包括连接器.查询缓存.分析器.优化器.执行器等,涵盖 MySQL 的大多数核心服务功能,以及所有的内置函数(如日期.时间.数学和加密函数等),所有跨存储引擎的功能都在这一层实现,比如存储过程.触发器.视图等.而存储引擎层负责数据的存储和提取.其架构模式是插件式的,支持 InnoDB.MyISAM.Memory 等多个存储引擎.现在最常用的存储引擎是

极客时间 Mysql实战45讲 07讲行锁功过:怎么减少行锁对性能的影响笔记 极客时间极客时间 Mysql实战45讲 07讲行锁功过:怎么减少行锁对性能的影响笔记 极客时间 笔记体会: 方案一,事务相对较长,则占用锁的时间较长,会导致其他客户端等待资源时间较长.方案二,串行化执行,将相对长的事务分成多次相对短的事务,则每次事务占用锁的时间相对较短,其他客户端在等待相应资源的时间也较短.这样的操作,同时也意味着将资源分片使用(每次执行使用不同片段的资源),可以提高并发性.方案三,人为自己制造锁竞争

Mysql实战45讲 极客时间 读书笔记 Mysql实战45讲 极客时间 读书笔记 笔记体会: 根据加锁范围:MySQL里面的锁可以分为:全局锁.表级锁.行级锁 一.全局锁:对整个数据库实例加锁.MySQL提供加全局读锁的方法:Flush tables with read lock(FTWRL)这个命令可以使整个库处于只读状态.使用该命令之后,数据更新语句.数据定义语句和更新类事务的提交语句等操作都会被阻塞.使用场景:全库逻辑备份.风险:1.如果在主库备份,在备份期间不能更新,业务停摆2.如果在

极客时间 Mysql实战45讲 04讲深入浅出索引(下)极客时间 笔记体会: 回表:回到主键索引树搜索的过程,称为回表覆盖索引:某索引已经覆盖了查询需求,称为覆盖索引,例如:select ID from T where k between 3 and 5在引擎内部使用覆盖索引在索引K上其实读了三个记录,R3~R5(对应的索引k上的记录项),但对于MySQL的Server层来说,它就是找引擎拿到了两条记录,因此MySQL认为扫描行数是2最左前缀原则:B+Tree这种索引结构,可以利用索引的"最左前

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

极客时间 Mysql实战45讲 04讲深入浅出索引 极客时间(上)读书笔记  笔记体悟 1.索引的作用:提高数据查询效率2.常见索引模型:哈希表.有序数组.搜索树3.哈希表:键 - 值(key - value).4.哈希思路:把值放在数组里,用一个哈希函数把key换算成一个确定的位置,然后把value放在数组的这个位置5.哈希冲突的处理办法:链表6.哈希表适用场景:只有等值查询的场景7.有序数组:按顺序存储.查询用二分法就可以快速查询,时间复杂度是:O(log(N))8.有序数组查询效率高,更新

一.一主多从的切换正确性 在前面的第24.25和26篇文章中,我和你介绍了 MySQL 主备复制的基础结构,但这些都是一主一备的结构. 大多数的互联网应用场景都是读多写少,因此你负责的业务,在发展过程中很可能先会遇到读性能的问题.而在数据库层解决读性能问题,就要涉及到接下来两篇文章要讨论的架构:一主多从. 今天这篇文章,我们就先聊聊一主多从的切换正确性.然后,我们在下一篇文章中再聊聊解决一主多从的查询逻辑正确性的方法. 1.一主多从基本结构 如图 1 所示,就是一个基本的一主多从结构. 图 1

参考极客时间专栏<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讲>专栏,总觉得看完和没看一样

之前,你大概都是通过搜索别人的经验来解决问题.如果能够理解MySQL的工作原理,那么在遇到问题的时候,是不是就能更快地直戳问题的本质? 以实战中的常见问题为切入点,带你剖析现象背后的本质原因.为你串起各个零散的知识点,再由线到面带你构建MySQL知识体系.旨在给你一个从理论到实战的系统性指导,让你少走弯路,彻底搞懂MySQL. 林晓斌,网名丁奇,前阿里资深技术专家.作为活跃的MySQL社区贡献者,丁奇专注于数据存储系统.MySQL性能优化和功能改进,热衷于解决MySQL疑难问题. MySQL实战

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

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

一.读写分离架构 在上一篇文章中,我和你介绍了一主多从的结构以及切换流程.今天我们就继续聊聊一主多从架构的应用场景:读写分离,以及怎么处理主备延迟导致的读写分离问题. 我们在上一篇文章中提到的一主多从的结构,其实就是读写分离的基本结构了.这里,我再把这张图贴过来,方便你理解. 1.读写分离基本结构 图 1 读写分离基本结构 读写分离的主要目标就是分摊主库的压力.图 1 中的结构是客户端(client)主动做负载均衡,这种模式下一般会把数据库的连接信息放在客户端的连接层.也就是说,由客户端来选择后

21 | 为什么我只改一行的语句,锁这么多? 加锁规则里面:包含了两个"原则".两个"优化"和一个"bug". 原则 1:加锁的基本单位是 next-key lock.希望你还记得,next-key lock 是前开后闭区 间. 原则 2:查找过程中访问到的对象才会加锁. 优化 1:索引上的等值查询,给唯一索引加锁的时候,next-key lock 退化为行锁. 优化 2:索引上的等值查询,向右遍历时且最后一个值不满足等值条件的时候,next-k

一.本节内容 我在上一篇文章末尾留给你的问题是:两个 group by 语句都用了 order by null,为什么使用内存临时表得到的语句结果里,0 这个值在最后一行:而使用磁盘临时表得到的结果里,0 这个值在第一行? 今天我们就来看看,出现这个问题的原因吧. 二.内存表的数据组织结构 1.两个查询结果 -0 的位置 为了便于分析,我来把这个问题简化一下,假设有以下的两张表 t1 和 t2,其中表 t1 使用Memory 引擎, 表 t2 使用 InnoDB 引擎. create table