想象一下，如果 WordPress 开发者突然发现下一个版本的 WordPress 放弃了 PHP 支持，改为使用 Ruby，所有的主题和插件都必须重写，要么被困在旧版本中，永远无法升级。或者，假设微软突然决定将 Windows 管理从 PowerShell 转向 Bash，Windows 管理员们不得不更新所有的脚本，以便在下一个更新中使用 Bash。
如果你已经使用过 InfluxDB，可能就不需要想象这些情景了，因为这实际上已经发生在 InfluxDB 的用户身上，而且不止一次。
InfluxDB的“三重语言”困境
InfluxDB 最初于 2013 年发布时，使用了 InfluxQL 作为查询语言。InfluxQL 是一种类似 SQL 的语言，专门为时序数据设计。尽管其语法与 SQL 相似，但灵活性较差，数据聚合和转换的便捷性也较小。
然而，随着 2020 年 InfluxDB 2.0 的发布，Flux 语言被引入。Flux 比 InfluxQL 更强大，但也更为复杂。用户表示，他们需要参加“InfluxDB 大学”课程才能理解这门语言，而且通常要参与三个以上的 Flux 项目才能真正熟悉并运用这门语言。InfluxDB 当时信心十足地认为 Flux 会是未来的方向，许多忠实用户也纷纷投入时间，翻译查询并重写应用程序，以支持 Flux 语言。
但谁能想到，仅仅四年后，InfluxDB 3.0 发布时，Flux 却被弃用，取而代之的是 SQL。那些花费时间学习 Flux 并更新项目的用户，发现自己无法将项目升级到 InfluxDB 3.0，并且意识到他们在 Flux 上投入的时间和精力付之东流。
虽然 TDengine 和 InfluxDB一样认为 SQL 是时序数据库的最佳语言选择，但我们更希望他们能在浪费广大用户的时间之前，就得出这个结论。
Flux与SQL查询对比
以下是 InfluxDB 的 Flux 查询与 TDengine 的 SQL 查询对比，直观展示了两者的简洁性和可读性，给到大家参考。
Flux查询：
from(bucket:"power")
|> range(start:-1h)
|> filter(fn:(r) =>
r.measurement == "smeter" and
r.field == "voltage" and
r.location == "chicago"
)
|> aggregateWindow(every: 1m, fn: mean)TDengine SQL 查询：
SELECT AVG(voltage) FROM power.smeter WHERE ts > now - 1h AND location = "chicago" INTERVAL(1m);从这两段查询的对比中，我们可以明显看出 TDengine 的 SQL查询更简洁、易读。
TDengine 对 SQL 的承诺
在经历了五十年的发展后，SQL 已被证明是最稳固的查询语言。自其诞生以来，就迅速成为了顶级数据库管理系统的查询语言，并且成为了数据库管理员和用户的重要工具。如今，可以毫不夸张地说，几乎所有与数据相关的人——从刚刚毕业、寻求第一份工作的数据科学专业毕业生，到在行业中耕耘数十年的资深专家——都具备一定的 SQL 使用经验。
而 TDengine 自发布之初就一直支持标准 SQL，并承诺将继续坚定地支持这一语言。未来，我们将继续扩展 SQL 的实现，而不会用任何其他查询语言来替代它。
在支持标准 SQL 的同时，TDengine 还在 SQL 语言上进行了针对时序数据处理特点的功能扩展，比如数据汇总、插值和时间加权平均等功能，这使得用户不仅能享受 SQL 的灵活性，也能应用到类似 InfluxQL 的专用功能。事实上，TDengine 中的几乎所有功能——如流处理、数据订阅、权限管理、集群管理等——都可以通过 SQL 语句来实现。
TDengine 对 SQL 的支持大大减少了新用户学习曲线的难度，任何曾经使用过其他 SQL 数据库的用户，都能轻松上手 TDengine。我们相信，SQL 是时序数据管理的最佳选择，我们也非常重视开发者的时间，绝不希望他们为了使用我们的产品而学习一门专门的语言。
此外，我们深知，稳定和长期的解决方案对任何工业数据基础设施都至关重要。客户希望能拥有一致的产品体验，而不是每隔几年就发生一次重大转型。许多用户发现，将现有的 InfluxDB 项目升级到 3.0 的工作量，几乎和迁移到另一个时序数据库产品相当。因此，我们诚邀这些用户尝试 TDengine 的开源版本（OSS）或 TDengine Cloud，亲自体验这一数据库产品如何轻松上手并快速部署。
