1.巩固mysql的B+树优势，以及mysql究竟在哪里处理数据。
MySQL既可以在磁盘中处理数据，也可以将数据加载到内存中进行处理，这取决于具体的配置和使用情况。通常情况下，MySQL会将热数据（经常被访问的数据）加载到内存中进行处理，而把冷数据（不经常被访问的数据）保留在磁盘上。这可以提高查询效率和响应速度。同时，MySQL也提供了缓存机制，将一些经常使用的查询结果缓存到内存中，避免频繁地从磁盘中读取数据。但是，如果系统的内存不足以加载全部的热数据，MySQL也可以在磁盘上进行处理。此时，可能会出现较慢的查询响应时间。因此，在实际使用中，根据具体的场景和需求来配置MySQL的内存和磁盘使用是非常重要的。
由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。预读可以提高I/O效率。预读的长度一般为页（page:计算机管理存储器的逻辑块-通常为4k）的整倍数. 主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时，会触发一个缺页异常，此时系统会向磁盘发出读盘信号，磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中。
综上可以看到，在有条件的情况下，是可以选择内存中处理数据的，那么这时候我们就应该尽可能减少IO的次数，平衡二叉树为什么不好用，就是因为IO次数太多了，如果一次IO只读出一个节点，一个节点上只有一个数据和两个指针，太亏了，尽管有预读机制，但上面也说了，预读基本上是以页为单位。
至于B+树比B树好在哪儿，首先全表扫描的话只需要扫描所有叶子节点的链表，没有B树那么复杂，其次范围查询也更方便，这个不用多说。最后聊聊IO次数的问题，如果非叶子节点既有数据又有指针，不可否认会有运气好的时候，甚至一次IO就拿到了数据。但是更多情况下会将大量的无用数据IO到内存，而B+树只有最后一次才有可能读到无用的数据。
简单计算一下，索引值的大小约为6B，如果一张表只有一列，且只填了一个1，这时候一条数据的带下约为4B，这时候显然B树效率更高，因为节省了6B的空间，但如果一条数据的规模远大于索引值的6B，那么非叶子节点存放一条数据的空间可以替换成无数个索引值，显然总体上会极大减少IO次数。
2.final关键字
3.kafka目前能记住的点
我的系统中用于特检院系统想云平台推送数据
scala和java编写的，相比rabbitmq，不那么准确
依赖于zookeeper集群进行选举，这个选举过程非常简单粗暴，就是一个谁先谁当的过程，不涉及什么算法问题。
java中的使用：
new KafkaProducer()、new KafkaConsumer()
标签：查漏,12,MySQL,内存,IO,补缺,磁盘,数据,预读 From： https://www.cnblogs.com/lvjiawei/p/17552344.html