一.今日内容概要 今天我要跟你聊聊 MySQL 的锁.数据库锁设计的初衷是处理并发问题.作为多用户共享的资源,当出现并发访问的时候,数据库需要合理地控制资源的访问规则.而锁就是用来实现这些访问规则的重要数据结构. 根据加锁的范围,MySQL 里面的锁大致可以分成全局锁.表级锁和行锁三类.今天这篇文章,我会和你分享全局锁和表级锁.而关于行锁的内容,我会留着在下一篇文章中再和你详细介绍. 这里需要说明的是,锁的设计比较复杂,这两篇文章不会涉及锁的具体实现细节,主要介绍的是碰到锁时的现象和其背后的原理

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

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

极客时间 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这种索引结构,可以利用索引的"最左前

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

在<极客时间>订阅了<MySQL实战45讲>专栏,总觉得看完和没看一样

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

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

课程介绍(第一讲) linux介绍安装(第二讲) linux的基础操作(第三讲) ROS中语言c++与python介绍(第四讲) 安装ROS系统(第五讲) 第一个: sudo sh -c echo deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main /etc/apt/sources.list.d/ros-latest.list第二个: sudo apt-key adv --keyserver hkp://keyserver

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

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

一.引子 今天是大年三十,在开始我们今天的学习之前,我要先和你道一声春节快乐! 在上一篇文章中,我们在优化 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 (

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

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

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