scala 写 flink 比用 java 舒服一些。

mysql 的使用不太对吧，并行写入同一张表对写入性能不会有提升，线程开那么多也没啥用啊。可以考虑不用 mysql ，数据放 kafka 。
看起来这个场景用大数据工具解决会简单很多，spark/flink 之类的。

1. 数据层的 sql 枚举出所有 join 情况，根据前端回传的字段列表选择 sql 。
2. 把 join 从 sql 提到代码层，其他和 1 相同。这样更容易控制。
3. 数据层返回全部字段，代码中筛选。查询慢的问题可以做缓存和预查询。但查询过于复杂可能会影响数据库整体性能，编码层面无法解决。

3 最简单，2 最清晰。按需选择。

你司大佬排斥 stream 的原因无非这么几条：
1. 可读性差。理论上 lambda 范式的代码可读性会更好。如果可读性变差了，说明姿势不太对，业务逻辑和控制逻辑没有分离。
2. 性能损耗。据说相比 for loop 大约 15%的性能损失。但对业务代码来说是可接受的。
3. 不便调试。这个要看具体案例，个人认为不是问题。
4. 老派守旧。无解，建议换公司。

redis 内部是一个伪单线程实现，一个 keys 会阻塞后面所有的查询，导致全部超时。

怎么敢在生产环境用 keys ，要丢饭碗的啊

你要同步本地缓存，就大大增加了缓存技术的复杂度，有一点得不偿失。
一般是一级本地缓存过期时间尽量调短一点，损失一定的一致性来换性能。

再说你把本地缓存搞成分布式的，还要二级 redis 干嘛？

没什么需要注意的啊，网速跑不满找联通的人处理就好了。

爬虫框架不都带这个吗

好像 python 就是这样做的？
API 的设计是一门科学，各自有不同的取舍。

A 里有长事务，alter 在等锁？
话说你驱动更新了吗。

1. "1w 条提交给 topic1,小于 1w 条提交给 topic2"，分两个 topic 是有业务含义吗？如果没有的话这个逻辑是很有问题的。
2. "1w 条写 topic"是在 kafka 里写了 1w 条，还是写了一条，里边放了 1w 条数据？如果是后者，这样做是非常有问题的。
3. 你的 kafka 集群有多大？该 topic 分区有多少？听起来好像只有一个分区？有分区逻辑吗？比如你完全可以根据数据量写到不同的分区，而不是创建两个 topic 。
4.至于你说的“每个任务对应一个 topic ，用完删除”的想法更是有点异想天开。首先 kafka 已经是吞吐量最高的 mq ，且吞吐量不受存储数据量影响。其次，“用完删除”没有意义，高性能的分布式数据库 mq 等基本都是标记删除，而且高吞吐 mq 的数据都是放在磁盘的，删除 topic 只是个手动腾出磁盘空间的操作，有什么意义？

总之你遇到的问题不是 kafka 的问题，也不是换个 mq 可以解决的问题。看看 kafka 的性能瓶颈在哪里，可能是分区、网络 io 、内存之类的。

和数据量有关系，直觉上应该不会减少。

@Mateverse “[op] 和 [楼里一些优越感很强的 kt 程序员]”，没说你优越感。

这帖子多少有点引战，我上一句也有点过激，不会再回复了。

还是建议大家多用一用其他语言的，像 op 和楼里一些优越感很强的 kt 程序员，怎么说呢，多少沾点...

还有就是，理论上其他 JVM 语言有的东西 Java 都可以加上去，再不济可以混合编译。
“加功能”总是很简单，“该不该加”、“要不要加”、“怎样更好的加”背后的东西才是需要思考的。
Java 再差也不可能搞出高版本不兼容低版本这种事来。这是包袱，也是责任。

@changhai 我的意思是说因为语法糖去攻击 Java 没有必要，虽然这事情我也做过。

打败 Java 的不会是一个修补版的 Java 。

为啥不用 scala ？语法糖比 kotlin 还多。
以前我也怒喷过 Java 在语法方面的不思进取，后来看了看 JDK 的更新，模块化、G1 、ZGC ，工程方面的大动作真的不含糊，相比之下语法糖那点真不是啥大事。
再后来用了用 scala ，语法糖见缝插针，多到吐血，滥用到 IDE 都不知道你的代码对不对。
个人认为 JDK17 已经是比较完美的状态，该有的差不多都有。
打败 java 的不会是另一种 jvm 语言。

myql 有个配置是 in 里多少个值不走索引。比较多的话会全表扫描。