这有效:
SELECT * FROM users ORDER BY id LIMIT 5
这不会 - 引发语法错误:
SELECT * FROM users LIMIT 5 ORDER BY id
SQL 似乎对子句顺序过于严格。
这么严格有充分的理由吗?
PS SELECT 和 FROM 指定数据的来源,我同意这应该在查询中具有特定的位置。但是,其他子句只是“玩”该数据-它们与数据源有关系,但彼此之间没有关系,因此应该以特定方式对它们进行排序的事实对我来说似乎不是很直观.
这有效:
SELECT * FROM users ORDER BY id LIMIT 5
这不会 - 引发语法错误:
SELECT * FROM users LIMIT 5 ORDER BY id
SQL 似乎对子句顺序过于严格。
这么严格有充分的理由吗?
PS SELECT 和 FROM 指定数据的来源,我同意这应该在查询中具有特定的位置。但是,其他子句只是“玩”该数据-它们与数据源有关系,但彼此之间没有关系,因此应该以特定方式对它们进行排序的事实对我来说似乎不是很直观.
Hugh Darwen 的理论认为,在 1960 年代语言采用这种方式是一种时尚:
您是否认为 SELECT-FROM-WHERE 是理所当然的,或者您是否像我一样对 System R 团队应该摒弃编写任意复杂性表达式的常规方式而转而支持完全特殊的东西感到好奇,有人可能会说,相当独裁……?
事实是,在 1960 年代,各种脚本语言(我们现在倾向于这样称呼)已经出现用于报告生成,尤其是临时报告生成。我们在 1969-77 年间为 IBM 工作的称为终端业务系统 (TBS) 的前关系 DBMS 中有一种这样的语言。我们的语言要求用户在一系列步骤中指定所需的报告,这些步骤必须按规定的顺序给出......
一个有点相似但更复杂的报告生成器后来由美国的 IBM 开发,作为一个产品的一部分(平淡无奇,就像当时 IBM 的风格一样)通用信息系统(GIS)......当我第一次看到 SQL ,我的第一反应是“哦,不!GIS 的儿子?请不要那样做!” 我可能在这件事上完全错了。我所感知的相似性可能是虚幻的,即使不是,我也没有确凿的证据表明 System R 团队中的任何人都熟悉 GIS。事实仍然是,固定行动顺序的一般风格是当时的主流。我假设 SQL 的 SELECT-FROM-WHERE 就是以这种方式出现的。
当你用英语或其他语言写作时,你也会使用特定的语法。您永远不会将动词放在英语句子的末尾,但它在德语中使用。
在 SQL 中,您必须遵守同样的语法。
你也不会写这样的查询FROM user SELECT * ORDER BY xy WHERE a=b
因为这是 MySQL 的语法: http ://dev.mysql.com/doc/refman/5.0/en/select.html
解析器是为速度而构建的。如果您允许不一致的语法,解析器将花费更多时间来确定需要做什么。这会对性能产生重大影响。
此外,它使人类更容易阅读。
除了 LIMIT(例如 SQL Server 中的 TOP)之外,还有一个反映语法顺序的 SQL 语句的逻辑处理 ORDER
如果你用 TOP 代替 LIMIT 那就很明显了
首先,让我告诉你
“每种语言都有自己的一套规则和规定”
我们需要遵守这个规则。违反任何命令的任何类型的规则(例如语法)都会导致我们出错。
使用该ORDER BY子句指定评估规则左侧单元格的顺序。expr 必须解析为维度或度量列。如果ORDER BY未指定子句,则顺序默认为DIMENSION BY子句中指定的列顺序。
在这里查看更多信息: