Kysely项目中UNION ALL与LIMIT的语法问题解析

在SQL查询构建器Kysely的使用过程中，开发者可能会遇到一个关于UNION ALL操作与LIMIT子句结合使用的语法问题。这个问题涉及到SQL查询的结构和不同数据库方言对集合操作的处理方式差异。

问题现象

当开发者尝试构建一个包含UNION ALL操作并同时使用LIMIT子句的查询时，Kysely会生成包含重复LIMIT子句的SQL语句。例如：

SELECT * FROM "links" WHERE $1
UNION ALL
SELECT * FROM "links" WHERE $2
LIMIT $3
LIMIT $4

这种语法在PostgreSQL等数据库中是不合法的，会导致查询执行失败。开发者期望的语法应该是每个子查询单独应用LIMIT：

(SELECT * FROM "links" WHERE $1 LIMIT $2)
UNION ALL
(SELECT * FROM "links" WHERE $3 LIMIT $4)

技术背景

这个问题源于不同SQL方言对集合操作(UNION、INTERSECT、EXCEPT等)的实现差异：

1. 在某些数据库中，UNION操作被视为父查询的一部分，父查询的某些子句(如LIMIT)会应用于整个UNION结果集
2. 在其他数据库中，通过正确使用括号，可以将集合操作视为独立的子查询集合，其中没有"主"查询的概念

这种差异使得构建跨数据库兼容的查询构建器变得复杂，特别是在处理LIMIT等子句时。

解决方案探讨

Kysely项目维护者提出了几个潜在的改进方向：

1. 引入新的独立union函数(以及intersect、except等)，提供更清晰的语法：

unionAll([select, select]).execute(db)

2. 结合更通用的db.execute方法，提供统一的查询执行接口：

db.execute(unionAll([select, select]))

3. 考虑将数组形式的unionAll直接放在db对象上，简化API使用：

db.unionAll([...]).execute()

最佳实践建议

在当前版本中，开发者可以采用以下临时解决方案：

1. 使用原始SQL片段绕过问题：

(await db.executeQuery(sql`${select} union all ${select}`.compile(db))).rows

2. 避免在UNION操作中直接链式调用LIMIT，而是为每个子查询单独应用LIMIT

长期来看，等待Kysely提供更完善的集合操作支持是最佳选择，这将确保生成的SQL语法正确且跨数据库兼容。

总结

SQL查询构建器在处理复杂操作如UNION ALL时需要考虑不同数据库的语法差异。Kysely项目正在积极改进这方面的支持，开发者应关注API更新，同时可以采用临时解决方案应对当前限制。理解底层SQL语法规则有助于构建更健壮的数据库查询。