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 里多少个值不走索引。比较多的话会全表扫描。

不就是遍历对象么？难点在哪。

好像只能在内存里处理。你的需求有点像 elasticsearch 的相关度概念，可以自己用代码简单撸一个。不要苛求都可以在 sql 里解决。

很棒，尝试订阅了一些。

方案一中“建索引后查询性能有所提升但插入速度较慢”，感觉写入速度不应该是瓶颈...mysql 写入有不少优化方案，真心数据量特别大还可以 load data 。