postgresql如何解析一条SQL语句

词法分析：SELECTFROMtable→解析成Token序列。
语法分析：AST 构造，括号不匹配 → 报告错误。
语义分析：SELECTcolumn_non_existent → 错误。
查询重写：视图扩展、外连接和内连接。
查询优化：路径选择（索引抓取）、成本估算（统计信息）。
执行计划：顺序扫描+哈希连接。
执行：访问堆表，返回结果集。

解释查看计划，分析更新统计数据。
请记住：统计数据是优化的关键。

大数据=SQL Boy,SQL Debug打破SQL Boy 的僵局

粗略地说，SQLDebug就是在SQL中添加“断点”，以查看每个阶段数据如何变化。
这个技巧对于复杂的 SQL 来说绝对是完美的（比如我们去年运行的 3 000 级嵌套 Union 查询）。
我们先来说说最重要的事情。
首先需要在Hive中使用hive.root.logger=DEBUG和控制台操作来最大化日志。
还有一点是需要使用Calcite这样的工具将SQL变成可视化的语法树。
否则，阅读代码就像阅读圣经一样。
还有一个关键细节。
比如把SQL分成三部分，给每一部分添加一个flag字段，比如selectfrom(selectid,name,'1 'asflag...这样就可以直接判断数据是从哪一部分来的，说实话，挺混乱的。
我一开始以为只看执行计划就够了，后来发现这是错误的。
一些奇怪的不正确的执行计划根本看不出来。
直接建临时表来存储中间结果是最残酷的方法，但事实并非如此。
确实，例如将 Union 拆分为三个 temp_table1 /2 /3 ，然后直接使用 selectfromtemp_table2 whereflag='2 ' 进行测试，这比运行整个 SQL 快 1 00 倍以上。
等等，还有一点：不要忘记使用脚本来自动删除临时表，否则建议尝试使用 DataCompare 自动比较结果与预期的结果不同。
数据下降5 %以上，问题就可以得到实际解决。