- 博客(14)
- 收藏
- 关注
RSS订阅原创 Redis--Redis集群（学习日记第十三期）
槽位的信息存储于每 个节点中。当客户端向一个错误的节点发出了指令，该节点会发现指令的 key 所在的槽位并不归自己管理，这时它会向客 户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。奇数个master节点可以在满足选举该条件的基础上节省一个节点，比如三个master节点和四个master节点的 集群相比，大家如果都挂了一个master节点都能选举新master节点，如果都挂了两个master节点都没法选举 新master节点了，所以奇数的master节点更多的是。
2025-03-04 17:47:27
853
原创 Redis---主从与哨兵架构详解（学习日记第十二期）
哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过 sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis 主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)：redis自带的事务功能很鸡肋，而redis的lua脚本几乎实现了常规的事务功能， 官方推荐如果要使用redis的事务功能可以用redis lua替代。
2025-03-01 22:53:16
702
原创 Redis--Redis持久化（油炸圣女果的学习日记第十一期）
我们通常使用 AOF 日志重 放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很 长的时间。Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重启效率大幅得到提升。注意，如果执行带过期时间的set命令，aof文件里记录的是并不是执行的原始命令，而是记录key过期的。重写完新的AOF文件才会进行改 名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。
2025-02-28 20:58:54
984
原创 Redis--核心数据结构和高性能原理（油炸圣女果的学习日记第十期）
首先将每个用户关注的人作为一个用户的set缓存如集合A,B,C，那么诸葛老师和杨过老师的共同关注就是A和B集合的交集，那么就可以通过共同关注的人数或占比，系统可以推断出后你类似的人，就可以给你推送他关注的人给你或者判定你们可能共同认识的人（A和B的差集），或者和你喜好类似的人购买了某些商品，是不是可以推测你也感兴趣？，第二个是 key 的正则模式， 第三个是一次遍历的key的数量(参考值，底层遍历的数量不一定)，并不是符合条件的结果数量。这样我在查询的时候，先法消息的排序在后面，便是一种栈的形式。
2025-02-27 21:41:09
943
原创 Mysql---InnoDB底层与日志（油炸圣女果的学习日记第九期）
MIXED：混合模式复制，实际就是前两种模式的结合，在Mixed模式下，MySQL会根据执行的每一条具 体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种，如果sql里有函数或一些 在执行时才知道结果的情况，会选择Row，其它情况选择Statement，推荐使用这一种。开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果没有，就会返回没有权限的错误，如 下所示 (在工程实现上，如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证)。
2025-02-26 21:20:08
798
原创 Mysql调优---Mysql锁机制（油炸圣女果的学习日记第七期）
（简单介绍乐观锁：即在存放的数据最后加一个字段，存放version版本号或者时间戳，每次修改这个表的记录是给版本号+1，那么当我们查询数据时同时查询当前数据的版本号，那么当你在一个事务中查询完数据想要更新数据时，需要将查询到的版本号给更新数据逻辑，即只有当数据库当前数据的版本号是相等的时候，才能成功进行数据更新操作。，主要是为了提高加表锁的效率，是mysql数据库自己 加的。（同样的哈，从加锁的角度看，要给一行数据加行锁，首先我们得去定位这行数据的位置，然后再对其加锁，肯定是比表锁复杂的。
2025-02-24 22:41:13
1142
原创 Mysql调优--事务（油炸圣女果的学习日记第六期）
那么蓝色的已提交的标志就在第二层，这个时候事务A和事务B第一次查询都是500的值，当我们修改值为800并提交，事务A可重复读，查询到的是快转读：依然为500；（这个其实不是什么大问题，但是如果你在同一个事务里执行了三条同样的sql，如果恰好在执行这三个sql的时候，另外有一个事务在修改表的值，那么等于你的同一事务的相同查询sql的结果是不同的，这也意味着这种隔离级别是很低的），比如RR可重复读，当A事务在读，B事务正常执行写，且A在查询的时候走的快照读不会收到执行中的B事务干扰，实现读写并发，不过。
2025-02-23 21:38:49
1098
原创 Mysql调优--索引05（油炸圣女果的学习日记第五期）
join_buffer 一次只能放800行数据，那么执行过程就是先往 join_buffer 里放800行记录，然 后从 t1 表里取数据跟 join_buffer 中数据对比得到部分结果，然后清空 join_buffer ，再放入 t2 表剩余200行记录，再 次从 t1 表里取数据跟 join_buffer 中数据对比。count(*) 是例外，mysql并不会把全部字段取出来，而是专门做了优化，不取值，按行累加，效率很高，所以不需要用 count(列名)或count(常量)来替代 count(*)。
2025-02-22 21:33:07
541
原创 Mysql调优--索引04（油炸圣女果的学习日记第四期）
此时你在where条件里搜索的时候，如果是根据name字段来搜索，那么此时就会先到索引树里根据name 字段的前20个字符去搜索，定位到之后前20个字符的前缀匹配的部分数据之后，再回到聚簇索引提取出来 完整的name字段值进行比对。联合索引建立时是按照name、age、position来建立的，在索引树上，name相等时，age是有序的，但是position是无序的（只有在name、age都相等的叶子结点，position才是有序的）中进行排序，排序完后需要再次取回其它需要的字段；
2025-02-21 20:45:57
645
原创 Mysql调优--索引03（油炸圣女果的学习日记第三期）
因为联合索引第一个字段就用范围查找，mysql内部（mysql底层有自己的判断逻辑）可能觉得第一个字段就用范围，结果集应该很大，回表效率不高（如果结果集大，意味着在存放索引文件中查找出的结果统统需要走一遍回表查找数据的操作），还不 如就全表扫描。估计应该是Mysql认为范围查找过滤的结果集过大，like KK% 在绝大多数情况来看，过滤后的结果集比较小，所以这里Mysql选择给 like KK% 用了索引下推优化，当然这也不是绝对的，有时like KK% 也不一定就会走索引下推。
2025-02-20 22:05:02
683
原创 Mysql调优--索引02（油炸圣女果的学习日记第二期）
扫描全索引就能拿到结果，一般是扫描某个二级索引，这种扫描不会从索引树根节点开始快速查找，而是直接对二级索引的叶子节点遍历和扫描，速度还是比较慢的，这种查询一般为使用覆盖索引，二级索引一般比较小，所以这种通常比ALL快一些。2.关联表查询，idx_film_actor_id是film_id和actor_id的联合索引，这里使用到了film_actor的左边前缀film_id部分。显示了在key列记录的索引中，表查找值所用到的列或常量，常见的有：const（常量），字段名（例：film.id）
2025-02-20 19:52:13
1003
转载 MySQL数据库学习笔记（二）----MySQL数据类型
【正文】上一章节中，我们学习了MySQL软件的安装，既然软件都装好了，现在就正式开始MySQL的基础知识的学习吧，即使是零基础，也要一步一个脚印。恩，首先要学习的就是MySQL的数据类型。一、数据类型：1、整型（xxxint） 2、浮点型(float和double) 3、定点数(decimal) 4、字符串(char,varchar,xxxtext) 5、二进制数据(xxxBlob) 6、日期时间类型二、数据类型介绍：1、整型：注：M表示最大的显示宽度。其中，int用
2021-10-17 14:47:42
61
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人