泛型 List<T>

顺便用抓包工具看一下 tcp 连接数还有数据包的大小

很奇怪的现象。执行语句的客户端是哪个？ Navicat ？ DataGrip?PLSQL ？

1.别用触发器；
2.考虑做分表；
3.在代码里做好数据的清洗，最好是先删除数据库中较老时间的数据然后再插入，能不用 update 就尽量规避；
4.注意调整 max_allowed_packet 的限制。

严格意义上数据库的 decimal 能够满足需求但是数据处理上比较蛋疼，有条件的话用 bigint 存储分，然后整个后端操作里全都使用分单位,尽量避免小数的出现，唯一的缺陷就是 bigint 比较耗费空间 decimal 在 8 位小数时才用 8 个字节，考虑到分单位可能实际中只需要用 5 个字节，相当于每一条记录多浪费 3 个字节的空间，再加上金额这个字段有很多种，结合下来整体的开销还是不小的。所以这就是个用存储换舒适度的问题。

@jry 你认真的？普通项目能不能活过 6.9 年都是个问题。。。

分布式 id 为什么不用推特的 snow 算法生成，uuid 的缺点太明显了

不难

看下结果集数据量，navicat fetch 的可能不是全部数据。

我司电信项目的并发标准是日常 500qps, 峰值 3 倍也就是 1500qps，实际压测中可以达到 10000qps，当然和互联网公司没得比，真正的互联网公司的高并发至少要 10w 级

从设计模式的单一职责原则来说不建议 service 的互相调用，相似的业务也应该由多个 Dao 重新组合完成实际业务，但是这样会带来大量冗余，好处是各个 service 完全独立没有相互耦合。相对的 service 互相调用则可以使得代码更为简洁业务上的相关性也体现在了代码上，在需要修改时只需要修改被依赖的 service，在重构时有很大的作用。业界对于耦合十分厌恶，比较互联网项目基本都拆除了外键，所以 service 只调用 dao 是一种更严谨的方式，service 之前的相互依赖一旦随着项目推进逐渐增多就会变成项目的负债让项目的推进越来越难。如果项目中没有严格规定的话，要考虑好两个 service 所对应的顶层业务是否需要这种关联性，需要则 service 调用 service，不然还是调用 dao 重新组合业务好了(这种方式调优时也有明显优势)。

instrument、aop、asm、javasist

做 CI 不 pull 怎么行，封版就是让大家过个好年

用 docker 好一点，但也有 windows 的版本

me too

老接口有很多。。。而且一般也没啥动力重构

那么多链路，浏览器、反向代理、安全校验、业务校验，一般根本到不了数据库，数据库本身也有对数据块大小的限制

为了个剪切板，我升级了 windows 的开发版。。。不过真的还挺好用

新版不是出了个 Services