@@ -449,7 +449,7 @@ mysqlshow -uroot -p1234 test book --count
449449 CREATE DATABASE db1; -- 创建db1数据库
450450 ` ` `
451451
452- * 创建数据库( 判断，如果不存在则创建)
452+ * 创建数据库（ 判断，如果不存在则创建）
453453
454454 ` ` ` mysql
455455 CREATE DATABASE IF NOT EXISTS 数据库名称;
@@ -1633,7 +1633,7 @@ INSERT INTO stu_course VALUES (NULL,1,1),(NULL,1,2),(NULL,2,1),(NULL,2,2);
16331633* 子查询
16341634* 自关联查询
16351635
1636- 多表查询格式：
1636+ 多表查询格式：（笛卡儿积）
16371637
16381638` ` ` mysql
16391639SELECT
@@ -1650,7 +1650,7 @@ WHERE
16501650
16511651
16521652
1653- # ### 内连接查询
1653+ # ### 内连接
16541654
16551655查询原理：内连接查询的是两张表有交集的部分数据
16561656
@@ -1673,7 +1673,7 @@ WHERE
16731673
16741674
16751675
1676- # ### 外连接查询
1676+ # ### 外连接
16771677
16781678* 左外连接：查询左表的全部数据，和左右两张表有交集部分的数据
16791679
@@ -1732,7 +1732,7 @@ WHERE
17321732
17331733
17341734
1735- # ### 自关联查询
1735+ # ### 自关联
17361736
17371737自关联查询：同一张表中有数据关联。可以多次查询这同一个表！
17381738
@@ -5493,11 +5493,11 @@ MySQL 的主从复制原理图：
54935493
54945494* 从库的查询压力大
54955495* 大事务的执行，主库必须要等到事务完成之后才会写入 binlog，导致从节点出现应用 binlog 延迟
5496- * 主库的DDL ，从库与主库的 DDL 同步是串行进行，DDL 在主库执行时间很长，那么从库也会消耗同样的时间
5496+ * 主库的 DDL ，从库与主库的 DDL 同步是串行进行，DDL 在主库执行时间很长，那么从库也会消耗同样的时间
54975497* 锁冲突问题也可能导致从节点的 SQL 线程执行慢
54985498* 从库的机器性能比主库的差，导致从库的复制能力弱
54995499
5500- 主从同步问题永远都是一致性和性能的权衡 ，需要根据实际的应用场景，可以采取下面的办法：
5500+ 主从同步问题永远都是 ** 一致性和性能的权衡 ** ，需要根据实际的应用场景，可以采取下面的办法：
55015501
55025502* 二次查询，如果从库查不到数据，则再去主库查一遍，由 API 封装，比较简单，但导致主库压力大
55035503* 降低多线程大事务并发的概率，优化业务逻辑
@@ -5875,7 +5875,7 @@ InnoDB 实现了以下两种类型的行锁：
58755875- 排他锁和排他锁 冲突
58765876- 排他锁和共享锁 冲突
58775877
5878- 可以通过以下语句显示给数据集加共享锁或排他锁 ：
5878+ 可以通过以下语句显式给数据集加共享锁或排他锁 ：
58795879
58805880` ` ` mysql
58815881SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE -- 共享锁
@@ -5983,7 +5983,7 @@ SELECT * FROM table_name WHERE ... FOR UPDATE -- 排他锁
59835983
59845984# ### 锁升级
59855985
5986- 无索引行锁升级为表锁：不通过索引检索数据，那么 InnoDB 将对表中的所有记录加锁，实际效果和加表锁一样
5986+ 无索引行锁升级为表锁：不通过索引检索数据，InnoDB 会将对表中的所有记录加锁，实际效果和 ** 表锁 ** 一样
59875987
59885988索引失效会造成锁升级，实际开发过程应避免出现索引失效的状况
59895989
@@ -10399,7 +10399,7 @@ slave 与 master 连接断开
1039910399
1040010400
1040110401
10402- # ### 缓存不一致
10402+ # ### 一致性
1040310403
1040410404网络信息不同步，数据发送有延迟，导致多个 slave 获取相同数据不同步
1040510405
@@ -10842,19 +10842,6 @@ Cache Aside Pattern 中服务端需要同时维系 DB 和 cache，并且是以 D
1084210842* 写操作比较频繁的话导致 cache 中的数据会被频繁被删除，影响缓存命中率
1084310843
1084410844
10845- 缓存不一致的方法：
10846-
10847- * 数据库和缓存数据** 强一致** 场景 ：
10848- * 更新 DB 时同样更新 cache，加一个锁来保证更新 cache 时不存在线程安全问题，这样可以增加命中率
10849- * 延迟双删：先淘汰缓存再写数据库，休眠1秒再次淘汰缓存，可以将1秒内造成的缓存脏数据再次删除
10850- * CDC 同步：通过 canal 订阅 MySQL binlog 的变更上报给 Kafka，系统监听 Kafka 消息触发缓存失效
10851- * 可以短暂地允许数据库和缓存数据** 不一致** 场景：更新 DB 的时候同样更新 cache，但是给缓存加一个比较短的过期时间，这样就可以保证即使数据不一致影响也比较小
10852-
10853-
10854-
10855- 参考文章：http://cccboke.com/archives/2020-09-30-21-29-56
10856-
10857-
1085810845
1085910846****
1086010847
@@ -10900,6 +10887,28 @@ Read-Through Pattern 也存在首次不命中的问题，采用缓存预热解
1090010887
1090110888
1090210889
10890+ # ## 缓存一致
10891+
10892+ 使用缓存代表不需要强一致性，只需要最终一致性
10893+
10894+ 缓存不一致的方法：
10895+
10896+ * 数据库和缓存数据** 强一致** 场景 ：
10897+ * 更新 DB 时同样更新 cache，加一个锁来保证更新 cache 时不存在线程安全问题，这样可以增加命中率
10898+ * 延迟双删：先淘汰缓存再写数据库，休眠1秒再次淘汰缓存，可以将1秒内造成的缓存脏数据再次删除
10899+ * CDC 同步：通过 canal 订阅 MySQL binlog 的变更上报给 Kafka，系统监听 Kafka 消息触发缓存失效
10900+ * 可以短暂地允许数据库和缓存数据** 不一致** 场景：更新 DB 的时候同样更新 cache，但是给缓存加一个比较短的过期时间，这样就可以保证即使数据不一致影响也比较小
10901+
10902+
10903+
10904+ 参考文章：http://cccboke.com/archives/2020-09-30-21-29-56
10905+
10906+
10907+
10908+ ***
10909+
10910+
10911+
1090310912# ## 企业方案
1090410913
1090510914# ### 缓存预热
0 commit comments