有人工查看时间进行数据捞取的操作就 timestamp 和 datetime，时间要求范围不大的话就 timestamp，注意时间一定要给默认值，不然加索引的索引可能会失效，没有人工查看操作直接 int 性能最佳计算也方便

真实占用没区别，但是在索引创建方面有区别，也会影响总的行长，进而影响行的组织方式，可能会频繁引起页分裂啥的，所以能确定小于 64 就 varchar(64), 后续可能会有改动又不知道多大就直接 varchar(255)，不然从小改到大锁表时间，还有上面说到的页分裂都有可能引发问题

@daozhihun 这只是个近似说法，因为正常情况下使用不到上限而已。而上面的完美散列也只是利用黄金分割率来达到一种勉强的不冲突而已(也没有真实达到)，这个方法的好处只在于计算 hash 的方法极其简单所以性能也非常的好

完美散列是指 hashCode 不冲突，但是桶位的计算一般都是取后几位那么就很有可能冲突，说到底你混淆了桶位和 hashCode

大概率是插件问题，看 system\log 下的 idea.log

查询语句可以带主键(趋势递增才可以), 比如原来的语句是 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

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