人工智慧自動SQL優化出現在90年代末。目前在商用資料庫領域，LECCO Technology Limited(靈高科研有限公司)擁有該技術，並提供使用該技術的自動優化產品LECCO SQL Expert，它支持Oracle、Sybase、MS SQL Server和IBM DB2資料庫平台。該產品針對資料庫應用的開發和維護階段提供的模塊有：SQL語法優化器、PL/SQL集成化開發調試環境(IDE)、掃描器、資料庫監視器等。其核心模塊SQL 語法優化器的工作原理為：①輸入一條源SQL語句；②「人工智慧反饋式搜索引擎」對輸入的SQL語句，結合檢測到的資料庫結構和索引進行重寫，產生N條等效的SQL語句輸出；③產生的N條等效SQL語句再送入「人工智慧反饋式搜索引擎」進行重寫，直至無法產生新的輸出或搜索限額滿；④對輸出的SQL語句進行過濾，選出具有不同執行計劃的SQL語句；⑤對得到的SQL語句進行批量測試，找出性能最好的SQL語句。
㈡ mysql能用來直接做哪些人工智慧演算法,寫sql
人工智慧帶不帶學習能力？如果正常的人工智慧，就幾個IF，幾個隨機數可以搞掂了。如果要帶學習能力，就必須再判斷條件中，增加返回值，順序校驗演算法，insert機制等。
㈢ 2020-10-11：一條sql語句執行時間過長，應該如何優化從哪些方面進行優化
改進資料庫sql語句進行優化的理由 應用程序之優化通常可分為兩個方面：源代碼之優化和sql語句之優化。源代碼之優化在時間成本和風險上代價很高；另一方面，源代碼之優化對資料庫系統性能之提升收效有限。 優化之理由 1)sql語句是對資料庫(數據)進行操作之惟一途徑； 2)sql語句消耗了70%~90%之資料庫資源； 3)sql語句獨立於程序設計邏輯，相對於對程序源代碼之優化，對sql語句之優化在時間成本和風險上之代價都很低； 4)sql語句可以有不同之寫法； 5)sql語句易學，難精通。 優化技術之發展 第一代之sql優化工具是執行計劃分析工具。這類之工具對輸入之sql語句從資料庫提取執行計劃，並解釋執行計劃中關鍵字之含義；第二代之sql優化工具只能提供增加索引之建議，它通過對輸入之sql語句之執行計劃之分析來產生是否要增加索引之建議。該類工具存在著致命之缺點——只分析了一條sql語句就得出增加某個索引之結論，根本不理會(實際上也無法評估到)增加之索引對整體資料庫系統性能之影響。其破壞性在於： 1、不理會增加之索引對其他增、刪、改sql語句之負面影響； 2、沒有考慮增加之索引可能導致資料庫判斷失誤； 3、對由於增加索引引起之資料庫系統負擔忽略不計。 同時，這些工具由於技術水平之限制存在著以下缺點： 1、無法保證建議或改寫之正確性； 2、無法進行重寫，僅僅提供了建議或有限程度之改寫，重寫工作還是需要人工完成，優化工作所需之時間和工作量同人工進行優化差不多； 3、改寫之規則和hints有限，難以處理復雜之sql語句； 4、必須人手逐條進行測試。 這類工具曾經盛極一時，直到人工智慧自動sql優化之出現。
㈣ SQL資料庫的應用領域、現狀、發展前景
SQL資料庫是具有數據操縱和數據定義等多種功能的資料庫語言，這種語言具有交互性特點，能為用戶提供極大的便利，資料庫管理系統應充分利用SQL語言提高計算機應用系統的工作質量與效率。
一、SQL資料庫的應用領域
1、多媒體資料庫
這種資料庫主要存儲與多媒體有關的數據，如語音、圖像和視頻數據。多媒體數據最大的特點是數據連續、數據量大、存儲空間大。
2、移動資料庫
這種資料庫是在筆記本電腦、掌上電腦等移動計算機系統上開發的。資料庫的最大特點是通過無線數字通信網路傳輸。移動資料庫可以隨時隨地獲取和訪問數據，為一些業務應用和一些突發事件帶來了極大的便利。
3、空間資料庫
目前，這種資料庫發展迅速。它主要包括地理信息資料庫（也稱為GIS）和計算機輔助設計（CAD）資料庫。其中，地理信息資料庫一般存儲與地圖相關的信息數據；CAD資料庫一般存儲機械、集成電路、電子設備設計圖紙等設計信息的空間資料庫。
4、信息檢索系統
信息檢索是根據用戶輸入的信息從資料庫中查找相關文檔或信息，並將信息反饋給用戶。信息檢索領域與資料庫領域同步發展。它是一個典型的聯機文檔管理系統或聯機圖書目錄。
5、分布式信息檢索
這種資料庫是隨著Internet的發展而產生的。它廣泛應用於Internet和遠程計算機網路系統中。特別是隨著電子商務的發展，這種資料庫的發展更為迅速。許多網路用戶（如個人、公司或企業等）將信息存儲在自己的計算機中。
6、專家決策系統
專家決策系統也是資料庫應用的一部分。因為越來越多的數據可以在網上獲得，特別是通過這些數據，企業可以對企業的發展做出更好的決策，從而使企業能夠更好地經營。隨著人工智慧的發展，專家決策系統的應用越來越廣泛。
二、SQL資料庫現狀
1、自主研發
國內自主研發關系型資料庫的企業、單位基本上都是發源於上世紀90年代的，而且都是以大學、科研機構為主。到今天，有代表性的廠商有：達夢–由華中理工馮玉才教授創辦，完全自主研發。以Oracle為參照、追趕對象。
2、引進源代碼
引進資料庫源代碼發展國產資料庫，如今，經濟發展，而且IBM也願意迎合國人對於國產化的訴求，將擱置多年的Informix源代碼拿出來，發揮余熱。2015年以來，與IBM簽訂源代碼授權的公司有華勝天成、南大通用（Gbase8t）和星瑞格。這三個公司成為以引進Informix源代碼發展國產資料庫的代表。
三、SQL資料庫發展前景
1、產品形成系列化
一方面，Web和數據倉庫等應用的興起，數據的絕對量在以驚人的速度迅速膨脹；另一方面，移動和嵌入式應用快速增長。針對市場的不同需求，資料庫正在朝系列化方向發展。
2、智能化集成化
SQL資料庫技術的廣泛使用為企業和組織收集並積累了大量的數據。數據豐富知識貧乏的現實直接導致了聯機分析處理（OLAP）和數據挖掘（DataMining）等技術的出現，促使資料庫向智能化方向發展。
3、支持各種互聯網應用
SQL資料庫管理系統是網路經濟的重要基礎設施之一。支持Internet（甚至於MobileInternet）資料庫應用已經成為資料庫系統的重要方面。例如，Oracle公司從8版起全面支持互聯網應用，是互聯網資料庫的代表。
(4)人工智慧sql優化擴展閱讀：
SQL包括了所有對資料庫的操作，主要是由4個部分組成：
1、數據定義：又稱為「DDL語言」，定義資料庫的邏輯結構，包括定義資料庫、基本表、視圖和索引4部分。
2、數據操縱：又稱為「DML語言」，包括插入、刪除和更新三種操作。
3、數據查詢：又稱為「DQL語言」，包括數據查詢操作。
4、數據控制：又稱為「DCL語言」，對用戶訪問數據的控制有基本表和視圖的授權及回收。
5、事務控制：又稱為「TCL語言」，包括事務的提交與回滾。
參考資料來源：網路-SQL資料庫
㈤ 技術干貨：SQL on Hadoop在快手大數據平台的實踐與優化
快手大數據架構工程師鍾靚近日在 A2M 人工智慧與機器學習創新峰會分享了題為《SQL on Hadoop 在快手大數據平台的實踐與優化》的演講，主要從 SQL on Hadoop 介紹、快手 SQL on Hadoop 平台概述、SQL on Hadoop 在快手的使用經驗和改進分析、快手 SQL on Hadoop 的未來計劃四方面介紹了 SQL on Hadoop 架構。
SQL on Hadoop，顧名思義它是基於 Hadoop 生態的一個 SQL 引擎架構，我們其實常常聽到 Hive、SparkSQL、Presto、Impala 架構。接下來，我會簡單的描述一下常用的架構情況。
HIVE，一個數據倉庫系統。它將數據結構映射到存儲的數據中，通過 SQL 對大規模的分布式存儲數據進行讀、寫、管理。
根據定義的數據模式，以及輸出 Storage，它會對輸入的 SQL 經過編譯、優化，生成對應引擎的任務，然後調度執行生成的任務。
HIVE 當前支持的引擎類型有：MR、SPARK、TEZ。
基於 HIVE 本身的架構，還有一些額外的服務提供方式，比如 HiveServer2 與 MetaStoreServer 都是 Thrift 架構。
此外，HiveServer2 提供遠程客戶端提交 SQL 任務的功能，MetaStoreServer 則提供遠程客戶端操作元數據的功能。
Spark，一個快速、易用，以 DAG 作為執行模式的大規模數據處理的統一分析引擎，主要模塊分為 SQL 引擎、流式處理 、機器學習、圖處理。
SPARKSQL 基於 SPARK 的計算引擎，做到了統一數據訪問，集成 Hive，支持標准 JDBC 連接。SPARKSQL 常用於數據交互分析的場景。
SPARKSQL 的主要執行邏輯，首先是將 SQL 解析為語法樹，然後語義分析生成邏輯執行計劃，接著與元數據交互，進行邏輯執行計劃的優化，最後，將邏輯執行翻譯為物理執行計劃，即 RDD lineage，並執行任務。
PRESTO，一個互動式分析查詢的開源分布式 SQL 查詢引擎。
因為基於內存計算，PRESTO 的計算性能大於有大量 IO 操作的 MR 和 SPARK 引擎。它有易於彈性擴展，支持可插拔連接的特點。
業內的使用案例很多，包括 FaceBook、AirBnb、美團等都有大規模的使用。
我們看到這么多的 SQL on Hadoop 架構，它側面地說明了這種架構比較實用且成熟。利用 SQL on Hadoop 架構，我們可以實現支持海量數據處理的需求。
查詢平台每日 SQL 總量在 70 萬左右，DQL 的總量在 18 萬左右。AdHoc 集群主要用於交互分析及機器查詢，DQL 平均耗時為 300s；AdHoc 在內部有 Loacl 任務及加速引擎應用，所以查詢要求耗時較低。
ETL 集群主要用於 ETL 處理以及報表的生成。DQL 平均耗時為 1000s，DQL P50 耗時為 100s，DQL P90 耗時為 4000s，除上述兩大集群外，其它小的集群主要用於提供給單獨的業務來使用。
服務層是對上層進行應用的。在上層有四個模塊，這其中包括同步服務、ETL 平台、AdHoc 平台以及用戶程序。在調度上層，同樣也有四方面的數據，例如服務端日誌，對它進行處理後，它會直接接入到 HDFS 里，我們後續會再對它進行清洗處理；服務打點的數據以及資料庫信息，則會通過同步服務入到對應的數據源里，且我們會將元數據信息存在後端元數據系統中。
網頁爬取的數據會存入 hbase，後續也會進行清洗與處理。
HUE、NoteBook 主要提供的是互動式查詢的系統。報表系統、BI 系統主要是 ETL 處理以及常見的報表生成，額外的元數據系統是對外進行服務的。快手現在的引擎支持 MR、Presto 及 Spark。
管理系統主要用於管理我們當前的集群。HiveServer2 集群路由系統，主要用於引擎的選擇。監控系統以及運維系統，主要是對於 HiveServer2 引擎進行運維。
我們在使用 HiveServer2 過程中，遇到過很多問題。接下來，我會詳細的為大家闡述快手是如何進行優化及實踐的。
當前有多個 HiveServer2 集群，分別是 AdHoc 與 ETL 兩大集群，以及其他小集群。不同集群有對應的連接 ZK，客戶端可通過 ZK 連接 HiveServer2 集群。
為了保證核心任務的穩定性，將 ETL 集群進行了分級，分為核心集群和一般集群。在客戶端連接 HS2 的時候，我們會對任務優先順序判定，高優先順序的任務會被路由到核心集群，低優先順序的任務會被路由到一般集群。
BeaconServer 服務為後端 Hook Server 服務，配合 HS2 中的 Hook，在 HS2 服務之外實現了所需的功能。當前支持的模塊包括路由、審計、SQL 重寫、任務控制、錯誤分析、優化建議等。
•無狀態，BeaconServer 服務支持水平擴展。基於請求量的大小，可彈性調整服務的規模。
•配置動態載入，BeaconServer 服務支持動態配置載入。各個模塊支持開關，服務可動態載入配置實現上下線。比如路由模塊，可根據後端加速引擎集群資源情況，進行路由比率調整甚至熔斷。
•無縫升級，BeaconServer 服務的後端模塊可單獨進行下線升級操作，不會影響 Hook 端 HS2 服務。
•Hive 支持 SPARK 與 TEZ 引擎，但不適用於生產環境。
•SQL on Hadoop 的 SQL 引擎各有優缺點，用戶學習和使用的門檻較高。
•不同 SQL 引擎之間的語法和功能支持上存在差異，需要大量的測試和兼容工作，完全兼容的成本較高。
•不同 SQL 引擎各自提供服務會給數倉的血緣管理、許可權控制、運維管理、資源利用都帶來不便。
•在 Hive 中，自定義實現引擎。
•自動路由功能，不需要設置引擎，自動選擇適合的加速引擎。
•根絕規則匹配 SQL，只將兼容的 SQL 推給加速引擎。
•復用 HiveServer2 集群架構。
基於 HiveServer2，有兩種實現方式。JDBC 方式是通過 JDBC 介面，將 SQL 發送至後端加速引擎啟動的集群上。PROXY 方式是將 SQL 下推給本地的加速引擎啟動的 Client。
JDBC 方式啟動的後端集群，均是基於 YARN，可以實現資源的分時復用。比如 AdHoc 集群的資源在夜間會自動回收，作為報表系統的資源進行復用。
路由方案基於 HS2 的 Hook 架構，在 HS2 端實現對應 Hook，用於引擎切換；後端 BeaconServer 服務中實現路由 服務，用於 SQL 的路由規則的匹配處理。不同集群可配置不同的路由規則。
為了保證後算路由服務的穩定性，團隊還設計了 Rewrite Hook，用於重寫 AdHoc 集群中的 SQL，自動添加 LIMIT 上限，防止大數據量的 SCAN。
•易於集成，當前主流的 SQL 引擎都可以方便的實現 JDBC 與 PROXY 方式。再通過配置，能簡單的集成新的查詢引擎，比如 impala、drill 等。
•自動選擇引擎，減少了用戶的引擎使用成本，同時也讓遷移變得更簡單。並且在加速引擎過載 的情況下，可以動態調整比例，防止因過載 對加速性能的影響。
•自動降級，保證了運行的可靠性。SQL 路由支持 failback 模塊，可以根據配置選擇是否再路由引擎執行失敗後，回滾到 MR 運行。
•模塊復用，對於新增的引擎，都可以復用 HiveServer2 定製的血緣採集、許可權認證、並發鎖控制等方案，大大降低了使用成本。
•資源復用，對於 adhoc 查詢佔用資源可以分時動態調整，有效保證集群資源的利用率。
當查詢完成後，本地會輪詢結果文件，一直獲取到 LIMIT 大小，然後返回。這種情況下，當有大量的小文件存在，而大文件在後端的時候，會導致 Bad Case，不停與 HDFS 交互，獲取文件信息以及文件數據，大大拉長運行時間。
在 Fetch 之前，對結果文件的大小進行預排序，可以有數百倍的性能提升。
示例：當前有 200 個文件。199 個小文件一條記錄 a，1 個大文件混合記錄 a 與 test 共 200 條，大文件名 index 在小文件之後。
Hive 中有一個 SimpleFetchOptimizer 優化器，會直接生成 FetchTask，減小資源申請時間與調度時間。但這個優化會出現瓶頸。如果數據量小，但是文件數多，需要返回的條數多，存在能大量篩掉結果數據的 Filter 條件。這時候串列讀取輸入文件，導致查詢延遲大，反而沒起到加速效果。
在 SimpleFetchOptimizer 優化器中，新增文件數的判斷條件，最後將任務提交到集群環境，通過提高並發來實現加速。
示例：讀取當前 500 個文件的分區。優化後的文件數閾值為 100。
一個表有大量的子分區，它的 DESC 過程會與元數據交互，獲取所有的分區。但最後返回的結果，只有跟表相關的信息。
與元數據交互的時候，延遲了整個 DESC 的查詢，當元數據壓力大的時候甚至無法返回結果。
針對於 TABLE 的 DESC 過程，直接去掉了跟元數據交互獲取分區的過程，加速時間跟子分區數量成正比。
示例：desc 十萬分區的大表。
•復用 split 計算的數據，跳過 rece 估算重復統計輸入過程。輸入數據量大的任務，調度速率提升 50%。
•parquetSerde init 加速，跳過同一表的重復列剪枝優化，防止 map task op init 時間超時。
•新增 LazyOutputFormat，有 record 輸出再創建文件，避免空文件的產生，導致下游讀取大量空文件消耗時間。
•statsTask 支持多線程聚合統計信息，防止中間文件過多導致聚合過慢，增大運行時間。
•AdHoc 需要打開並行編譯，防止 SQL 串列編譯導致整體延遲時間增大的問題。
HS2 啟動時會對物化視圖功能進行初始化，輪詢整個元資料庫，導致 HS2 的啟動時間非常長，從下線狀態到重新上線間隔過大，可用性很差。
將物化視圖功能修改為延遲懶載入，單獨線程載入，不影響 HS2 的服務啟動。物化視圖支持載入中獲取已緩存信息，保證功能的可用性。
HS2 啟動時間從 5min+提升至<5s。
HS2 本身上下線成本較高，需要保證服務上的任務全部執行完成才能進行操作。配置的修改可作為較高頻率的操作，且需要做到熱載入。
在 HS2 的 ThriftServer 層我們增加了介面，與運維系統打通後，配置下推更新的時候自動調用，可實現配置的熱載入生效。
HiveServer2 的 scratchdir 主要用於運行過程中的臨時文件存儲。當 HS2 中的會話創建時，便會創建 scratchdir。在 HDFS 壓力大的時候，大量的會話會阻塞在創建 scratchdir 過程，導致連接數堆積至上限，最終 HS2 服務無法再連入新連接，影響服務可用性。
對此，我們先分離了一般查詢與 create temporay table 查詢的 scratch 目錄，並支持 create temporay table 查詢的 scratch 的懶創建。當 create temporay table 大量創建臨時文件，便會影響 HDFS NameNode 延遲時間的時候，一般查詢的 scratchdir HDFS NameNode 可以正常響應。
此外，HS2 還支持配置多 scratch，不同的 scratch 能設置載入比率，從而實現 HDFS 的均衡負載。
Hive 調度其中存在兩個問題。
一、子 Task 非執行狀態為完成情況的時候，若有多輪父 Task 包含子 Task，導致子 Task 被重復加入調度隊列。這種 Case，需要將非執行狀態修改成初始化狀態。
二、當判斷子 Task 是否可執行的過程中，會因為狀態檢測異常，無法正常加入需要調度的子 Task，從而致使查詢丟失 Stage。而這種 Case，我們的做法是在執行完成後，加入一輪 Stage 的執行結果狀態檢查，一旦發現有下游 Stage 沒有完成，直接拋出錯誤，實現查詢結果狀態的完備性檢查。
•HS2 實現了介面終止查詢 SQL。利用這個功能，可以及時終止異常 SQL。
•metastore JDOQuery 查詢優化，關鍵字異常跳過，防止元數據長時間卡頓或者部分異常查詢影響元數據。
•增加開關控制，強制覆蓋外表目錄，解決 insert overwrite 外表，文件 rename 報錯的問題。
•hive parquet 下推增加關閉配置，避免 parquet 異常地下推 OR 條件，導致結果不正確。
•executeForArray 函數 join 超大字元串導致 OOM，增加限制優化。
•增加根據 table 的 schema 讀取分區數據的功能，避免未級聯修改分區 schema 導致讀取數據異常。
•部分用戶並沒有開發經驗，無法處理處理引擎返回的報錯。
•有些錯誤的報錯信息不明確，用戶無法正確了解錯誤原因。
•失敗的任務排查成本高，需要對 Hadoop 整套系統非常熟悉。
•用戶的錯誤 SQL、以及需要優化的 SQL，大量具有共通性。人力維護成本高，但系統分析成本低。
SQL 專家系統基於 HS2 的 Hook 架構，在 BeaconServer 後端實現了三個主要的模塊，分別是 SQL 規則控制模塊、SQL 錯誤分析模塊，與 SQL 優化建議模塊。SQL 專家系統的知識庫，包含關鍵字、原因說明、處理方案等幾項主要信息，存於後端資料庫中，並一直積累。
通過 SQL 專家系統，後端可以進行查詢 SQL 的異常控制，避免異常 SQL 的資源浪費或者影響集群穩定。用戶在遇到問題時，能直接獲取問題的處理方案，減少了使用成本。
示例：空分區查詢控制。
SQL 專家系統能解決一部分 HS2 的任務執行的錯誤診斷需求，但是比如作業 健康 度、任務執行異常等問題原因的判斷，需要專門的系統來解決，為此我們設計了作業診斷系統。
作業診斷系統在 YARN 的層面，針對不同的執行引擎，對搜集的 Counter 和配置進行分析。在執行層面，提出相關的優化建議。
作業診斷系統的數據也能通過 API 提供給 SQL 專家系統，補充用於分析的問題原因。
作業診斷系統提供了查詢頁面來查詢運行的任務。以下是命中 map 輸入過多規則的任務查詢過程：
㈥ python學習分幾個階段
分為七大階段！
階段一:python基礎知識和高級特性
㈦ 怎樣進行sql資料庫的優化
1、資料庫空間是個概述，在sqlserver里，使用語句 exec sp_spaceused 'TableName' 這個語句來查。
㈧ 什麼叫SQL語句的優化
意思就是要執行的效率高
譬如select * from tabla_name where id=1 可以執行
select * from tabla_name where id in (1) 也可以執行
但是比較來看，=1的比in (1)的效率要高
只是舉個簡單的例子，實際操作里並不是如此簡單