关键字小写的 SQL 格式化工具
SQL 格式化工具 的预设方案
格式化查询语句的同时让关键字保持小写。大写关键字是较早的惯例,源自编辑器还没有语法高亮的年代;许多现代风格指南现在更倾向于全程小写。
- 文件永不离开你的设备
- 免费，无需注册
- 无水印
- 加载后可离线使用
如何SQL 格式化工具
- 1
粘贴你的查询语句
一整行密集的,或者已经半格式化过的都可以。
- 2
设置你的偏好
缩进大小,以及关键字是否要大写。
- 3
复制结果
可以直接粘贴回你的编辑器或迁移脚本里。
为什么大写关键字最初会成为一种惯例
把 SQL 关键字大写这个做法,可以追溯到代码编辑器完全没有语法高亮的年代,那时要把 `SELECT` 和 `WHERE` 从周围的表名、列名中视觉上区分出来,只能靠手动用不同的大小写来输入——这是在替代一个现代编辑器现在会自动提供的颜色区分功能。如今几乎每一个主流编辑器和 IDE 都会按颜色高亮 SQL 关键字,不管它们是怎么输入的,那个最初的理由在很大程度上已经不复存在,不少现代风格指南也已经转向推荐全程使用小写,理由更简单:打字更快,写查询时也不需要在大小写之间切换思路。
匹配某个特定团队或项目已经确定的风格
关键字该用哪种大小写惯例,归根结底取决于一个项目现有的代码库或团队风格指南已经在用什么,而不是某种客观上正确的选择——查询实际的执行行为无论哪种写法都完全一样。这个预设正是为那些已经确定使用小写的团队和个人准备的,让格式化后的查询匹配周围代码库的主流风格,而不是在一个其他查询都是小写的文件里引入一条大小写格格不入的查询。
一致性比哪种惯例胜出更重要
同一个代码库里关键字大小写混用的实际代价不是技术层面的——SQL 根本不在乎——而是审阅者的注意力每次读到一处不一致时都会被勾住的那种细小、累积的摩擦,在一个团队每周审阅几十条查询的规模下会累积起来。选定一种惯例,无论是小写还是大写,并一致地应用它,才是真正带来可读性收益的做法;这个预设让小写成为机械式的默认选项,这样就没有人需要手动重新输入关键字去匹配团队选定的风格。
常见问题
会改变我的查询实际执行的逻辑吗?
不会。只有空白和关键字的大小写会改变——没有任何子句被重新排序,也没有任何标记被重写。SQL 关键字本身是不区分大小写的,所以把它们大写不可能改变行为。
引号里面的文字会怎样?
会被原样保留。这个格式化工具在触碰任何内容之前会先对查询语句做分词,所以像 'check the order from stock' 这样的字符串会保留它原本小写的 "order" 和 "from",而不会被当成关键字大写。基于正则表达式的格式化工具经常在这一点上出错。
支持哪些 SQL 方言?
PostgreSQL、MySQL、SQL Server、SQLite 和 Oracle 共有的常见子句结构。它是做格式化而不是做解析,所以特定方言的语法会原样通过而不会报错——但也不会得到特别的缩进处理。
我的查询语句会被发送到别处吗?
不会。格式化在你的浏览器中进行。这一点很重要,因为真实的查询语句往往携带表名、列名,有时甚至是字面意义上的客户数据——这些都不该被粘贴进一个陌生的服务器。