对于"该学什么语言"这个问题，社区的回答总是层出不穷——Go、Rust、Elixir、Haskell……每隔几年就会出现一个新的"正确答案"，让开发者不断重新投资学习。但 Fagner Brack 最近的一篇文章提出了一个反直觉的观点：SQL 是少有的、经得起时间考验的编程语言，一次学会，受用三十年。

SQL 建立在数学之上，而非潮流之上

这个结论的核心在于 SQL 的底层基础。SQL 建立在关系代数（relational algebra）之上——这是一种数学框架，不会因为语言流行周期的变化而改变。这意味着 1995 年写的一条 SQL 查询，今天在 PostgreSQL 中无需任何修改即可运行。而 JavaScript 代码从 2015 年运行到今天，往往需要更新依赖、调整 API、修改构建配置才能正常工作。

这背后的原因很清晰：SQL 采用的是声明式模型——你描述你想要什么结果，由引擎来决定如何执行。这种设计使得引擎可以在不改变查询本身的情况下持续优化性能。SQL 的稳定性来自于它解决的不是技术问题，而是数学问题。

技术框架与数学基础的区别

JavaScript 和它背后的框架（React、Vue、Angular 等）代表的是一种截然不同的路径：命令式编程加持续迭代的框架。这意味着每隔几年，开发者就需要重新学习思维模型、API 和最佳实践，才能跟上前端生态的变化。这种"时尚驱动"的演进方式带来的问题是：每一次框架升级，都意味着旧代码需要被翻译成新范式，而这种翻译往往伴随着破坏性变更。

SQL 则不同。它没有"版本升级"的概念需要开发者焦虑。一条正确写出的 SQL，其含义在 1995 年和 2026 年之间是稳定的。引擎会变，优化器会变，性能会提升，但代码本身不需要改。这对于长期维护来说，是一个本质性的优势。

实践建议：40 小时换一个职业周期

作者给出了一个务实的建议：初级开发者应该在 SQL 上投入约 40 个小时，系统掌握联结（joins）、子查询、窗口函数（window functions）和查询计划（query plans）。这个投资的回报可以跨越多个工作角色和数十年。

这 40 小时不是用来学语法的，而是用来建立一种思维方式——如何用关系代数的思维来组织数据查询。一旦掌握了这个思维方式，你会发现它在不同的工作场景、不同的数据库产品之间高度可迁移。

SQL 的缺陷同样值得知道

文章也承认了 SQL 的一些长期缺陷：NULL 的三值逻辑（true/false/unknown）、GROUP BY 中重复的列名列表、以及不同数据库厂商对日期处理的不一致。这些问题确实存在，而且因为向后兼容的原因，SQL 标准一直没有修正它们。

但这恰恰说明了作者的核心论点：向后兼容性保留了你写的旧代码，同样也保留了这些不完美。这是一个交易——你接受 SQL 的缺陷，换来的是你今天写的查询在十年后依然能运行。

对于正在选择学习方向的开发者而言，这篇文章提供了一个值得认真对待的思路：与其追逐下一个框架热点，不如把时间花在一种稳定、跨场景、可迁移的技能上。SQL 可能是少数几个真正符合这个标准的选项之一。

参考来源：https://fagnerbrack.com/learn-sql-once-use-it-for-30-years-9aceb0bdee03