几百行SQL不一定是问题，得看它为什么长。

有些场景就该用SQL处理

数据仓库里的ETL脚本、BI报表的取数逻辑、月度数据对账——这些场景天然就是多表关联、多层聚合、条件分支。把这些逻辑拆到应用层，你得写更多的Java代码、发更多次SQL查询、在内存里做更多次数据拼装。最后代码量未必少，性能还可能更差。

一个统计报表，需要关联5张表、按部门汇总、过滤掉已删除的记录、计算环比增长——这写成SQL可能80行，写成Java可能200行外加10次数据库查询。在这个场景里，SQL才是正确答案。

更多时候是历史包袱在作怪

很多项目里service层基本没有逻辑，所有处理全是SQL实现的。这种代码库几乎一定有个共同特征：是很多年前某个人起头写的，然后被一代代人往上加。

最初可能只是一条100行的SQL，后来业务加了一个字段，有人直接在SQL里加了一个LEFT JOIN。再后来业务又加了一个过滤条件，有人又加了一个子查询。五年下来，原来100行的SQL变成了300行，但这300行里有一半是互相依赖的——你动其中任何一块，不知道会影响哪里。

这不是写这些SQL的人水平差，而是没有人愿意在一个运行着的系统上动大手术。改SQL出了问题，数据跑错了，你得背锅。不改，下一个接手的人骂你两句，你不在乎。这就是为什么屎山会持续积累。

真正的问题是关注点混乱

但更常见的情况是滥用——大量业务逻辑不该放SQL里。三四个LEFT JOIN套着三重子查询，查询出来的数据还要在SQL里做格式转换、字符串拼接、条件判断——CASE WHEN 写了几十行、IF(condition, a, b) 嵌套了好几层。

这种SQL的问题不是"行数多"，是关注点混乱。数据获取（SQL）和业务逻辑（应该在应用层）被混在一起了。结果就是：SQL极难读懂，因为你要同时理解数据结构和业务规则；业务逻辑极难修改，因为你得懂SQL才能改；单元测试极难写，因为你没法在不跑数据库的情况下测试逻辑。

为什么有人这么写

不是因为想"凸显自己强大"，大部分人写复杂SQL是因为：

当时图省事。 在数据库层面做完所有事，service层直接拿结果用，开发速度快。不用考虑ORM的N+1问题，不用写数据组装的代码，一条SQL全搞定。短期看确实省事。

历史上有人这么写，后来的人跟着学。 代码风格有传染性。新来的人看到项目里到处是几百行的SQL，就以为这是"正确的写法"，然后继续这个风格。

对"SQL能做什么"理解不深。 很多写复杂SQL的人其实并不擅长SQL，他们不会写窗口函数、不会用CTE（Common Table Expression），只会用子查询和JOIN来实现需求。子查询嵌子查询，SQL就自然越来越长。

反过来，真正擅长SQL的人写的查询往往比别人短——因为他们知道用窗口函数一行解决的问题不需要写子查询，知道用CTE把逻辑拆成几步读起来反而清晰。

几百行SQL怎么重构

如果你要接手这种代码，有几个思路。

先读懂，再动。 看不懂就不要动。加一行注释解释你理解了什么，下次再看至少有个起点。很多人接手屎山的第一反应是"我来重构"，结果改了之后出了新的bug，反而比原来更难维护。

用CTE（WITH 子句）重写，把长SQL拆成命名的步骤。 MySQL 8.0、PostgreSQL、Oracle都支持CTE。如果你们还在用MySQL 5.7，那只能用子查询或者视图来拆，但升级到8.0本身也是应该做的事了。原来一条300行的SQL嵌套了五层，可以用CTE把每一层抽出来，给它起一个有意义的名字：

WITH 
active_users AS (
    SELECT user_id, nameFROMusersWHEREstatus = 'active'
),
recent_orders AS (
    SELECT user_id, COUNT(*) AS order_count 
    FROM orders 
    WHERE created_at > NOW() - INTERVAL30DAY
    GROUPBY user_id
)
SELECT u.name, o.order_count
FROM active_users u
JOIN recent_orders o ON u.user_id = o.user_id;

逻辑没变，但每一段的意图很清楚。维护的时候可以单独调试某一段。

识别哪些逻辑该下沉到数据库、哪些该上移到应用层。 纯粹的数据过滤、聚合、排序——留在SQL里。业务规则判断（比如"如果用户等级是VIP且订单金额超过500就打折"）——移到应用层。字符串格式化、枚举值的文字描述——移到应用层。

不要追求一次重构完成。 每次改这个模块，顺手把你改的那一段SQL清理一下，长期下来代码库会慢慢变好。一次性大重构风险太高，而且很可能改了一半就被新需求打断，留下一个更乱的状态。

几百行的SQL在某些场景下是合理的，在大部分业务系统里是可以重构的，但"可以重构"和"现在就要重构"是两回事。判断标准很简单：这块代码还要不要继续改？要改就重构，不改就算了，别浪费时间在稳定运行的屎山上。