不限于 java 大多数语言都在去 xml 化，虽然它的描述能力更强，但冗余信息比较多不符合人的阅读习惯。具体到 Java 项目中 xml 已经越来越少了，Spring boot 中默认已经没有 xml 了，新的框架们尽管支持，但也都提供相应的注解使用方式。
注解从某种程度上来说有侵入性，且对于第三方的库除非使用字节码技术修改不然没办法直接使用注解；
xml 呢也有它的好处，集中式管理, 对业务代码无侵入, 比如 dubbo 的 xml 现在你想修改服务版本直接在一个文件中修改就好, 如果采用注解那么就要全局替换注解影响范围要大一些，此外还有调试的时候你可以在 xml 中选择只加载你需要测试的服务以及其依赖的服务，把其他的临时注释掉。

但新项目仍然建议使用注解方式，因为所谓的耦合性在实际的项目中并没有什么实际的影响，绝大多数情况下是可以忽略的, 同时可以更好的收敛我们的代码，在不滥用的情况下更清爽也高效

是否使用覆盖索引和 age 上面有没有索引有直接关系, 没有索引的话自然不会走覆盖索引, 而且你这个 age 还很有可能区分度 cardinality 不够或者数据量很小，CBO 发现全表扫描的 cost 反而比较小，那就直接扫全表喽

最简单的就是锁喽, 比较适合单机情况。单机下还可以使用 LinkedBlockingQueue 、线程池(其实也是 LinkedBlockingQueue)等 juc 下的并发容器处理
分布式下可以考虑用消息队列, 前提是本身系统已经引入了一种消息队列, 不然额外引入一种消息队列的成本还有待商榷
想要轻量级就用个分布式锁，实现方式最好也与当前中间件结合，有 zk 用 zk，有 redis 用 redis, 啥都没有就用数据库或者文件去做

spring5 默认 jdk, spring boot2 默认 cglib

不加字符串会认为是数字, 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