如果公司要删除一位用户的敏感信息，只找到最初存放它的那张表还不够。这个字段可能被改名、拼接、计算，又流进报表和其他数据库对象。漏掉任何一处，删除就不完整。sqlleaf 想做的，就是沿着 SQL 留下的线索，把这条流动路径画到每一个字段。
项目目前只有作者在 Reddit 上的自述，尚无独立评测或公开用户案例。下面的能力和覆盖范围，均应按作者宣称理解。
不只看表，还要追到每一列
数据血缘（Data Lineage）记录数据从哪里来、经过哪些转换、最后去了哪里。传统的表级血缘可能只告诉你：表 A 生成了表 B。字段级血缘（Column-Level Lineage）则继续下钻：表 B 的某一列，究竟来自表 A 的哪几列，又经过了什么计算。
例如，一列结果可能由姓名字段、某个函数和固定字面量共同组成。按作者说法，sqlleaf 不只连接输入列与输出列，还会记录列、函数、字面量和变量等表达式之间的关系。这让血缘图不只是粗略的表间连线，而更接近数据实际流动和变形的过程。
这种粒度直接关系到两类工作。第一类是敏感数据清理：团队需要知道一项信息被复制或加工到了哪里。第二类是影响分析：修改某个字段或计算口径前，先找出可能受影响的下游结果。作者称，sqlleaf 正是源于其所在企业追踪并删除大型数据仓库中敏感数据的实际需求；但企业名称、仓库规模和实施成效都没有披露。
“跨方言”难在哪里？
不同数据库都使用 SQL，但函数、类型、引号和特殊语法并不完全一样，这些差异通常称为 SQL 方言。跨方言工具需要先理解不同写法，再把它们转换成可统一分析的内部结构。
sqlleaf 构建在 SQL 转译工具 sqlglot 之上。作者因此宣称，它继承了 sqlglot 对 30 多种 SQL 方言的支持。但这不等于 sqlleaf 已经能完整处理每种方言的所有语法。作者同时承认，各方言的特有功能很多，仍有大量部分需要实现，并称项目“还有很长的路要走”。所以标题里的 “any SQL dialect” 更适合看作工程目标，而不是已经得到验证的完整覆盖。
它想处理的不只是查询
作者列出的范围很宽：sqlleaf 可分析 insert、update、merge、copy、unload、execute、perform、put 等语句，也涉及表、视图、存储过程、类型、用户自定义函数（UDF）、stage 和 sequence 等对象。
它还包含 PL/pgSQL 解析器。PL/pgSQL 是 PostgreSQL 的过程式语言，可以加入变量、流程控制和动态生成的 SQL。普通静态 SQL 分析是在不运行查询的情况下，根据语句结构推导依赖；遇到运行时才拼出的查询和存储过程，完整还原通常更难。sqlleaf 将这部分纳入目标范围，因此值得关注。不过，现有材料没有给出具体语法覆盖、准确率或测试结果。
为什么值得继续看
字段级血缘并不是一张为了好看的关系图。它可以成为敏感信息清理、改表影响评估、校验、审计和追踪系统的基础设施。sqlleaf 的价值主张，在于试图把跨方言解析、更多 SQL 语句和过程式代码放进同一个血缘模型。项目代码已在 GitHub 公开。
真正需要观察的，不是它列出了多少方言和对象，而是面对真实仓库里的复杂语法时，能否稳定、准确地还原字段流向。
局限与未知
- 目前所有能力描述都来自项目作者，缺少第三方评测和可核验案例。
- 材料未披露版本号、方言覆盖率、血缘准确率、性能数据或测试结果。
- “支持 30+ 方言”来自底层 sqlglot 的覆盖范围，不能视为 sqlleaf 对这些方言都已具备完整的字段级血缘能力。