❶ 請教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語句的執行順序。