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

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

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

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

一 .本节内容概要 前面我们介绍过索引,你已经知道了在 MySQL 中一张表其实是可以支持多个索引的.但是,你写 SQL 语句的时候,并没有主动指定使用哪个索引.也就是说,使用哪个索引是由MySQL 来确定的. 不知道你有没有碰到过这种情况,一条本来可以执行得很快的语句,却由于 MySQL 选错了索引,而导致执行速度变得很慢? 我们一起来看一个例子吧. 我们先建一个简单的表,表里有 a.b 两个字段,并分别建上索引: CREATE TABLE `t` ( `id` int(11) NOT NUL…

一.引子 平时的工作中,不知道你有没有遇到过这样的场景,一条 SQL 语句,正常执行的时候特别快,但是有时也不知道怎么回事,它就会变得特别慢,并且这样的场景很难复现,它不只随机,而且持续时间还很短. 看上去,这就像是数据库“抖”了一下.今天,我们就一起来看一看这是什么原因. 二.你的 SQL 语句为什么变“慢”了 在前面第 2 篇文章<日志系统:一条 SQL 更新语句是如何执行的?>中,我为你介绍了WAL 机制.现在你知道了,InnoDB 在处理更新语句的时候,只做了写日志这一个磁盘操作.这个…

一.引子 经常会有同学来问我,我的数据库占用空间太大,我把一个最大的表删掉了一半的数据,怎么表文件的大小还是没变? 那么今天,我就和你聊聊数据库表的空间回收,看看如何解决这个问题. 这里,我们还是针对 MySQL 中应用最广泛的 InnoDB 引擎展开讨论.一个 InnoDB 表包含两部分,即:表结构定义和数据.在 MySQL 8.0 版本以前,表结构是存在以.frm 为后缀的文件里.而 MySQL 8.0 版本,则已经允许把表结构定义放在系统数据表中了.因为表结构定义占用的空间很小,所以我们今…

一.今日内容概要 在你开发应用的时候,一定会经常碰到需要根据指定的字段排序来显示结果的需求.还是以我们前面举例用过的市民表为例,假设你要查询城市是“杭州”的所有人名字,并且按照姓名排序返回前 1000 个人的姓名.年龄. 假设这个表的部分定义是这样的: CREATE TABLE `t` ( `id` int(11) NOT NULL, `city` varchar(16) NOT NULL, `name` varchar(16) NOT NULL, `age` int(11) NOT NULL,…

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

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

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

一.引子 在开发系统的时候,你可能经常需要计算一个表的行数,比如一个交易系统的所有变更记录总数.这时候你可能会想,一条 select count(*) from t 语句不就解决了吗? 但是,你会发现随着系统中记录数越来越多,这条语句执行得也会越来越慢.然后你可能就想了,MySQL 怎么这么笨啊,记个总数,每次要查的时候直接读出来,不就好了吗. 那么今天,我们就来聊聊 count(*) 语句到底是怎样实现的,以及 MySQL 为什么会这么实现.然后,我会再和你说说,如果应用中有这种频繁变更并需要…

一.引子 在 MySQL 中,有很多看上去逻辑相同,但性能却差异巨大的 SQL 语句.对这些语句使用不当的话,就会不经意间导致整个数据库的压力变大. 我今天挑选了三个这样的案例和你分享.希望再遇到相似的问题时,你可以做到举一反三.快速解决问题. 二.案例一:条件字段函数操作 假设你现在维护了一个交易系统,其中交易记录表 tradelog 包含交易流水号(tradeid).交易员 id(operator).交易时间(t_modified)等字段.为了便于描述,我们先忽略其他字段.这个表的建表语句如…

一.引子 一般情况下,如果我跟你说查询性能优化,你首先会想到一些复杂的语句,想到查询需要返回大量的数据.但有些情况下,“查一行”,也会执行得特别慢.今天,我就跟你聊聊这个有趣的话题,看看什么情况下,会出现这个现象. 需要说明的是,如果 MySQL 数据库本身就有很大的压力,导致数据库服务器 CPU 占用率很高或 ioutil(IO 利用率)很高,这种情况下所有语句的执行都有可能变慢,不属于我们今天的讨论范围. 为了便于描述,我还是构造一个表,基于这个表来说明今天的问题.这个表有两个字段 id和…

一.引子 在上一篇文章最后,我给你留了一个关于加锁规则的问题.今天,我们就从这个问题说起吧. 为了便于说明问题,这一篇文章,我们就先使用一个小一点儿的表.建表和初始化语句如下(为了便于本期的例子说明,我把上篇文章中用到的表结构做了点儿修改): CREATE TABLE `t` ( `id` int(11) NOT NULL, `c` int(11) DEFAULT NULL, `d` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `c` (`c`)…

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

参考极客时间专栏<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 是唯…

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

一.本节概况 今天是大年初二,在开始我们今天的学习之前,我要先和你道一声春节快乐! 在第 16和第 34篇文章中,我分别和你介绍了 sort buffer.内存临时表和 join buffer.这三个数据结构都是用来存放语句执行过程中的中间数据,以辅助 SQL 语句的执行的.其中,我们在排序的时候用到了 sort buffer,在使用 join 语句的时候用到了 join buffer. 然后,你可能会有这样的疑问,MySQL 什么时候会使用内部临时表呢? 今天这篇文章,我就先给你举两个需要用到…

一.引子 今天是大年三十,在开始我们今天的学习之前,我要先和你道一声春节快乐! 在上一篇文章中,我们在优化 join 查询的时候使用到了临时表.当时,我们是这么用的: create temporary table temp_t like t1; alter table temp_t add index(b); insert into temp_t select * from t2 where b>=1 and b<=2000; select * from t1 join temp_t on (…

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

一.本节概述 在上一篇文章中,我和你介绍了 join 语句的两种算法,分别是 Index Nested-LoopJoin(NLJ) 和 Block Nested-Loop Join(BNL). 我们发现在使用 NLJ 算法的时候,其实效果还是不错的,比通过应用层拆分成多个语句然后再拼接查询结果更方便,而且性能也不会差. 但是,BNL 算法在大表 join 的时候性能就差多了,比较次数等于两个表参与 join 的行数的乘积,很消耗 CPU 资源. 当然了,这两个算法都还有继续优化的空间,我们今天就…

一.本节分析案例 在 MySQL 中有两个 kill 命令:一个是 kill query + 线程 id,表示终止这个线程中正在执行的语句:一个是 kill connection + 线程 id,这里 connection 可缺省,表示断开这个线程的连接,当然如果这个线程有语句正在执行,也是要先停止正在执行的语句的. 不知道你在使用 MySQL 的时候,有没有遇到过这样的现象:使用了 kill 命令,却没能断开这个连接.再执行 show processlist 命令,看到这条语句的 Comman…

一.本节概览 今天我要和你讨论的是一个沉重的话题:误删数据. 在前面几篇文章中,我们介绍了 MySQL 的高可用架构.当然,传统的高可用架构是不能预防误删数据的,因为主库的一个 drop table 命令,会通过 binlog 传给所有从库和级联从库,进而导致整个集群的实例都会执行这个命令. 虽然我们之前遇到的大多数的数据被删,都是运维同学或者 DBA 背锅的.但实际上,只要有数据操作权限的同学,都有可能踩到误删数据这条线. 今天我们就来聊聊误删数据前后,我们可以做些什么,减少误删数据的风险,和…

一.引子 我经常会被问到这样一个问题:我的主机内存只有 100G,现在要对一个 200G 的大表做全表扫描,会不会把数据库主机的内存用光了? 这个问题确实值得担心,被系统 OOM(out of memory)可不是闹着玩的.但是,反过来想想,逻辑备份的时候,可不就是做整库扫描吗?如果这样就会把内存吃光,逻辑备份不是早就挂了? 所以说,对大表做全表扫描,看来应该是没问题的.但是,这个流程到底是怎么样的呢? 二.全表扫描对 server 层的影响 假设,我们现在要对一个 200G 的 InnoDB…

一.本节概述 在实际生产中,关于 join 语句使用的问题,一般会集中在以下两类: 1. 我们 DBA 不让使用 join,使用 join 有什么问题呢?2. 如果有两个大小不同的表做 join,应该用哪个表做驱动表呢? 今天这篇文章,我就先跟你说说 join 语句到底是怎么执行的,然后再来回答这两个问题.为了便于量化分析,我还是创建两个表 t1 和 t2 来和你说明. 可以看到,这两个表都有一个主键索引 id 和一个索引 a,字段 b 上无索引.存储过程idata() 往表 t2 里插入了 1…

一.复习一下加锁规则 在第20和21篇文章中,我和你介绍了 InnoDB 的间隙锁.next-key lock,以及加锁规则.在这两篇文章的评论区,出现了很多高质量的留言.我觉得通过分析这些问题,可以帮助你加深对加锁规则的理解. 所以,我就从中挑选了几个有代表性的问题,构成了今天这篇答疑文章的主题,即:用动态的观点看加锁. 为了方便你理解,我们再一起复习一下加锁规则.这个规则中,包含了两个“原则”.两个“优化”和一个“bug”: 原则 1:加锁的基本单位是 next-key lock.希望你还记…

一.本节概述 MySQL 里有很多自增的 id,每个自增 id 都是定义了初始值,然后不停地往上加步长.虽然自然数是没有上限的,但是在计算机里,只要定义了表示这个数的字节长度,那它就有上限.比如,无符号整型 (unsigned int) 是 4 个字节,上限就是 2 -1. 既然自增 id 有上限,就有可能被用完.但是,自增 id 用完了会怎么样呢? 今天这篇文章,我们就来看看 MySQL 里面的几种自增 id,一起分析一下它们的值达到上限以后,会出现什么情况. 二.表定义自增值 id 说到自增…

一.重要的日志模块:redo log 1.通过酒店掌柜记账思路刨析redo log工作原理 2.InnoDB 的 redo log 是固定大小的 只要赊账记录在了粉板上或写了账本上,之后即使掌柜忘记了,比如停业几天,回复生意后依然可以通过账本和粉板上的数据明确赊账账目 有了redo log,InnoDB就可以保证即使数据库发生异常重启,之前提交的记录都不会丢失,这个能力成为crash-safe二.重要的日志模块:binlog 二.重要的日志模块binlog 1.redo和三点区别binlog r…