❶ 请教HIVE执行sql报错
历史上存在的原理，以前都是使用hive来构建数据仓库，所以存在大量对hive所管理的数据查询的需求。而hive、shark、sparlSQL都可以进行hive的数据查询。shark是使用了hive的sql语法解析器和优化器，修改了执行器，使之物理执行过程是跑在spark上；而sparkSQL是使用了自身的语法解析器、优化器和执行器，同时sparkSQL还扩展了接口，不单单支持hive数据的查询，可以进行多种数据源的数据查询。望采纳
❷ sql语法中 什么值需要用单引号‘’修饰
sql中对字符都是用单引号
只有在表名中比较特殊的
比如两个单词组成的表名
才使用双引号把表名括起来。'用来定界字串，"用来定界标识符。
你给出的例子中，正好是用两个单词组成的表名或列名。
❸ presto简介
MapRece不能满足大数据快速实时adhoc查询计算的性能要求，Facebook2012年开发，2013年开源
基于内存的并行计算，Facebook推出的分布式SQL交互式查询引擎 多个节点管道式执行
支持任意数据源 数据规模GB~PB 是一种Massively parallel processing（mpp）(大规模并行处理)模型
数据规模PB 不是把PB数据放到内存，只是在计算中拿出一部分放在内存、计算、抛出、再拿
多数据源、支持SQL、扩展性（可以自己扩展新的connector）、混合计算（同一种数据源的不同库 or表；将多个数据源的数据进行合并）、高性能、流水线（pipeline）
数据仓库 交互式略弱的查询引擎 只能访问HDFS文件 磁盘
但是presto是无法代替hive的
基于spark core mpp模式 详细课件spark sql一文
cube预计算
时序，数据放内存 索引 预计算
不适合多个大表的join操作，因为presto是基于内存的，太多数据内存放不下的
如果一个presto查询查过30分钟，那
就kill吧，说明不适合 也违背了presto的实时初衷
相当于MySQL的一个实例，
相当于MySQL的database
大内存、万兆网络、高计算能力
presto 查询引擎是一个Master-Slave的拓扑架构
中心的查询角色 接收查询请求、解析SQL 生成执行计划 任务调度 worker管理
coordinator进行是presto集群的master进程
执行任务的节点
presto以插件形式对数据存储层进行了抽象，它叫做连接器，不仅包含Hadoop相关组件的连接器还包括RDBMS连接器
具体访问哪个数据源是通过catalog 中的XXXX.properties文件中connector.name决定的
提取数据 负责实际执行查询计划
将coordinator和worker结合在一起服务；
worker节点启动后向discovery service服务注册
coordinator通过discovery service获取注册的worker节点
1、coordinator接到SQL后，通过SQL语法解析器把SQL语法解析变成一个抽象的语法树AST，只是进行语法解析如果有错误此环节暴露
2、语法符合SQL语法，会经过一个逻辑查询计划器组件，通过connector 查询metadata中schema 列名 列类型等，将之与抽象语法数对应起来，生成一个物理的语法树节点 如果有类型错误会在此步报错
3、如果通过，会得到一个逻辑的查询计划，将其分发到分布式的逻辑计划器里，进行分布式解析，最后转化为一个个task
4、在每个task里面，会将位置信息解析出来，交给执行的plan，由plan将task分给worker执行
1、如果某个worker挂了，discovery service 会通知coordinator
2、对于query是没有容错的，一旦worker挂了，query就执行失败了，与其在这里容错不如直接执行
3、coordinator 和discovery service 的单点故障问题还没有解决
❹ 组件分享之后端组件——基于Golang的SQL解析器sqlparser
近期正在探索前端、后端、系统端各类常用组件与工具，对其一些常见的组件进行再次整理一下，形成标准化组件专题，后续该专题将包含各类语言中的一些常用组件。欢迎大家进行持续关注。
本节我们分享一个基于Golang的SQL解析器 sqlparser
使用方式如下：
当不同的SQL错误，将返回特定的错误信息，具体可以查看其官方提供的 README
❺ 知道为什么SQL查询语句不能使用*吗 考验你们的小细节
作为运行效率来说的话， 有2种情况。
第一种情况， 是返回了太多没有用处的列，导致网络传输的数据过多。
* 要返回所有的列的信息。
如果你表的列很多， 又存在很多 二进制的数据类型的话。
例如有某个 安保系统， 有个 进出门的日志表。 这个门需要 2个人， 各刷一次卡，才能进入。
这个表包含下面的列：
自增流水、门口代码、日期时间、第一次刷卡的卡片代码，第二次刷卡的卡片代码，第一次刷卡的照片，第二次刷卡的照片，......其他列
现在发现可能有安全问题， 说昨天有东西丢了。
那么首先就是先
SELECT
日期时间、门口代码，第一次刷卡的卡片代码，第二次刷卡的卡片代码
FROM
表
WHERE
门口代码 = '那个丢东西房间的门'
AND 日期时间 > 昨天0点
先看看都哪些人刷卡了， 然后再去有重点地去查看那些 可能有问题的 刷卡记录的 照片信息。
否则你直接
SELECT
*
FROM
表
WHERE
门口代码 = '那个丢东西房间的门'
AND 日期时间 > 昨天0点
一次就会有太多的数据， 从服务器 传递到你的客户端。 而这些数据， 又可能是你用不上的。
第二种情况， 是如果检索的列都包含在索引里面了， 那么查询效率要快很多。
还是上面那个例子。
假如存在有这样的索引 （门口代码， 日期时间）
SELECT
日期时间、门口代码
FROM
表
WHERE
门口代码 = '那个丢东西房间的门'
AND 日期时间 > 昨天0点
这个查询， 连表都不需要查询了， 直接查询完索引， 就能返回了。
在 SQL Server 中， 可以通过 Include 来包含一个额外的数据到索引上面。
例如：
CREATE NONCLUSTERED INDEX idx_TestDoc
ON 表 (门口代码， 日期时间)
Include(第一次刷卡的卡片代码，第二次刷卡的卡片代码) ;
上面的索引创建完毕的话
SELECT
日期时间、门口代码，第一次刷卡的卡片代码，第二次刷卡的卡片代码
FROM
表
WHERE
门口代码 = '那个丢东西房间的门'
AND 日期时间 > 昨天0点
也不需要访问表了， 直接查询索引， 就能返回了。
这个情况，用 select * 嘛， 是不行的。就要先去访问好索引， 然后通过索引里面的 信息， 去表里面定位到具体的行数据， 最后再检索出来。
❻ spark SQL和hive到底什么关系
Hive是一种基于HDFS的数据仓库，并且提供了基于SQL模型的，针对存储了大数据的数据仓库，进行分布式交互查询的查询引擎。
SparkSQL并不能完全替代Hive，它替代的是Hive的查询引擎，SparkSQL由于其底层基于Spark自身的基于内存的特点，因此速度是Hive查询引擎的数倍以上，Spark本身是不提供存储的，所以不可能替代Hive作为数据仓库的这个功能。
SparkSQL相较于Hive的另外一个优点，是支持大量不同的数据源，包括hive、json、parquet、jdbc等等。SparkSQL由于身处Spark技术堆栈内，基于RDD来工作，因此可以与Spark的其他组件无缝整合使用，配合起来实现许多复杂的功能。比如SparkSQL支持可以直接针对hdfs文件执行sql语句。
❼ sharding-sphere之SQL解析select
以mysql为例，先看一下sql的写法: 官网地址： 请点击我
sql关联查询的格式如下:
结果集合并:
sql的解析过程如官方文档sql写法解析过程一直，流程图如下:
举个例子：以mysql的查询sql为例，看看语法解析器的解析过程:
sql语法解析器的解析过程，获取 MySQLSelectParser ，并解析。和上一篇 insert 都一致。
在 MySQLSelectParser 的解析过程中，首先会解析sql，归并子查询，组装返回的statement，具体过程参照文章上方图，按照官方sql写法，一步一步解析，最终解析完成。
接下来一个一个看看，到底分别都是如何解析的
如果sql中有distinct，或者distinctrow，则抛异常，不支持该语句
跳过HIGH_PRIORITY，STRAIGHT_JOIN，SQL_BIG_RESULT,SQL_SMALL_RESULT,SQL_BIG_RESULT,SQL_BUFFER_RESULT,SQL_CACHE,SQL_NO_CACHE,SQL_CALC_FOUND_ROWS关键字。
选项之间 , 隔开，直到解析最后一个分词不是,结束，循坏处理。
在解释分词的时候，跳过其他的关键字，然后判断是否是 * ,或者 MAX,MIN,SUM,AVG,COUNT 函数，或者是普通返回字段，按照不同格式解析。
解析带 * 的语句逻辑，个人理解，组装StarSelectItem即可，有些逻辑不太了解，后续再更。
处理MAX,MIN,SUM,AVG,COUNT函数的逻辑如下：
根据.，()做不同的处理逻辑，解析别名，返回分词组装SelectItem。
再具体解析时，首先会获取第一分词，然后看下一个分词是不是 . ,如果是 . ，则第一分词是schema的名称，下一分词为表名称，不然第一分词是表名称。
在解析join语句时，首先判断是否是join子查询，如果是，则不支持。
在判断join结束的时候，实质是跳过 on 分词，解析on table1.a=table2.b这样的语句，分析前一个表达式和第二个表达式。
表关联结束之后，整个from语句就解析完成了，接下来的就是where语句了。
按照,分割，一个一个解析处理
不支持UNION，INTERSECT，MINUS，EXCEPT
以一下sql为例：
解析结果如图：
fyi
❽ Python/PHP MySQL语句解析器解决业务分表
自己曾经做过一个网盘项目。刚开始由于需要快速地从0到1建设上线，所以没有对核心文档表进行分表。当然我的架构理念也是“按需架构设计”。产品需求在没有明确的长远计划的情况下以“小步快跑，赶超竞品”为主。后期由于产品功能触达目标用户群需求点、产品用户体验不断提升、产品多方位导流、加强产品推广文档表每天有百万数据增长量。不得不对文档表进行按用户id分表。当时产品功能已全覆盖文档的生命周期。产品功能已丰富多彩。修改所有关联文档表的业务代码为按用户id分表开发测试成本非常高。上线后线上问题不可控。经过考虑在业务代码最底层DB层进行SQL语句解析来进行用户id分表处理。这样的话开发测试成本都非常低。上线后有问题方便回滚和追查原因。
今天为大家介绍Python/PHP两种MySQL语句解析器。当时网盘项目用的是PHP编程语言开发。
Python的SQL语句解析器 。个人推荐使用moz_sql_parser库。经调研官方的sqlparse库解析出来的语句段无法满足需求也很难理解。
1、Python moz_sql_parser库安装
2、Python moz_sql_parser SQL语句解析
3、Python moz_sql_parser总结
PHP的SQL语句解析器。 个人推荐使用PhpMyAdmin的sql-parser组件。PhpMyAdmin是经过 历史 检验可信赖的。
1、PHP PhpMyAdmin/sql-parser安装
2、PHP PhpMyAdmin/sql-parser SQL语句解析
3、PHP PhpMyAdmin/sql-parser总结
大家有什么问题可以发评论沟通。
❾ MySql中Sql的执行过程
如果查询缓存没有命中，那么SQL请求会进入分析器，分析器是用来分辨SQL语句的执行目的，其执行过程大致分为两步：
表1 语法分析关键字然后再通过语法规则解析，判断输入的SQL 语句是否满足MySQL语法，并且生成图5的语法树。由SQL语句生成的四个单词中，识别出两个关键字，分别是select 和from。根据MySQL的语法Select 和 from之间对应的是fields 字段，下面应该挂接username；在from后面跟随的是Tables字段，其下挂接的是userinfo。
优化器的作用是对SQL进行优化，生成最有的执行方案。如图6所示，前面提到的SQL解析器通过语法分析和语法规则生成了SQL语法树。这个语法树作为优化器的输入，而优化器（黄色的部分）包含了逻辑变换和代价优化两部分的内容。在优化完成以后会生成SQL执行计划作为整个优化过程的输出，交给执行器在存储引擎上执行。
所处的位置如上图所示，这节的重点在优化器中的逻辑变换和代价优化上。
逻辑变换也就是在关系代数基础上进行变换，其目的是为了化简，同时保证SQL变化前后的结果一致，也就是逻辑变化并不会带来结果集的变化。其主要包括以下几个方面：
这样讲概念或许有些抽象，通过图7 来看看逻辑变化如何在SQL中执行的吧。
如图7所示，从上往下共有4个步骤：
1. 针对存在的SQL语句，首先通过“否定消除”，去掉条件判断中的“NOT”。语句由原来的“or”转换成“and”，并且大于小于符号进行变号。蓝色部分为修改前的SQL，红色是修改以后的SQL。2. 等值传递，这一步很好理解分别降”t2.a=9” 和”t2.b=5”分别替换掉SQL中对应的值。3. 接下来就是常量表达式计算，将“5+7”计算得到“12”。4. 最后是常量表达式计算后的化简，将”9<=10”化简为”true”带入到最终的SQL表达式中完成优化。
代价优化是用来确定每个表，根据条件是否应用索引，应用哪个索引和确定多表连接的顺序等问题。为了完成代价优化，需要找到一个代价最小的方案。因此，优化器是通过基于代价的计算方法来决定如何执行查询的（Cost-based Optimization）。简化的过程如下：
这里将配置操作的代价分为MySQL 服务层和MySQL 引擎层，MySQL 服务层主要是定义CPU的代价，而MySQL 引擎层主要定义IO代价。MySQL 5.7 引入了两个系统表mysql.server_cost和mysql.engine_cost来分别配置这两个层的代价。如下：MySQL 服务层代价保存在表server_cost中，其具体内容如下：
由上可以看出创建临时表的代价是很高的，尤其是内部的myisam或innodb临时表。MySQL 引擎层代价保存在表engine_cost中，其具体内容如下：
目前io_block_read_cost和memory_block_read_cost默认值均为1，实际生产中建议酌情调大memory_block_read_cost，特别是对普通硬盘的场景。MySQL会根据SQL查询生成的查询计划中对应的操作从上面两张代价表中查找对应的代价值，并且进行累加形成最终执行SQL计划的代价。再将多种可能的执行计划进行比较，选取最小代价的计划执行。
当分析器生成查询计划，并且经过优化器以后，就到了执行器。执行器会选择执行计划开始执行，但在执行之前会校验请求用户是否拥有查询的权限，如果没有权限，就会返回错误信息，否则将会去调用MySQL引擎层的接口，执行对应的SQL语句并且返回结果。例如SQL：“SELECT * FROM userinfo WHERE username = 'Tom';“假设 “username“ 字段没有设置索引，就会调用存储引擎从第一条开始查，如果碰到了用户名字是” Tom“， 就将结果集返回，没有查找到就查看下一行，重复上一步的操作，直到读完整个表或者找到对应的记录。需要注意SQL语句的执行顺序并不是按照书写顺序来的，顺序的定义会在分析器中做好，一般是按照如下顺序：
如果命中的记录比较多，应用会从MySql Server一批批获取数据
本文从MySQL中SQL语句的执行过程作为切入点，首先介绍了查询请求的执行流程，其中将MySQL的处理分为MySQL Server层和MySQL存储引擎层。通过介绍SQL语句的流转，引出了后面要介绍的5大组件，他们分别是：连接器、查询缓存、分析器、优化器、执行器。后面的内容中对每个组件进行了详细的介绍。连接器，负责身份认证和权限鉴别；查询缓存，将查询的结果集进行缓存，提高查询效率；分析器，对SQL语句执行语法分析和语法规则，生成语法树和执行计划；优化器，包括逻辑变换和代价优化；执行器，在检查用户权限以后对数据进行逐条查询，整个过程遵守SQL语句的执行顺序。