@@ -385,7 +385,7 @@ mysqlshow -uroot -p1234 test book --count
385385
386386SHOW PROCESSLIST:查看当前 MySQL 在进行的线程,可以实时地查看 SQL 的执行情况,其中的 Command 列显示为 Sleep 的这一行,就表示现在系统里面有一个空闲连接
387387
388- 
388+ 
389389
390390| 参数 | 含义 |
391391| -- ----- | ------------------------------------------------------------ |
@@ -4139,12 +4139,12 @@ MySQL 官方对索引的定义为:索引(index)是帮助 MySQL 高效获
41394139 - R- tree 索引(空间索引):空间索引是 MyISAM 引擎的一个特殊索引类型,主要用于地理空间数据类型
41404140 - Full- text 索引(全文索引):快速匹配全部文档的方式。MyISAM 支持, InnoDB 不支持 FULLTEXT 类型的索引,但是 InnoDB 可以使用 sphinx 插件支持全文索引,MEMORY 引擎不支持
41414141
4142- | 索引 | InnoDB引擎 | MyISAM引擎 | Memory引擎 |
4143- | -- ------- | --------------- | ---------- | ---- ------ |
4144- | BTREE | 支持 | 支持 | 支持 |
4145- | HASH | 不支持 | 不支持 | 支持 |
4146- | R- tree | 不支持 | 支持 | 不支持 |
4147- | Full- text | 5 .6 版本之后支持 | 支持 | 不支持 |
4142+ | 索引 | InnoDB | MyISAM | Memory |
4143+ | -- ------- | ---------------- | ------ | ------ |
4144+ | BTREE | 支持 | 支持 | 支持 |
4145+ | HASH | 不支持 | 不支持 | 支持 |
4146+ | R- tree | 不支持 | 支持 | 不支持 |
4147+ | Full- text | 5 .6 版本之后支持 | 支持 | 不支持 |
41484148
41494149联合索引图示:根据身高年龄建立的组合索引(height,age)
41504150
@@ -5894,21 +5894,21 @@ MySQL 的主从之间维持了一个长连接。主库内部有一个线程,
58945894
58955895coordinator 就是原来的 sql_thread,并行复制中它不再直接更新数据,只** 负责读取中转日志和分发事务** :
58965896
5897- * 线程分配完成并不是立即执行,为了防止造成更新覆盖,更新同一行的两个事务必须被分发到同一个工作线程
5897+ * 线程分配完成并不是立即执行,为了防止造成更新覆盖,更新同一 DB 的两个事务必须被分发到同一个工作线程
58985898* 同一个事务不能被拆开,必须放到同一个工作线程
58995899
59005900MySQL 5 .6 版本的策略:每个线程对应一个 hash 表,用于保存当前这个线程的执行队列里的事务所涉及的表,hash 表的 key 是数据库 名,value 是一个数字,表示队列中有多少个事务修改这个库,适用于主库上有多个 DB 的情况
59015901
59025902每个事务在分发的时候,跟线程的冲突(事务操作的是同一个 DB)关系包括以下三种情况:
59035903
59045904* 如果跟所有线程都不冲突,coordinator 线程就会把这个事务分配给最空闲的线程
5905- * 如果跟多于一个线程冲突,coordinator 线程就进入等待状态,直到和这个事务存在冲突关系的线程只剩下 1 个
59065905* 如果只跟一个线程冲突,coordinator 线程就会把这个事务分配给这个存在冲突关系的线程
5906+ * 如果跟多于一个线程冲突,coordinator 线程就进入等待状态,直到和这个事务存在冲突关系的线程只剩下 1 个
59075907
59085908优缺点:
59095909
59105910* 构造 hash 值的时候很快,只需要库名,而且一个实例上 DB 数也不会很多,不会出现需要构造很多个项的情况
5911- * 不要求 binlog 的格式,statement 格式的 binlog 也可以很容易拿到库名
5911+ * 不要求 binlog 的格式,statement 格式的 binlog 也可以很容易拿到库名(日志章节详解了 binlog)
59125912* 主库上的表都放在同一个 DB 里面,这个策略就没有效果了;或者不同 DB 的热点不同,比如一个是业务逻辑库,一个是系统配置库,那也起不到并行的效果,需要** 把相同热度的表均匀分到这些不同的 DB 中** ,才可以使用这个策略
59135913
59145914
@@ -5965,7 +5965,7 @@ MySQL 5.7.22 的并行复制策略在通用性上是有保证的,但是对于
59655965* 主库不建查询的索引,从库建查询的索引。因为索引需要维护的,比如插入一条数据,不仅要在聚簇索引上面插入,对应的二级索引也得插入
59665966* 将读操作分到从库了之后,可以在主库把查询要用的索引删了,减少写操作对主库的影响
59675967
5968- 读写分离产生了读写延迟,造成数据的不一致性。假如客户端执行完一个更新事务后马上发起查询,如果查询选择的是从库的话,可能读到的还是以前的数据,叫过期读,
5968+ 读写分离产生了读写延迟,造成数据的不一致性。假如客户端执行完一个更新事务后马上发起查询,如果查询选择的是从库的话,可能读到的还是以前的数据,叫过期读
59695969
59705970解决方案:
59715971
@@ -6221,7 +6221,7 @@ FLUSH TABLES WITH READ LOCK 简称(FTWRL),全局读锁,让整个库处
62216221
62226222MySQL 里面表级别的锁有两种:一种是表锁,一种是元数据锁(meta data lock,MDL)
62236223
6224- MDL 叫元数据锁,主要用来保护 MySQL内部对象的元数据,保证数据读写的正确性,通过 MDL 机制保证 DDL、DML、SELECT 操作的并发,** 当对一个表做增删改查操作的时候,加 MDL 读锁;当要对表做结构变更操作的时候,加 MDL 写锁**
6224+ MDL 叫元数据锁,主要用来保护 MySQL内部对象的元数据,保证数据读写的正确性,通过 MDL 机制保证 DDL、DML、DQL 操作的并发,** 当对一个表做增删改查操作的时候,加 MDL 读锁;当要对表做结构变更操作的时候,加 MDL 写锁**
62256225
62266226* MDL 锁不需要显式使用,在访问一个表的时候会被自动加上,事务中的 MDL 锁,在语句执行开始时申请,在整个事务提交后释放
62276227
@@ -6852,7 +6852,7 @@ binlog_format=STATEMENT
68526852
68536853 缺点:记录的数据比较多,占用很多的存储空间
68546854
6855- * MIXED:这是 MySQL 默认的日志格式,混合了STATEMENT 和 ROW两种格式 。MIXED 格式能尽量利用两种模式的优点,而避开它们的缺点
6855+ * MIXED:这是 MySQL 默认的日志格式,混合了STATEMENT 和 ROW 两种格式 。MIXED 格式能尽量利用两种模式的优点,而避开它们的缺点
68566856
68576857
68586858
@@ -7035,10 +7035,10 @@ long_query_time=10
70357035
70367036# # 范式
70377037
7038- 建立科学的,规范的数据库就需要满足一些规则来优化数据的设计和存储,这些规则就称为范式。
7039-
70407038# ## 第一范式
70417039
7040+ 建立科学的,** 规范的数据表** 就需要满足一些规则来优化数据的设计和存储,这些规则就称为范式
7041+
70427042** 1NF:** 数据库表的每一列都是不可分割的原子数据项,不能是集合、数组等非原子数据项。即表中的某个列有多个值时,必须拆分为不同的列。简而言之,** 第一范式每一列不可再拆分,称为原子性**
70437043
70447044基本表:
@@ -8513,7 +8513,7 @@ Redis 基于 Reactor 模式开发了网络事件处理器,这个处理器被
85138513
85148514* 文件事件处理器使用 I/O 多路复用(multiplexing)程序来同时监听多个套接字,并根据套接字目前执行的任务来为套接字关联不同的事件处理器
85158515
8516- * 当被监听的套接字准备好执行连接应答 (accept)、读取 (read)、写入 (write)、关闭 (close) 等操作时,与操作相对应的文件事件就会产生,这时文件事件处理器会调用套接字之前关联好的事件处理器来处理事件
8516+ * 当被监听的套接字准备好执行连接应答 (accept)、读取 (read)、写入 (write)、关闭 (close) 等操作时,与操作相对应的文件事件就会产生,这时文件事件处理器会将处理请求放入 ** 单线程的执行队列 ** 中,等待调用套接字关联好的事件处理器来处理事件
85178517
85188518** Redis 单线程也能高效的原因** :
85198519
@@ -11524,7 +11524,7 @@ Read-Through Pattern 也存在首次不命中的问题,采用缓存预热解
1152411524
1152511525缓存不一致的方法:
1152611526
11527- * 数据库和缓存数据强一致场景 :
11527+ * 数据库和缓存数据强一致场景:
1152811528 * 更新 DB 时同样更新 cache,加一个锁来保证更新 cache 时不存在线程安全问题,这样可以增加命中率
1152911529 * 延迟双删:先淘汰缓存再写数据库,休眠 1 秒再次淘汰缓存,可以将 1 秒内造成的缓存脏数据再次删除
1153011530 * CDC 同步:通过 canal 订阅 MySQL binlog 的变更上报给 Kafka,系统监听 Kafka 消息触发缓存失效
0 commit comments