无解的问题。不过 jdk 已经慢慢吸收了一些 lombok 的东西，lombok 也不是不可替代。

问题太多了，填完这个坑还有下个坑。op 你说的重复无意义数据其实是接口没做幂等生成的重复数据，本就不应该存在。
单从解决这个 sql 的角度来说，查询慢主要是因为 in 查询触发了全表扫描。
下策：mysql 有个 in 查询是否走索引的阈值配置，酌情调整该参数。但这个方案不解决根本问题。
中策：越复杂的查询精准分页越困难且无意义，劝说业务方放弃精准分页想法，用“加载更多”的类游标方式,每页数据不定长。去掉无意义的计算函数，去掉 groupby orderby ，子查询拆出来，在内存中分页，每次 in 查询中只查询不多于 10 条 task_id ，结果在内存中去重。
上策：提桶跑路。

不要面向 sql 编程。

jvm 没这么傻，linux 也没这么傻。

运行内存和你的 jar 包大小又没啥关系···和启动参数有关。

@linuxsteam 确实不可能 cherry-pick 后忽略...不要信任同事，自己再操作一遍试试。

是啊，用 java 的都是笨比，op 最聪明了呢。
认真回答下：java 主流规范目前不建议多表联查，有数据规模上升后的查询效率问题，分库分表后的重构困难等。复杂的 sql 往往会耦合业务，造成一些排查难、debug 难，是非常不推荐的开发方式。ORM 框架也没往这方向发力。
如果真想联查，用 @select 写个 sql ，mybatis 也不是非要写 xml 的。

爆痘刷酸合适吗？我一般是用阿达帕林，见效很快。

@hepin1989 你知道邓草原是谁嘛说人家圈钱？扣帽子扣挺快啊？家里帽子得堆到房顶了吧？

可以这样定义：语法糖反编译以后是另一种比较啰嗦的写法。

非常非常非常非常多

@roundgis 微博

即使新出的语言比发展了几十年的语言更优秀一些也很正常，世界在进步嘛。

不过语法糖这个东西，并不是越多越香。开发一时爽，维护火葬场。要不要加糖是一种取舍。

转自邓草原大佬的说法：

我为什么从 Scala 转回 Java 。1 、Java 已经吸收和实现了大部分类 Scala 的语法，而且还在继续； 2 、Java 的语法虽然没有 Scala 精炼但也更严格些 (也就是没那么灵活)，但有成熟 IDE 的帮助，写起来也不慢和少错； 3 、能招到更多的程序员。最后，现在的 Java 已经足够好了，成为各种因素下最均衡的。 ​

op 最好从一个具体的场景或问题出发，不然这个问题无法讨论。

你对这个场景的解决方案，问题太多了。
首先，RC 的隔离级别，即使加了索引和事务，也只有行锁没有间隙锁，你在 update...where （ A && B && C ）还是会受到另一个事务的影响，极有可能导致更新错误。
其次，从根源上来说上层代码逻辑本身就有问题，不太合理。

如果你只是想解决死锁问题，加索引即可。索引怎么设计取决于你 where 条件的字段的区分度和使用概率。但这样做不解决 RC 隔离级别下的不可重复读问题。但也有可能你的业务场景和并发度不会遇到这个问题。
最好不要 update...where id 或唯一索引以外的字段，可以先 select id where..，再 update...where id 。

SQL 层面没什么好优化的。
1. 审视全文检索的需求到底是否必要，业务上是否可以规避，比如只允许查询预先缓存的 keyword 。
2. 用 mysql 的全文索引肯定没问题啊，你说的某个人名 5000 多条慢 90%是 IO 原因。

你这样 update...where 不加索引的字段会锁表的，让老鸟看到该挨揍了。

@sqmwin 感谢，我也试试。