先问一个问题：你的团队在用几个数据库？
MySQL 做 OLTP、PostgreSQL 做 OLAP、Snowflake 做数据仓库、偶尔还要给某个历史遗留的 Oracle 系统跑个报表……这几乎是现代数据团队的标配。
然后问题来了：同一段业务逻辑，你要写几遍？
“方言税”：每个数据库都在收
SQL 有个很微妙的东西叫“方言”。标准 SQL 是一回事，但每个数据库都有自己的“口音”：
MySQL 的 LIMIT，在 Oracle 里是 ROWNUM，在 SQL Server 里是 TOP
日期函数：MySQL 用 DATE_ADD，PostgreSQL 用 INTERVAL，Oracle 用 ADD_MONTHS
字符串拼接：MySQL 用 CONCAT，SQL Server 用 ，PostgreSQL 用 ||
窗口函数的支持程度、CTE 的递归语法、GROUP BY 的严格程度，各有各的规矩
你花了一下午调通了一段复杂的分析 SQL，在 MySQL 上跑得欢。然后需求来了：同样的逻辑要在 Snowflake 上跑。你打开编辑器，把那段 SQL 复制过去，一跑——报错。
不是逻辑错了。是方言不对。
于是你开始改：LIMIT 换成 QUALIFY 的写法，日期函数全部重写，字符串拼接的语法换掉……改完了跑通了。但下次需求再变呢？再改一遍？再下次换个数据库呢？
你花在“翻译方言”上的时间，比花在“思考逻辑”上的时间还多。
这不是个别现象。Stack Overflow 的调查显示，开发者花在解决环境配置和兼容性问题上的时间，占编码总时间的相当大比例。而 SQL 方言差异，是其中最隐蔽、最消耗精力的一种“兼容性税”。
更糟的是，这种成本是累积的。每支持一个新数据库，你就要多维护一套 SQL 副本。三套数据库 = 三套 SQL。改一个业务口径 = 改三处地方。漏改一处 = 线上数据对不上 = 半夜被叫起来修 bug。
为什么不能“写一次，跑所有”？
你可能会想：“那用标准 SQL 不就行了？”
理论上是这样。但现实是：标准 SQL 覆盖不了真实业务需求。窗口函数的方言差异、日期时间处理的五花八门、字符串操作的不同实现，这些在标准 SQL 里要么没定义，要么定义得太宽松，每个数据库的实现都不一样。
但反过来想：你需要的不是“一套 SQL 跑所有”，而是“一套逻辑生成所有”。
这两个概念的区别很大。
“一套 SQL 跑所有”是把同一段文本塞给所有数据库——这条路走不通。
“一套逻辑生成所有”是只写一次逻辑，让工具帮你翻译成每个数据库的方言——这条路走得通。
SQLazy 的做法：逻辑写一次，方言自动适配
SQLazy 走的正是第二条路。
你的逻辑用 workflow 写，就是那套分步的、可读的、按顺序排列的操作序列。然后编译器负责把它翻译成目标数据库的原生 SQL。
比如“计算股票最长连续上涨天数”这个逻辑，用 workflow 写：
这份 workflow 和数据库无关。它描述的是逻辑，不是 SQL 语法。
关键在于告诉编译器目标数据库究竟是哪一款——无论是 MySQL、PostgreSQL、Oracle，还是 Snowflake、BigQuery。一旦指定，它就能自动为你生成对应的 SQL。
同样的工作流，只需切换一个选项，即可生成不同方言的 SQL，无需重写任何代码。
工作流保持不变，因为核心逻辑未变。变化的仅仅是编译器输出的“口音”。
这意味着什么？
第一，你只需要维护一份逻辑。改业务口径，只改 workflow。编译器重新生成所有数据库的 SQL。不会出现“改了 MySQL 忘了改 Oracle”的情况。
第二，新人上手更快。不用学每个数据库的方言差异——只需要看懂 workflow，编译器负责处理方言。workflow 是给人看的，SQL 是给数据库跑的。
第三，迁移成本趋近于零。从 MySQL 迁移到 PostgreSQL？切换一个选项，重新编译，所有 SQL 自动适配。不用逐行改代码，不用踩方言的坑。
第四，审计更简单。你审查的是 workflow——一段可读的逻辑描述，而不是几百行分布在不同数据库里的 SQL 副本。
SQL 方言不是“小问题”。它是数据团队每天都在交的隐形税，每多一个数据库，就多一套维护成本，多一份出错风险。
SQLazy 的解法很简单：别让人类去翻译方言，让编译器去做。
你只管把逻辑写清楚。剩下的事情，交给编译器。而且逻辑还可以借助 LLM 来辅助实现，口语化表达可以被规范成 SQLazy 语句。
AI writes the logic. A compiler writes the SQL.
