又菜又爱玩oh
获得徽章 1
#青训营笔记创作活动#
1月20日 Day10
今日学习：UDP比TCP快，但也有例外
用UDP比TCp快的地方
使用socket进行数据传输
重传机制
流量控制机制
滑动窗口机制
拥塞控制机制
分段机制
乱序重排机制
连接机制
用UDP就一定比用TCP快吗？
在TCP里，它内部会根据MSS的大小分段，这时候进入到IP层之后，每个包大小都不会超过MTU，因此IP层一般不会再进行分片。这时候发生丢包了，只需要重传每个MSS分段就够了。
但对于UDP，其本身并不会分段，如果数据过大，到了IP层，就会进行分片。此时发生丢包的话，再次重传，就会重传整个大数据包。
使用UDP就比TCP要慢
使用UDP的应用层如果也实现了分段机制的话，那就不会出现上述的问题了。
TCP为了实现可靠性，引入了重传机制、流量控制、滑动窗口、拥塞控制、分段以及乱序重排机制。而UDP则没有实现，因此一般来说TCP比UDP快。
TCP是面向连接的协议，而UDP是无连接的协议。这里的"连接"其实是，操作系统内核在两端代码里维护的一套复杂状态机。
大部分项目，会在基于UDP的基础上，模仿TCP，实现不同程度的可靠性机制。比如王者农药用的KCP其实就在基于UDP在应用层里实现了一套重传机制。
对于UDP+重传的场景，如果要传超大数据包，并且没有实现分段机制的话，那数据就会在IP层分片，一旦丢包，那就需要重传整个超大数据包。而TCP则不需要考虑这个，内部会自动分段，丢包重传分段就行了。这种场景下，其实TCP更快。
1月20日 Day10
今日学习：UDP比TCP快，但也有例外
用UDP比TCp快的地方
使用socket进行数据传输
重传机制
流量控制机制
滑动窗口机制
拥塞控制机制
分段机制
乱序重排机制
连接机制
用UDP就一定比用TCP快吗？
在TCP里，它内部会根据MSS的大小分段，这时候进入到IP层之后，每个包大小都不会超过MTU，因此IP层一般不会再进行分片。这时候发生丢包了，只需要重传每个MSS分段就够了。
但对于UDP，其本身并不会分段，如果数据过大，到了IP层，就会进行分片。此时发生丢包的话，再次重传，就会重传整个大数据包。
使用UDP就比TCP要慢
使用UDP的应用层如果也实现了分段机制的话，那就不会出现上述的问题了。
TCP为了实现可靠性，引入了重传机制、流量控制、滑动窗口、拥塞控制、分段以及乱序重排机制。而UDP则没有实现，因此一般来说TCP比UDP快。
TCP是面向连接的协议，而UDP是无连接的协议。这里的"连接"其实是，操作系统内核在两端代码里维护的一套复杂状态机。
大部分项目，会在基于UDP的基础上，模仿TCP，实现不同程度的可靠性机制。比如王者农药用的KCP其实就在基于UDP在应用层里实现了一套重传机制。
对于UDP+重传的场景，如果要传超大数据包，并且没有实现分段机制的话，那数据就会在IP层分片，一旦丢包，那就需要重传整个超大数据包。而TCP则不需要考虑这个，内部会自动分段，丢包重传分段就行了。这种场景下，其实TCP更快。
展开
评论
点赞
#青训营笔记创作活动#
1月19日 Day9
今日学习：英文文档和资料看不懂的方法
平常我们会遇见很多不懂的英文文档或者英文文件，以下文章内容就是帮助我们选择对的方法解决问题
如果在出差的路上，或者咖啡馆，或者自习室，可以拿出英文资料，或者是需要查看的技术文档，或者需要学习的产品手册。将不能够准确理解的段落、句子、单词摘抄到随身携带的抄写本上，这样便于针对细节深入处理。
如果在家的情况下，有时候会觉得使用电脑打字的速度要比用手抄本写笔记的速度要快，你就可以像下图这样，在电脑主屏幕上用文本编辑器来记下笔记，用扩展显示器显示 pdf，这样不用切来切去，影响阅读速度。
查找、分解的方法。总的来说大概几个方面，包括了:
搜索
翻译
找文献
分解复杂句子
查找语法知识
1月19日 Day9
今日学习：英文文档和资料看不懂的方法
平常我们会遇见很多不懂的英文文档或者英文文件，以下文章内容就是帮助我们选择对的方法解决问题
如果在出差的路上，或者咖啡馆，或者自习室，可以拿出英文资料，或者是需要查看的技术文档，或者需要学习的产品手册。将不能够准确理解的段落、句子、单词摘抄到随身携带的抄写本上，这样便于针对细节深入处理。
如果在家的情况下，有时候会觉得使用电脑打字的速度要比用手抄本写笔记的速度要快，你就可以像下图这样，在电脑主屏幕上用文本编辑器来记下笔记，用扩展显示器显示 pdf，这样不用切来切去，影响阅读速度。
查找、分解的方法。总的来说大概几个方面，包括了:
搜索
翻译
找文献
分解复杂句子
查找语法知识
展开
评论
点赞
#青训营笔记创作活动#
1月18日 Day8
今日学习:kafka
一个典型的 Kafka 体系架构包括若干 Producer、若干 Broker、若干 Consumer，以及一个 ZooKeeper 集群，如图所示。其中 ZooKeeper 是 Kafka 用来负责集群元数据的管理、控制器 的选举等操作的。Producer 将消息发送到 Broker，Broker 负责将收到的消息存储到磁盘中，而 Consumer 负责从 Broker 订阅并消费消息。
消息系统
Kafka 和传统的消息系统(也称作消息中间件)都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。
存储系统
Kafka 把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效地降低了数据丢失的风险。也正是得益于 Kafka 的消息持久化功能和多副本机制，我们可以把 Kafka 作为长期的数据存储系统来使用，只需要把对应的数据保留策略设置 为“永久”或启用主题的日志压缩功能
流式处理平台
Kafka 不仅为每个流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理类库，比如窗口、连接、变换和聚合等各类操作。
在 Kafka 中还有两个特别重要的概念——主题（Topic）与分区（Partition）。
主题是一个逻辑上的概念，它还可以细分为多个分区，一个分区只属于单个主题，很多时候也会把分区称为主题分区（Topic-Partition）
同一主题下的不同分区包含的消息是不同的，分区在存储层面可以看作一个可追加的日志（Log）文件，消息在被追加到分区日志文件的时候都会分配一个特定的偏移量（offset）
offset 是消息在分区中的唯一标识，Kafka 通过它来保证消息在分区内的顺序性，不过 offset 并不跨越分区，也就是说，Kafka 保证的是分区有序而不是主题有序。
在 Kafka 的消费理念中还有一层消费组（Consumer Group)）的概念，每个消费者都有一个对应的消费组。当消息发布到主题后，只会被投递给订阅它的每个消费组中的一个消费者。
更多详细请看下方链接，讲解非常细腻，建议收藏反复阅读，学习后将有更深刻的理解。
1月18日 Day8
今日学习:kafka
一个典型的 Kafka 体系架构包括若干 Producer、若干 Broker、若干 Consumer，以及一个 ZooKeeper 集群，如图所示。其中 ZooKeeper 是 Kafka 用来负责集群元数据的管理、控制器 的选举等操作的。Producer 将消息发送到 Broker，Broker 负责将收到的消息存储到磁盘中，而 Consumer 负责从 Broker 订阅并消费消息。
消息系统
Kafka 和传统的消息系统(也称作消息中间件)都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。
存储系统
Kafka 把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效地降低了数据丢失的风险。也正是得益于 Kafka 的消息持久化功能和多副本机制，我们可以把 Kafka 作为长期的数据存储系统来使用，只需要把对应的数据保留策略设置 为“永久”或启用主题的日志压缩功能
流式处理平台
Kafka 不仅为每个流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理类库，比如窗口、连接、变换和聚合等各类操作。
在 Kafka 中还有两个特别重要的概念——主题（Topic）与分区（Partition）。
主题是一个逻辑上的概念，它还可以细分为多个分区，一个分区只属于单个主题，很多时候也会把分区称为主题分区（Topic-Partition）
同一主题下的不同分区包含的消息是不同的，分区在存储层面可以看作一个可追加的日志（Log）文件，消息在被追加到分区日志文件的时候都会分配一个特定的偏移量（offset）
offset 是消息在分区中的唯一标识，Kafka 通过它来保证消息在分区内的顺序性，不过 offset 并不跨越分区，也就是说，Kafka 保证的是分区有序而不是主题有序。
在 Kafka 的消费理念中还有一层消费组（Consumer Group)）的概念，每个消费者都有一个对应的消费组。当消息发布到主题后，只会被投递给订阅它的每个消费组中的一个消费者。
更多详细请看下方链接，讲解非常细腻，建议收藏反复阅读，学习后将有更深刻的理解。
展开
评论
点赞
#青训营笔记创作活动#
1月17日 Day7
今日学习：Http and websocket
使用HTTP不断轮询
但这样，会有两个比较明显的问题
当你打开F12页面时，你会发现满屏的HTTP请求。虽然很小，但这其实也消耗带宽，同时也会增加下游服务器的负担。
最坏情况下，用户在扫码后，需要等个1~2s，正好才触发下一次http请求，然后才跳转页面，用户会感到明显的卡顿。
使用起来的体验就是，二维码出现后，手机扫一扫，然后在手机上点个确认，这时候卡顿等个1~2s，页面才跳转。
不断轮询查看是否有扫码
长轮询
我们知道，HTTP请求发出后，一般会给服务器留一定的时间做响应，比如3s，规定时间内没返回，就认为是超时。
如果我们的HTTP请求将超时设置的很大，比如30s，在这30s内只要服务器收到了扫码请求，就立马返回给客户端网页。如果超时，那就立马发起下一次请求。
这样就减少了HTTP请求的个数，并且由于大部分情况下，用户都会在某个30s的区间内做扫码操作，所以响应也是及时的。
上面提到的两种解决方案，本质上，其实还是客户端主动去取数据
websocket是什么
我们知道TCP连接的两端，同一时间里，双方都可以主动向对方发送数据。这就是所谓的全双工。
而现在使用最广泛的HTTP1.1，也是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，这就是所谓的半双工。
总结
TCP协议本身是全双工的，但我们最常用的HTTP1.1，虽然是基于TCP的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的websocket协议。
在HTTP1.1里。只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。
对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用websocket协议。
websocket和socket几乎没有任何关系，只是叫法相似。
正因为各个浏览器都支持HTTP协议，所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作，升级成功后就跟HTTP没有任何关系了，之后就用websocket的数据格式进行收发数据。
1月17日 Day7
今日学习：Http and websocket
使用HTTP不断轮询
但这样，会有两个比较明显的问题
当你打开F12页面时，你会发现满屏的HTTP请求。虽然很小，但这其实也消耗带宽，同时也会增加下游服务器的负担。
最坏情况下，用户在扫码后，需要等个1~2s，正好才触发下一次http请求，然后才跳转页面，用户会感到明显的卡顿。
使用起来的体验就是，二维码出现后，手机扫一扫，然后在手机上点个确认，这时候卡顿等个1~2s，页面才跳转。
不断轮询查看是否有扫码
长轮询
我们知道，HTTP请求发出后，一般会给服务器留一定的时间做响应，比如3s，规定时间内没返回，就认为是超时。
如果我们的HTTP请求将超时设置的很大，比如30s，在这30s内只要服务器收到了扫码请求，就立马返回给客户端网页。如果超时，那就立马发起下一次请求。
这样就减少了HTTP请求的个数，并且由于大部分情况下，用户都会在某个30s的区间内做扫码操作，所以响应也是及时的。
上面提到的两种解决方案，本质上，其实还是客户端主动去取数据
websocket是什么
我们知道TCP连接的两端，同一时间里，双方都可以主动向对方发送数据。这就是所谓的全双工。
而现在使用最广泛的HTTP1.1，也是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，这就是所谓的半双工。
总结
TCP协议本身是全双工的，但我们最常用的HTTP1.1，虽然是基于TCP的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的websocket协议。
在HTTP1.1里。只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。
对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用websocket协议。
websocket和socket几乎没有任何关系，只是叫法相似。
正因为各个浏览器都支持HTTP协议，所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作，升级成功后就跟HTTP没有任何关系了，之后就用websocket的数据格式进行收发数据。
展开
评论
点赞
赞了这篇文章
#青训营笔记创作活动#
1月16日 Day6
今日学习：电脑如何通过DHCP自己获得ip地址的
插上网线之后，获得IP的方式主要有两种。
第一种是，自己手动在电脑里配，在选择手动配置之后，除了IP地址还需要配上子网掩码和路由器的地址。
第二种获取IP的方式，DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）电脑插上网线，联网后会通过DHCP协议动态申请一个IP，同时获得子网掩码，路由器地址等信息。通过DHCP，在联网之后可以自动获取到本机需要的IP地址，子网掩码还有路由器地址。
DHCP的工作原理
说白了，就是向某个管IP分配的服务器，也就是DHCP服务器，申请IP地址。其实一般家里用的路由器就自带这个功能。
DHCP Discover：在联网时，本机由于没有IP，也不知道DHCP服务器的IP地址是多少，所以根本不知道该向谁发起请求，于是索性选择广播，向本地网段内所有人发出消息，询问"谁能给个IP用用"。
DHCP Offer：不是DHCP服务器的机子会忽略你的广播消息，而DHCP服务器收到消息后，会在自己维护的一个IP池里拿出一个空闲IP，通过广播的形式给回你的电脑。
DHCP Request：你的电脑在拿到IP后，再次发起广播，就说"这个IP我要了"。
DHCP ACK：DHCP服务器此时再回复你一个ACK，意思是"ok的"。你就正式获得这个IP在一段时间（比如24小时）里的使用权了。后续只要IP租约不过期，就可以一直用这个IP进行通信了。
那手机是如何获得的呢？
DHCP分为四个阶段，分别是 Discover，Offer， Request和ACK。如果曾经连过这个网，机器会记录你上次使用的IP，再次连接时优先使用原来的那个IP，因此只需要经历第三第四阶段。
DHCP是应用层协议，考虑到需要支持广播功能，底层使用的是UDP协议，而不是TCP协议。
DHCP分配下来的IP是有可能跟某台手动配置的IP地址重复的。
DHCP得到IP之后还会发3次无偿ARP通告，在确认没有冲突后开始使用这个IP。
1月16日 Day6
今日学习：电脑如何通过DHCP自己获得ip地址的
插上网线之后，获得IP的方式主要有两种。
第一种是，自己手动在电脑里配，在选择手动配置之后，除了IP地址还需要配上子网掩码和路由器的地址。
第二种获取IP的方式，DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）电脑插上网线，联网后会通过DHCP协议动态申请一个IP，同时获得子网掩码，路由器地址等信息。通过DHCP，在联网之后可以自动获取到本机需要的IP地址，子网掩码还有路由器地址。
DHCP的工作原理
说白了，就是向某个管IP分配的服务器，也就是DHCP服务器，申请IP地址。其实一般家里用的路由器就自带这个功能。
DHCP Discover：在联网时，本机由于没有IP，也不知道DHCP服务器的IP地址是多少，所以根本不知道该向谁发起请求，于是索性选择广播，向本地网段内所有人发出消息，询问"谁能给个IP用用"。
DHCP Offer：不是DHCP服务器的机子会忽略你的广播消息，而DHCP服务器收到消息后，会在自己维护的一个IP池里拿出一个空闲IP，通过广播的形式给回你的电脑。
DHCP Request：你的电脑在拿到IP后，再次发起广播，就说"这个IP我要了"。
DHCP ACK：DHCP服务器此时再回复你一个ACK，意思是"ok的"。你就正式获得这个IP在一段时间（比如24小时）里的使用权了。后续只要IP租约不过期，就可以一直用这个IP进行通信了。
那手机是如何获得的呢？
DHCP分为四个阶段，分别是 Discover，Offer， Request和ACK。如果曾经连过这个网，机器会记录你上次使用的IP，再次连接时优先使用原来的那个IP，因此只需要经历第三第四阶段。
DHCP是应用层协议，考虑到需要支持广播功能，底层使用的是UDP协议，而不是TCP协议。
DHCP分配下来的IP是有可能跟某台手动配置的IP地址重复的。
DHCP得到IP之后还会发3次无偿ARP通告，在确认没有冲突后开始使用这个IP。
展开
评论
点赞
#青训营笔记创作活动#
1月15日 Day5
今日学习: SQL索引
这一篇说实话我要理解难度很大，我觉得我的学习还不够，对于SQL的理解太浅
MySQL联合索引有时候遵循最左前缀匹配原则，有时候不遵循。
前提 如果创建 b,c,d 联合索引面
如果 我where 后面的条件是c = 1 and d = 1为什么不能走索引呢 如果没有b的话 你查询的值相当于 *11 我们都知道*是所有的意思也就是我能匹配到所有的数据
如果 我 where 后面是 b = 1 and d =1 为什么会走索引呢？ 你等于查询的数据是 1*1 我可以通过前面 1 进行索引匹配 所以就可以走索引
最左缀匹配原则的最重要的就是 第一个字段
select * 会走索引
范围查找有概率索引失效但是在特定的情况下会生效 范围小就会使用 也可以理解为 返回结果集小就会使用索引
mysql中连接查询的原理是先对驱动表进行查询操作，然后再用从驱动表得到的数据作为条件，逐条的到被驱动表进行查询。
每次驱动表加载一条数据到内存中，然后被驱动表所有的数据都需要往内存中加载一遍进行比较。效率很低，所以mysql中可以指定一个缓冲池的大小，缓冲池大的话可以同时加载多条驱动表的数据进行比较，放的数据条数越多性能io操作就越少，性能也就越好。所以，如果此时使用select * 放一些无用的列，只会白白的占用缓冲空间。浪费本可以提高性能的机会。
按照评论区老哥的说法 select * 不是造成索引失效的直接原因 大部分原因是 where 后边条件的问题 但是还是尽量少去使用select * 多少还是会有影响的
1月15日 Day5
今日学习: SQL索引
这一篇说实话我要理解难度很大，我觉得我的学习还不够，对于SQL的理解太浅
MySQL联合索引有时候遵循最左前缀匹配原则，有时候不遵循。
前提 如果创建 b,c,d 联合索引面
如果 我where 后面的条件是c = 1 and d = 1为什么不能走索引呢 如果没有b的话 你查询的值相当于 *11 我们都知道*是所有的意思也就是我能匹配到所有的数据
如果 我 where 后面是 b = 1 and d =1 为什么会走索引呢？ 你等于查询的数据是 1*1 我可以通过前面 1 进行索引匹配 所以就可以走索引
最左缀匹配原则的最重要的就是 第一个字段
select * 会走索引
范围查找有概率索引失效但是在特定的情况下会生效 范围小就会使用 也可以理解为 返回结果集小就会使用索引
mysql中连接查询的原理是先对驱动表进行查询操作，然后再用从驱动表得到的数据作为条件，逐条的到被驱动表进行查询。
每次驱动表加载一条数据到内存中，然后被驱动表所有的数据都需要往内存中加载一遍进行比较。效率很低，所以mysql中可以指定一个缓冲池的大小，缓冲池大的话可以同时加载多条驱动表的数据进行比较，放的数据条数越多性能io操作就越少，性能也就越好。所以，如果此时使用select * 放一些无用的列，只会白白的占用缓冲空间。浪费本可以提高性能的机会。
按照评论区老哥的说法 select * 不是造成索引失效的直接原因 大部分原因是 where 后边条件的问题 但是还是尽量少去使用select * 多少还是会有影响的
展开
评论
点赞
1月14日 Day4
今日学习：Go语言学习与进阶
客户端转服务端，最大的挑战不是学一门新语言，而是编程思维的改变；
“三刷”官方文档是我高效学习一门新的编程语言的制胜法宝：
1刷从头看到尾，扫清知识盲点，搞清楚概念；
2刷必须手敲，而且要写注释和总结；
3刷先只写注释，不看文档实现功能，遇到问题再和文档比较，加深理解。如果还有余力，就和我一样整理成文章，分享出来帮助大家学习，回馈社区。
在掌握Go基础之后，也可以通过“三刷”的方式掌握SQL,Redis,Linux，Nginx的基础知识点，这样就有能力开发Web项目了。
要进阶就要学“微服务”和“DDD”！下文也会重点讲讲微服务和DDD的概念，让大家先有个目标，这样才能心中有火，眼里有光。
通读一遍需求文档和原型图
梳理业务逻辑，进行抽象，明确有多少个功能需求要开发
根据功能需求创建数据库，创建表，添加字段，设置合适的字段类型，长度，主外键等
考虑业务场景，创建索引...
开始疯狂的CRUD...
开始疯狂的加Cache...
开发疯狂的给客户端提供数据接口...
持续迭代：根据业务增长做负载均衡、分库分表、读写分离....
今日学习：Go语言学习与进阶
客户端转服务端，最大的挑战不是学一门新语言，而是编程思维的改变；
“三刷”官方文档是我高效学习一门新的编程语言的制胜法宝：
1刷从头看到尾，扫清知识盲点，搞清楚概念；
2刷必须手敲，而且要写注释和总结；
3刷先只写注释，不看文档实现功能，遇到问题再和文档比较，加深理解。如果还有余力，就和我一样整理成文章，分享出来帮助大家学习，回馈社区。
在掌握Go基础之后，也可以通过“三刷”的方式掌握SQL,Redis,Linux，Nginx的基础知识点，这样就有能力开发Web项目了。
要进阶就要学“微服务”和“DDD”！下文也会重点讲讲微服务和DDD的概念，让大家先有个目标，这样才能心中有火，眼里有光。
通读一遍需求文档和原型图
梳理业务逻辑，进行抽象，明确有多少个功能需求要开发
根据功能需求创建数据库，创建表，添加字段，设置合适的字段类型，长度，主外键等
考虑业务场景，创建索引...
开始疯狂的CRUD...
开始疯狂的加Cache...
开发疯狂的给客户端提供数据接口...
持续迭代：根据业务增长做负载均衡、分库分表、读写分离....
展开
评论
点赞
#青训营笔记创作活动#
1月13日 Day3
今日学习：Mysql与B+树存储计算
基础知识一张数据表一般对应一颗或多颗树的存储，树的数量与建索引的数量有关，每个索引都会有一颗单独的树。主键索引也是聚簇索引，非主键索引都是非聚簇索引。除格式信息外，两种索引的非叶子节点都是只存索引数据的，比如索引为id，那非叶子节点就是存的id数据。B+树的查询是从上往下一层层查询的，一般情况下我们认为B+树的高度保持在3层以内是比较好的，也就是上两层是索引，最后一层存数据，这样查表的时候只需要进行3次磁盘IO就可以了(实际上会少一次，因为根节点会常驻内存)，且能够存放的数据量也比较可观。如果数据量过大，导致B+数变成4层了，则每次查询就需要进行4次磁盘IO了，从而使性能下降。所以我们才会去计算InnoDB的3层B+树最多可以存多少条数据。
不同条件算出来的存储大有不同，具体计算方法反复看下方文章，满满干货，看了半天才摸索出一点点，看来只有更加深刻的学习才能学到真本事
1月13日 Day3
今日学习：Mysql与B+树存储计算
基础知识一张数据表一般对应一颗或多颗树的存储，树的数量与建索引的数量有关，每个索引都会有一颗单独的树。主键索引也是聚簇索引，非主键索引都是非聚簇索引。除格式信息外，两种索引的非叶子节点都是只存索引数据的，比如索引为id，那非叶子节点就是存的id数据。B+树的查询是从上往下一层层查询的，一般情况下我们认为B+树的高度保持在3层以内是比较好的，也就是上两层是索引，最后一层存数据，这样查表的时候只需要进行3次磁盘IO就可以了(实际上会少一次，因为根节点会常驻内存)，且能够存放的数据量也比较可观。如果数据量过大，导致B+数变成4层了，则每次查询就需要进行4次磁盘IO了，从而使性能下降。所以我们才会去计算InnoDB的3层B+树最多可以存多少条数据。
不同条件算出来的存储大有不同，具体计算方法反复看下方文章，满满干货，看了半天才摸索出一点点，看来只有更加深刻的学习才能学到真本事
展开
评论
点赞