关于复杂业务逻辑使用SQL还是java代码实现的思考

先说结论：建议复杂业务逻辑使用java代码实现或者两者结合使用，将两者的优势结合起来。以下为本人的相关依据：

业务场景

现在有一个复杂业务逻辑需求。此时有两种实现方法：

1. 写一条复杂SQL，相关业务逻辑写在SQL中(重SQL)
2. 写多条简单的SQL，在service层进行调用处理。(重Java)

接下来通过各个方面来分析一下两种方式的优缺点。

开发效率方面

开发效率方面，使用SQL实现的方式明显比java实现要快很多。

• 使用SQL写复杂业务，写完后在数据库中运行一下，结果正确的话就可以直接使用了。
• 而使用java实现则需要先去多个dao层拿基础数据，如何还需要在service层进行处理等一系列操作。

架构升级方面

• 使用SQL实现复杂的逻辑，当需要优化查询时间时先使用索引和各种优化策略，但是如果此时还是查询太慢，就需要加cpu，加内存，换SSD等等。
  如果此时表中数据量过大还需要水平分表时，而业务逻辑跟数据库的数据是强耦合的，这时候就只能通过java重新业务逻辑，实现分表了。
• 而如果使用java实现，如果遇到数据库瓶颈，则可以使用缓存、分库分表等方法，应用层基本不用改，在DAO层进行路由。

可维护性方面

• 复杂的SQL虽然可以实现业务逻辑，但是它难以维护和调试。当复杂的SQL慢慢变成成百上千行时，导致代码变得难以理解和修改。如果此时需要添加新的逻辑或修改原来的逻辑，那对开发人员来说将是一场噩梦。复杂SQL换个人来很难理解其意图，这涉及到项目的数据模型+业务逻辑，对这两者都要了解才能真正理解表关联之后的数据结构。
• 相比之下，使用Java实现业务逻辑可以更好地分离业务逻辑和数据访问逻辑，使代码更加清晰、易于维护和调试。此外，使用java编写业务逻辑还可以利用java的面向对象编程特性，使代码更加可扩展和可重用。

业务逻辑复杂度方面

• SQL：如果业务逻辑主要涉及数据检索、排序、分组等操作，使用 SQL 通常更加简洁明了。
• Java：如果业务逻辑涉及复杂的条件判断、循环、外部服务调用等，使用 Java 则更合适。

资源开销方面

• 复杂查询将逻辑写在一个SQL中，在数据库中只查询一次，网络IO开销较少，这点是优点。但复杂SQL随着时间推移，将会越来越复杂，如果计算量大，则会极度耗费数据库服务器资源，而且不易优化，如果存在分表分库的需求，或者服务拆分，复杂sql就是拦路虎。
• 使用java代码实现会将逻辑拆分成多条简单sql，会产生更多次IO操作，这点上会存在更多耗时操作。所以循环查询这个是不推荐的，但可以通过分页等来一次查询多条记录，但这种service层就更复杂，好处是容易做到水平扩展，应用服务器做集群远比数据库更简单轻松。

如何选择

• 如果是在业务初期，并且需要快速开发上线，那么使用重 SQL 模式也是可以理解的，但是还是要抽时间重构成 Java 模式。
• 如果项目已经开发成熟了，那么旧的重 SQL 逻辑可以暂时不动，新的逻辑都基于 Java 模式开发，先保证慢 SQL 不增加，旧的 SQL 稳定运行，毕竟业务稳定是第一要素。
• 如果本身就是多服务架构，还是用简单sql更好。如果是单体架构，复杂sql和简单sql组合都无所谓，但简单sql的组合代码更容易复用，也更能充分利用代码生成工具来生成增删改查代码。

总结

• 开发多年以来，发现系统的瓶颈基本都在数据库，复杂sql就是其根源，难优化、难拆分、业务逻辑分散到sql中、不容易利用IDE等工具定位问题。
• 因此不建议直接在sql里包含过多逻辑，数据库层就做增删改查，能单表操作就单表操作，会省去很多时间如sql优化、由于复杂sql导致的bug等。建议将复杂业务逻辑使用java代码实现或者两者结合使用，将两者的优势结合起来。

参考文章：慢SQL，压垮团队的最后一根稻草