不加字符串会认为是数字, 2019-01 会被当做 2019 - 1 = 2018, 所以会不等, 加上引号才是字符串, 对于你程序来说你是 String 类型所以转成 sql 就是带引号的字符串

@yuhaocoding 贵州电信, 不过这个东西是全国的, 我的是计费那块的

@drich 这个还没了解, 现在就想多面试几家看看

@ivars 宇宙条有点虚啊，我到目前基本都是做业务的。暂时在准备几家的面试, 麻烦留个邮箱我后续看情况去尝试一发

@taoche 不是有仇，是上面说了已经投递了，流程已经开始了

乐观锁的本质上是消除锁定, 适用于高并发下 读多(读是无锁)写少 的情况, 用乐观锁就是写也不加锁，然后通过结果去重试, 如果写的请求很多极端点全是写的请求, 那么还不如悲观锁的效率高

@EmdeBoas 我只是大概知道题主想问什么，所以说的比较简单。ACID 是事务的概念，但要区分的话主要是数据库事务以及业务层的事务，数据库事务的 C 是非常清晰的，业务层的事务建立在数据库事务之上，它的 C 就像你说的模糊，但一般情况下业务层事务很少谈到 ACID，ACID 默认情况下其实指的是数据库事务。CAP 的 C 指的就是多个副本数据的一致性, 你说的强一致性包括答主所说的最终一致性只是对数据同步延迟的不同要求, 强一致性适用于实时交易系统，最终一致性多用于离线计算系统, 而像 zk 这种半写集群的一致性要求强度在两者之间。

不要弄混 ACID 中的 C 和 CAP 的 C，前者的重心在于系统整体的一致性, 后者指的是多个副本之间的一致性

###########################################################
# spring @Async
###########################################################
profiler.spring.async.enable=true
# Add custom AsyncTaskExecutor classes. Comma separated list of fully qualified class names. Wildcard not supported.
# Default values
# org.springframework.scheduling.concurrent.ConcurrentTaskExecutor
# org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler
# org.springframework.core.task.SimpleAsyncTaskExecutor
# org.springframework.scheduling.quartz.SimpleThreadPoolTaskExecutor
# org.springframework.core.task.support.TaskExecutorAdapter
# org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor
# org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler
# org.springframework.jca.work.WorkManagerTaskExecutor
# org.springframework.scheduling.commonj.WorkManagerTaskExecutor
profiler.spring.async.executor.class.names=

想要仿照 java 原生 api 你就得把对象映射成共享内存，这样就可以进程通信了，但这个仅限于同一台物理机。要想和机器也没关系，那就只能用中间件了，redis 、zk 好做一些，mq 的话在不考虑事务的情况下也可以使用

才几万条。。。别引入中间件了，直接用个线程池得了

有人工查看时间进行数据捞取的操作就 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 攻击这种估计瞬间就崩溃了。不过我觉得这个容器还是很有思考和时间意义的，分多少层？每层限量又是多少?我该是扩容下层还是当前层亦或是上层？