查询语句可以带主键(趋势递增才可以), 比如原来的语句是 select * from table limit 1000,10(单页 10 条), 现在给改成
1.select * from table where id >= (select id from table 1imit 1000,1) limit 10
2.Select id from table limit 10000, 10;Select * from table where id in (123,345....);
3.select * from table INNER JOIN (select id from table limit 10000,1) using (id);
4.在代码里记录最后一条的 id, select * from table where id >= ? limit10;
简单来说就是只扫描主键不扫描行记录, 减少一次 B+树中的搜索

@22yune 你这个东西越说越像 B 树了。。。其实我觉得这种东西一定要结合实际业务场景来思考，一定要能解决在某种情况下的技术痛点，在某些场景下比 HashMap 更优更让程序员"偷懒"。 就好比 HashMap 红黑树的树化阈值是 8，是因为 hash 碰撞 8 次的可能性是亿分之六(假设数据遵从泊松分布)，所以它在实际使用中几乎很少树化（更多是为了应对 hash 攻击），但在某些领域要求极其严苛的情况下，你能将这亿分之六都处理好那么你这个东西就有很高的实用价值。

@22yune 你分层是有限的，你的 hashCode 的位数总会被使用完, 而你分层越多，你的容器的容量就会越小。这两个其实还可以接受, 因为正常使用中容量也许不会很大(或者我们就是要创造一种需要结合业务使用量分配层数的容器)，更加致命的是随着容器的层数的增加，扩容带来的开销成倍增长，在理想情况下可以并发进行，但如果遭遇 hash 攻击这种估计瞬间就崩溃了。不过我觉得这个容器还是很有思考和时间意义的，分多少层？每层限量又是多少?我该是扩容下层还是当前层亦或是上层？

https://dev.mysql.com/doc/refman/5.7/en/ 和 https://dev.mysql.com/doc/refman/8.0/en/
算是最全面的介绍了

没听说过静态表动态表这个说法，官方没有这个概念，估计是"以讹传讹"了。官方只有行格式 Row Formats 的概念 https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html 默认情况下就是 DYNAMIC 。顺便说一句，mysql 要用就别用 5.7 以前的了，之前版本的性能和特性。嗯，你懂得。

题主可能是想通过无锁化来基于 HashMap 创造一种新的更高性能的并发容器，但我觉得难点其实在于 hash 冲突的问题，一个 hash 碰撞率极低的算法它的实现是极为繁琐的，哪怕你实现了它的性能必然也是很低下的，所以很多人才没有朝这个方向发展，就像都知道 RSA 的安全性更高，实际代码中加密却还大多数是 MD5

把十进制转成二进制就看出规律了, 0100，相当于取第三位, 这个做法比较老但还算常见, linux 的常用权限 755, java 里面对于修饰符的判断都有用到

gc 占用的 cpu 已经很少了，不知道你怎么先入为主得出这个结论的。顺便吐槽下 gc 日志不给，只给个线程的快照有什么用

条件允许直接上 arthas，把你整个函数切成片分析

jstack 看线程，打印什么的不靠谱，不一定是业务线程。我这就遇到过很多其他处理阻塞主程的操作, 比如日志输出（输出流重定向到 kafka ）因为用的第三方库不够健壮一步发送 kafka 消息阻塞了业务线程。

更省内存呗。。。用 jol 打印下内存布局就知道，以前 Java 主要考虑易用性，现在开始优化语法糖和内存了，变成更好的语言吧

和 Spring Cloud 以及 docker 都没啥直接关系，简单来说就是把原本要写到日志文件的输出流重定向到 elk 那边，至于是通过 filebeat 还是直接写 kafka 实现都是可以的。至于你说的 index，同一个服务用一个 index 比较好, 我这边日志量大点(一天 200G 左右)，所以是每一天一个 index(同一个服务是一样的), 最后对于日志量的问题踩了不少坑, 比如最终展示的日志是在 es 的，所以其它中间的日志保留时间可以很短, 另外像一些心跳监测的日志也可以直接做一下过滤, 还有 es 支持数据生命周期管理，比如三天内设为 hot 数据, 七天就是 warm 数据, 超过半个月就是 cold, 一个月的直接 delete(具体视业务特性而定)

不超过十个 spring 自己够用, 超过十个上个配置中心好了， 比如 nacos

不涉及修改就不会有问题。。。

Invalidate Caches 试一下, 不行就把.iml 和.idea 删了重新导入

很有趣的问题， 看了下源码 byte b 在处理时被装箱成了 Byte，有趣的是 new Byte(1)和 new Integer(1)的 hashCode 是一样的, 这很容易让人困惑, 但在 HashMap 569 行(k = first.key) == key || (key != null && key.equals(k))) 中对 key 除了 hashCode 的判断还有对类型的判断(见 Integer equals 方法 974 行)。同理你使用 map.get(new Integer(1)) 就可以取出对应的值来, 哪怕不是同一个对象也依旧可以取出你想要的值, 因为 new Integer(1) equals new Integer(1)

集群熔断降级重启定时扫描

CompletableFuture 是最佳方案，dubbo 自己的异步调用就支持。话说 IO 多才更适合使用 CompletableFuture, 能让 CPU 更充分利用,谁说不利于高 IO 的？我能想到的只是高 IO 对系统危害比较大, 以及失败及异常处理较为复杂。

处理 json 从来都不是瓶颈，至于说比性能，要看谁比, 比 C++肯定不信, 但一些静态语言应该还是比得过的。
所以要想快用 C++写好, 然后通过 JNI 调用