基础篇
Day 1
01 | 基础架构:一条SQL查询语句是如何执行的?
- MySQL 可以分为 Server 层和存储引擎层两部分。
- 尽量使用长连接,避免内存过大没释放的办法
- 不要使用查询缓存
- 总结,sever层:连接器,分析器,优化器,执行器
Day2
02 | 日志系统:一条SQL更新语句是如何执行的?
- 与查询流程不一样的是,更新流程还涉及两个重要的日志模块
- redo log(重做日志)和 binlog(归档日志)
- WAL 的全称是 Write-Ahead Logging,它的关键点就是先写日志,再写磁盘,也就是先写粉板,等不忙的时候再写账本
- 当有一条记录需要更新的时候,InnoDB 引擎就会先把记录写到 redo log(粉板)里面,并更新内存,这个时候更新就算完成了。同时,InnoDB 引擎会在适当的时候,将这个操作记录更新到磁盘里面
- innoDB 的 redo log 是固定大小的,比如可以配置为一组 4 个文件,每个文件的大小是 1GB,那么这块“粉板”总共就可以记录 4GB 的操作
- 浅色框表示是在 InnoDB 内部执行的,深色框表示是在执行器中执行的
- 两阶段提交(上图后3步)将 redo log 的写入拆成了两个步骤:prepare 和 commit
Day3
03 | 事务隔离:为什么你改了我还看不见?
- ACID(Atomicity、Consistency、Isolation、Durability,即原子性、一致性、隔离性、持久性)
- 现在用的是,mysql5.6 默认是 可重复读(repeatable read)
- 对于一些从 Oracle 迁移到 MySQL 的应用,为保证数据库隔离级别的一致,你一定要记得将 MySQL 的隔离级别设置为“读提交”
Day4
04 05 | 深入浅出索引
- 索引模型:哈希表、有序数组和搜索树
- 每一个索引在 InnoDB 里面对应一棵 B+ 树。
- 普通索引查询方式,则需要先搜索 k 索引树,再到 ID 索引树搜索一次。这个过程称为回表
- 基于非主键索引的查询需要多扫描一棵索引树。因此,我们在应用中应该尽量使用主键查询
- 一般需要用自增量设置主键 NOT NULL PRIMARY KEY AUTO_INCREMENT
- KEY-VALUE类型可以不用自增量,直接设置KEY为主键
- 覆盖索引:查询选择的列已经在普通索引树上,就不需要回表
- 最左前缀:不只是索引的全部定义,只要满足最左前缀,就可以利用索引来加速检索 例如 name like '朱%',name的索引也起作用
- 联合索引:(a,b) 符合最左前缀,mysql5.6后可以索引下推,减少回表次数。
Day5
06 | 全局锁和表锁 :给表加个字段怎么有这么多阻碍?
- 全局锁:官方自带的逻辑备份工具是 mysqldump。当 mysqldump 使用参数–single-transaction 的时候,导数据之前就会启动一个事务,来确保拿到一致性视图。innoDB引擎支持,如果是MyISAM就需要用Flush tables with read lock (FTWRL)加全局锁再备份。
- 表级锁:表锁的语法是 lock tables … read/write
- 表级锁:元数据锁 MDL(metadata lock)。MDL 不需要显式使用,在访问一个表的时候会被自动加上。MDL 的作用是,保证读写的正确性
- alert 字段会有写锁,频繁读取的表如果添加字段会造成现成堵塞。
07 | 行锁功过:怎么减少行锁对性能的影响?
- 两阶段锁协议:在 InnoDB 事务中,行锁是在需要的时候才加上的,但并不是不需要了就立刻释放,而是要等到事务结束时才释放。这个就是两阶段锁协议。如果事务要锁多行,建议要把访问最多的那个锁放在最后执行。
- 死锁 死锁检测:
Day6
08 | 事务到底是隔离的还是不隔离的?
- InnoDB 的行数据有多个版本,每个数据版本有自己的 row trx_id,每个事务或者语句有自己的一致性视图。普通查询语句是一致性读,一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。
- InnoDB 利用了“所有数据都有多个版本”的这个特性,实现了“秒级创建快照”的能力。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。