合集-mysql入门到入焚

摘要:第零讲:基础架构:一条SQL查询语句是如何执行的目录第零讲:基础架构:一条SQL查询语句是如何执行的正确的认识事物的方式方法(极为重要):sql语句内部的执行过程:(极为重要)MySQL 可以分为 Server 层和存储引擎层两部分。Server 层存储引擎层每个组件的作用1.连接器职责:命令:作用:建立连接:认证身份获取权限管理连接2.查询缓存 阅读全文
posted @ 2024-07-19 10:22 guixiang 阅读(129) 评论(0) 推荐(0) 编辑
摘要:MySQL更新语句的执行流程涉及连接器、分析器、优化器、执行器等功能模块,以及重做日志和归档日志。重做日志采用WAL技术,先写日志再写磁盘,保证数据库异常重启时不会丢失已提交的记录,实现了crash-safe能力。归档日志记录原始逻辑,不同于重做日志的物理记录。文章详细介绍了更新语句的内部流程,包括执行器和InnoDB引擎的交互过程,以及重做日志的两阶段提交。通过对比重做日志和归档日志的特点,读者能够深入了解MySQL的日志系统设计和执行过程。 文章还介绍了MySQL里面最重要的两个日志,即物理日志redo log和逻辑日志binlog。redo log用于保证crash-safe能力。innodb_flush_log_at_trx_commit参数设置成1时,表示每次事务的redo log都直接持久化到磁盘,建议设置成1以保证数据不丢失。sync_binlog参数设置成1时,表示每次事务的binlog都持久化到磁盘,也建议设置成1以保证binlog不丢失。与MySQL日志系统密切相关的“两阶段提交”是跨系统维持数据逻辑一致性时常用的一个方案。 阅读全文
posted @ 2024-07-19 16:08 guixiang 阅读(93) 评论(0) 推荐(0) 编辑
摘要:目录第二讲:事务隔离:为什么你改了我还看不见定义隔离性与隔离级别隔离的缘由隔离的弊端事务隔离级别一个极为恰当的例子(重点关注“读提交”和“可重复读”):若隔离级别是“读未提交”数据库以视图方式执行引申:数据库迁移的注意事项如何配置默认级别设置本次会话的事务隔离级别,只在本会话有效,不会影响到其它会话 阅读全文
posted @ 2024-07-20 14:52 guixiang 阅读(57) 评论(0) 推荐(0) 编辑
摘要:目录第三讲:深入浅出的索引上:引入:索引的常见模型:哈希表:结论:有序数组:弊端:二叉搜索树特点:例子:思考:为什么数据库存储使用b+树 而不是二叉树“N 叉”树例子:笔锋一转InnoDB 的索引模型索引维护基于上面的索引维护过程说明,我们来讨论一个案例:小结:补充:问题: 第三讲:深入浅出的索引上 阅读全文
posted @ 2024-07-20 17:37 guixiang 阅读(80) 评论(0) 推荐(0) 编辑
摘要:目录第四讲:深入浅出索引(下)引入抛出问题:解决问题:覆盖索引引申:最左前缀原则示例:索引下推示例:分析:小结深入:问题:答案:深入分析上题: 第四讲:深入浅出索引(下) 引入 ​ 在上一篇文章中,我和你介绍了 InnoDB 索引的数据结构模型,今天我们再继续聊聊跟 MySQL 索引有关的概念。 抛 阅读全文
posted @ 2024-07-21 18:43 guixiang 阅读(72) 评论(0) 推荐(0) 编辑
摘要:目录第五讲:全局锁和表锁 :给表加个字段怎么有这么多阻碍?引言:锁的分类:全局锁场景:弊端:好处分析:回顾:提出问题:问题一:问题二:表级锁表锁:元数据锁(MDL)案例:变故发生:基于案列说问题:操作小结提问:官方:我的理解(片面了):深入: 第五讲:全局锁和表锁 :给表加个字段怎么有这么多阻碍? 阅读全文
posted @ 2024-07-22 13:56 guixiang 阅读(84) 评论(0) 推荐(0) 编辑
摘要:目录第六讲:行锁功过:怎么减少行锁对性能的影响?闲聊:行锁是什么两阶段锁协议示例:死锁和死锁检测第一种策略:第二种策略:策略分析场景提问:要把死锁关掉吗?控制并发度是否可以解决那怎么办小结深入:第一条:第二条:第三条提问:答案 第六讲:行锁功过:怎么减少行锁对性能的影响? 闲聊: ​ 在上一篇文章中 阅读全文
posted @ 2024-07-22 15:09 guixiang 阅读(83) 评论(0) 推荐(0) 编辑
摘要:目录第七讲:事务到底是隔离的还是不隔离的?前言:示例:结果:视图概念深入了解MVCC“快照”在 MVCC 里是怎么工作的?回顾实现方式更新逻辑小结深入:NO.1思考:答案: 第七讲:事务到底是隔离的还是不隔离的? 前言: ​ 我在第 3 篇文章和你讲事务隔离级别的时候提到过,如果是可重复读隔离级别, 阅读全文
posted @ 2024-07-23 21:22 guixiang 阅读(67) 评论(0) 推荐(0) 编辑
摘要:目录第八讲:普通索引和唯一索引,应该怎么选择?日常日常开头:日常提问:查询过程:日常答案更新过程不同索引的更新第一种情况是,这个记录要更新的目标页在内存中。第二种情况是,这个记录要更新的目标页不在内存中。一个更新事故:change buffer 的使用场景索引选择和实践change buffer 和 阅读全文
posted @ 2024-07-25 15:31 guixiang 阅读(52) 评论(0) 推荐(0) 编辑
摘要:第九讲: MySQL为什么有时候会选错索引? ​ 前面我们介绍过索引,你已经知道了在 MySQL 中一张表其实是可以支持多个索引的。 ​ 但是,你写 SQL 语句的时候,并没有主动指定使用哪个索引。也就是说,使用哪个索引是由 MySQL 来确定的。不知道你有没有碰到过这种情况,一条本来可以执行得很快 阅读全文
posted @ 2024-07-25 15:58 guixiang 阅读(24) 评论(0) 推荐(0) 编辑
摘要:第十讲:怎么给字符串字段加索引? ​ 现在,几乎所有的系统都支持邮箱登录,如何在邮箱这样的字段上建立合理的索引,是我们今天要讨论的问题。 总概 类似邮箱登录系统的长表索引 假设,你现在维护一个支持邮箱登录的系统,用户表是这么定义的: mysql> create table SUser( ID big 阅读全文
posted @ 2024-09-02 20:03 guixiang 阅读(32) 评论(0) 推荐(0) 编辑
摘要:目录第十讲:为什么我的MySQL会“抖”一下?图概:提出现实问题: SQL 执行的时候特别快,有时变得特别慢原因:为什么有时会“flush”呢?第一种场景,粉板满了,记不下了。第二种场景,要记住的事情太多,自己快记不住了,找账本把这笔账先加进去。第三种场景是,生意不忙,打烊之后柜台没事,掌柜闲着也是 阅读全文
posted @ 2024-09-04 21:30 guixiang 阅读(32) 评论(0) 推荐(0) 编辑
摘要:第十二讲: 为什么表数据删掉一半,表文件大小不变? 简概: 问题:表删掉了一半的数据,表文件的大小还是没变? ​ 经常会有同学来问我,我的数据库占用空间太大,我把一个最大的表删掉了一半的数据,怎么表文件的大小还是没变? InnoDB 的表回收 ​ 那么今天,我就和你聊聊数据库表的空间回收,看看如何解 阅读全文
posted @ 2024-09-05 20:52 guixiang 阅读(48) 评论(0) 推荐(0) 编辑
摘要:第十三讲:count(*)这么慢,我该怎么办? 简概: count(*) 的实现方式 ​ 你首先要明确的是,在不同的 MySQL 引擎中,count() 有不同的实现方式。 MyISAM 引擎把一个表的总行数存在了磁盘上,因此执行 count() 的时候会直接返回这个数,效率很高; 而 InnoDB 阅读全文
posted @ 2024-09-06 18:31 guixiang 阅读(43) 评论(0) 推荐(0) 编辑
摘要:第十四讲:答疑文章(一):日志和索引相关问题 简概: ​ 到目前为止,我已经收集了 47 个问题,很难通过今天这一篇文章全部展开。所以,我就先从中找了几个联系非常紧密的问题,串了起来,希望可以帮你解决关于日志和索引的一些疑惑。而其他问题,我们就留着后面慢慢展开吧。 ​ 我在第 2 篇文章《日志系统: 阅读全文
posted @ 2024-09-07 22:03 guixiang 阅读(38) 评论(0) 推荐(0) 编辑
摘要:该文章简述了order by排序的两种策略,一个是全字段排序:将字段全部放到sort__buffer里面,在内存内部排序(内存要求高),另一个是rowid排序:将order后面的指定字段与ID一起扔到内存排序,但因为如果查询有其他字段,他会再次回到表进行一次主键索引(因此相对而言内存消耗更小),之后为了更加快速,我们想到了前面的覆盖索引(这样可以避免创建临时表,前面的两个策略都创建了临时表),大概就是建立联合索引将我们所要查询的字段全部包涵进去,而且这还免去的排序,快的一批,但这样会加重后续索引维护,各有利弊 阅读全文
posted @ 2024-09-08 21:56 guixiang 阅读(27) 评论(0) 推荐(0) 编辑
摘要:第十六讲:如何正确地显示随机消息?该文章承接上一篇order by排序,进一步提出随机挑选数据的问题,站在大量数据查询的情况下:提出select word from words order by rand() limit 3;这种我们经常使用的查询语句的弊端:既要建立临时表排序(这里优化器使用的rowid排序)而且如果表中有一万条数据,那么扫描行数高达2万零三条(虽然sort_buffer排序不涉及表操作,不扫描表,这里需要注意临时表,上一张没细讲,就是因为使用另一个引擎,先后从memory到innodb引擎读了1万条数据),此外,拓宽了上一张rowid主键的范围(也可以是系统建的默认递增主键),还有优先队列排序法也挺有意思(与归并排序算法区分下),为了解决上面随机查询的弊端,我们提出了随机排序算法(这里要注意数据空洞,不能用大小比较)利用变量,字符串拼接,预处理语句十分有意思 阅读全文
posted @ 2024-09-09 20:34 guixiang 阅读(13) 评论(0) 推荐(0) 编辑
摘要:该文章中,提出了”有很多看上去逻辑相同,但性能却差异巨大的 SQL 语句”提出索引树罢工的现象分析了三个原因:where后面函数操作,多表查询字段类型冲突,utf-8字符编码冲突(俗称隐式类型转换),正因如此索引就会罢工(explain中key显示NULL),这边还顺便介绍了驱动表(多表查询from后面的是被驱动表),最后要强调的是select * from table where id + 1 = 10000 这个 SQL 语句与select * from table where id = 10000-1(这道题体现文章核心思想) 两者间查询效率相差极大 阅读全文
posted @ 2024-09-12 20:21 guixiang 阅读(22) 评论(0) 推荐(0) 编辑
摘要:和上篇文章不同,文章探讨了我们正常执行sql语句慢的原因:第一:其他进程正在DML写锁,需要kill或等待,第二flush刷盘flush在关闭session途中被别的命令堵住了,进一步堵住select查询,如sleep,第三,在引擎层面update存在且不提交写锁也会被堵住(这边还介绍了kill query与kill的去别,十分实用),第四:查询慢还可以是索引:走主键顺序扫描(可以在慢查询日志里找),第五:就算只扫描一行,但还是慢,还可以是事务一直没提交,造成undolog回滚日志特别长,如果没有加“lock in share mode”,那读取数据得先回滚到上一个版本再读取。 阅读全文
posted @ 2024-09-12 21:54 guixiang 阅读(18) 评论(0) 推荐(0) 编辑
摘要:文章以幻读起手,以假设的方式钻“加锁”的空子,引出“间隙锁”(也就是现在的mysql锁机制),但就算这样,在可重复读的隔离级别下也会发生死锁,即使对行锁有准确的认识,也可能会因为间隙锁翻车,像两个session同时占用一个主键(注意:与行锁不同,他没有锁之间的冲突)插入操作时都会被对方的间隙锁挡住(虽然很行锁很相似,但他们的加锁位置不同) 阅读全文
posted @ 2024-09-13 21:45 guixiang 阅读(65) 评论(0) 推荐(0) 编辑

点击右上角即可分享
微信分享提示