㈠ 內表怎麼和資料庫連接
內表就是一塊內存.
ABAP中可以把SAP管理的資料庫的數據抓到你自己建的內表中.
如果要在外部資料庫抓資料庫到sap的內表中,要做介面程序實現.
㈡ hashjoinrightsemi如何優化
Mysql一直被人詬病沒有實現HashJoin，最新發布的8.0.18已經帶上了這個功能，令人欣喜。有時候在想，MySQL為什麼一直不支持HashJoin呢？我想可能是因為MySQL多用於簡單的OLTP場景，並且在互聯網應用居多，需求沒那麼緊急。另一方面可能是因為以前完全靠社區，這種演進速度畢竟有限，Oracle收購MySQL後，MySQL的發版演進速度明顯加快了很多。
HashJoin本身演算法實現並不復雜，要說復雜，可能是優化器配套選擇執行計劃時，是否選擇HashJoin，選擇外表，內表可能更復雜一點。不管怎樣現在已經有了HashJoin，優化器在選擇Join演算法時又多了一個選擇。MySQL本著實用主義，相信這個功能增強也回應了一些質疑，有些功能不是沒有能力做好，而是有它的優先順序。
在8.0.18之前，MySQL只支持NestLoopJoin演算法，最簡單的就是Simple NestLoop Join，MySQL針對這個演算法做了若干優化，實現了Block NestLoop Join，Index NestLoop Join和Batched Key Access等，有了這些優化，在一定程度上能緩解對HashJoin的迫切程度。下文會單獨拿一個章節講MySQL的這些Join優化，下面先講HashJoin。
Hash Join演算法
NestLoopJoin演算法簡單來說，就是雙重循環，遍歷外表(驅動表)，對於外表的每一行記錄，然後遍歷內表，然後判斷join條件是否符合，進而確定是否將記錄吐出給上一個執行節點。從演算法角度來說，這是一個M*N的復雜度。HashJoin是針對equal-join場景的優化，基本思想是，將外表數據load到內存，並建立hash表，這樣只需要遍歷一遍內表，就可以完成join操作，輸出匹配的記錄。如果數據能全部load到內存當然好，邏輯也簡單，一般稱這種join為CHJ(Classic Hash Join)，之前MariaDB就已經實現了這種HashJoin演算法。如果數據不能全部load到內存，就需要分批load進內存，然後分批join，下面具體介紹這幾種join演算法的實現。
In-Memory Join(CHJ)
HashJoin一般包括兩個過程，創建hash表的build過程和探測hash表的probe過程。
1).build phase
遍歷外表，以join條件為key，查詢需要的列作為value創建hash表。這里涉及到一個選擇外表的依據，主要是評估參與join的兩個表(結果集)的大小來判斷，誰小就選擇誰，這樣有限的內存更容易放下hash表。
2).probe phase
hash表build完成後，然後逐行遍歷內表，對於內表的每個記錄，對join條件計算hash值，並在hash表中查找，如果匹配，則輸出，否則跳過。所有內表記錄遍歷完，則整個過程就結束了。過程參照下圖，來源於MySQL官方博客
左側是build過程，右側是probe過程，country_id是equal_join條件，countries表是外表，persons表是內表。
On-Disk Hash Join
CHJ的限制條件在於，要求內存能裝下整個外表。在MySQL中，Join可以使用的內存通過參數join_buffer_size控制。如果join需要的內存超出了join_buffer_size，那麼CHJ將無能為力，只能對外表分成若干段，每個分段逐一進行build過程，然後遍歷內表對每個分段再進行一次probe過程。假設外表分成了N片，那麼將掃描內表N次。這種方式當然是比較弱的。在MySQL8.0中，如果join需要內存超過了join_buffer_size，build階段會首先利用hash算將外表進行分區，並產生臨時分片寫到磁碟上；然後在probe階段，對於內表使用同樣的hash演算法進行分區。由於使用分片hash函數相同，那麼key相同(join條件相同)必然在同一個分片編號中。接下來，再對外表和內表中相同分片編號的數據進行CHJ的過程，所有分片的CHJ做完，整個join過程就結束了。這種演算法的代價是，對外表和內表分別進行了兩次讀IO，一次寫IO。相對於之之前需要N次掃描內表IO，現在的處理方式更好。
第一張圖是外表的分片過程，第二張圖是內表的分片過程，第三張圖是對分片進行build+probe過程。
Grace Hash Join
主流的資料庫Oracle，SQLServer，PostgreSQL早就支持了HashJoin。Join演算法都類似，這里介紹下Oracle使用的Grace Hash Join演算法。其實整個過程與MySQL的HashJoin類似，主要有一點區別。當出現join_buffer_size不足時，MySQL會對外表進行分片，然後再進行CHJ過程。但是，極端情況下，如果數據分布不均勻，導致大量的數據hash後都分布在一個分桶中，導致分片後，join_buffer_size仍然不夠，MySQL的處理方式是一次讀分片讀若干記錄構建hash表，然後probe對應的外表分片。處理完一批後，清理hash表，重復上述過程，直到這個分片的所有數據處理完為止。這個過程與CHJ在join_buffer_size不足時，處理邏輯相同。
GraceHash在遇到這種情況時，會繼續分片進行二次Hash，直到內存足夠放下一個hash表為止。但是，這里仍然有極端情況，如果輸入join條件都相同，那麼無論進行多少次Hash，都沒法分開，那麼這個時候GraceHashJoin也退化成和MySQL的處理方式一樣。
hybrid hash join
與GraceHashJoin的區別在於，如果緩存能緩存足夠多的分片數據，會盡量緩存，那麼就不必像GraceHash那樣，嚴格地將所有分片都先讀進內存，然後寫到外存，然後再讀進內存去走build過程。這個是在內存相對於分片比較充裕的情況下的一種優化，目的是為了減少磁碟的讀寫IO。目前Oceanbase的HashJoin採用的是這種join方式。
MySQL-Join演算法優化
在MySQL8.0.18之前，也就是在很長一段時間內，MySQL資料庫並沒有HashJoin，主要的Join演算法是NestLoopJoin。SimpleNestLoopJoin顯然是很低效的，對內表需要進行N次全表掃描，實際復雜度是N*M，N是外表的記錄數目，M是記錄數，代表一次掃描內表的代價。為此，MySQL針對SimpleNestLoopJoin做了若干優化，下面貼的圖片均來自網路。
BlockNestLoopJoin(BNLJ)
MySQL採用了批量技術，即一次利用join_buffer_size緩存足夠多的記錄，每次遍歷內表時，每條內表記錄與這一批數據進行條件判斷，這樣就減少了掃描內表的次數，如果內表比較大，間接就緩解了IO的讀壓力。
IndexNestLoopJoin(INLJ)
如果我們能對內表的join條件建立索引，那麼對於外表的每條記錄，無需再進行全表掃描內表，只需要一次Btree-Lookup即可，整體時間復雜度降低為N*O(logM)。對比HashJoin，對於外表每條記錄，HashJoin是一次HashTable的search，當然HashTable也有build時間，還需要處理內存不足的情況，不一定比INLJ好。
Batched Key Access
IndexNestLoopJoin利用join條件的索引，通過Btree-Lookup去匹配減少了遍歷內表的代價。如果join條件是非主鍵列，那麼意味著大量的回表和隨機IO。BKA優化的做法是，將滿足條件的一批數據按主鍵排序，這樣回表時，從主鍵的角度來說就相對有序，緩解隨機IO的代價。BKA實際上是利用了MRR特性(MultiRangeRead)，訪問數據之前，先將主鍵排序，然後再訪問。主鍵排序的緩存大小通過參數read_rnd_buffer_size控制。
總結
MySQL8.0以後，Server層代碼做了大量的重構，雖然優化器相對於Oracle還有很大差距，但一直在進步。HashJoin的支持使得MySQL優化器有更多選擇，SQL的執行路徑也能做到更優，尤其是對於等值join的場景。雖然MySQL之前對於Join做過若干優化，比如NBLJ，INLJ以及BKA等，但這些代替不了HashJoin的作用。一個好用的資料庫就應該具備豐富的基礎能力，利用優化器分析出合適場景，然後拿出對應的基礎能力以最高效的方式響應請求。
㈢ sql中in和exists的區別效率問題 轉
很多人和說法會認為in和Exists相比後者的效率要高。
但是以我本人使用資料庫的經驗來看，兩者的運行效率其實不相伯仲，不管有無可被利用的索引，它們在運行速度上沒有太明顯的分別，硬要說哪個快一些的話exists可能會快一點點，但是這種區別通常可以忽略。
然而在求非交集時 not in和not exists運行效率上的差距就很大，碰到大數據表時not in不管有無可被利用的索引，都會導致效率悲劇，其運行速度極之糟糕往往要運行很長的時間才能返回結果，期間系統就像假死一樣。not exists在有可被利用的索引的情況下碰到大數據表時其運行效率非常高、表現優異，但是若沒有可被利用索引的情況下其運行效率也很不好，此時其運行速度盡管要比not in快上不少但還是屬於那種令人無法接受的「蝸速」。
in和exists隨各人喜好隨便用，特別是數據量不大時。面對大數據表時就要小心，not in無論有無可被利用的索引都應避免使用，not exists在有可被利用索引的情況下可作為首選，反之也要避免使用。
㈣ 解釋一下資料庫的內模式、模式、外模式是什麼意思
一、模式（Schema）
定義：也稱邏輯模式，是資料庫中全體數據的邏輯結構和特徵的描述，是所有用戶的公共數據視圖。
理解：
①一個資料庫只有一個模式；
②是資料庫數據在邏輯級上的視圖；
③資料庫模式以某一種數據模型為基礎；
④定義模式時不僅要定義數據的邏輯結構（如數據記錄由哪些數據項構成，數據項的名字、類型、取值范圍等），而且要定義與數據有關的安全性、完整性要求，定義這些數據之間的聯系。
二、外模式（External Schema）
定義：也稱子模式（Subschema）或用戶模式，是資料庫用戶（包括應用程序員和最終用戶）能夠看見和使用的局部數據的邏輯結構和特徵的描述，是資料庫用戶的數據視圖，是與某一應用有關的數據的邏輯表示。
理解：
①一個資料庫可以有多個外模式；
②外模式就是用戶視圖；
③外模式是保證數據安全性的一個有力措施。
三、內模式（Internal Schema）
定義：也稱存儲模式（Storage Schema），它是數據物理結構和存儲方式的描述，是數據在資料庫內部的表示方式（例如，記錄的存儲方式是順序存儲、按照B樹結構存儲還是按hash方法存儲；索引按照什麼方式組織；數據是否壓縮存儲，是否加密；數據的存儲記錄結構有何規定）。
理解：
①一個資料庫只有一個內模式；
②一個表可能由多個文件組成，如：數據文件、索引文件。
它是資料庫管理系統(DBMS)對資料庫中數據進行有效組織和管理的方法
其目的有：
②為了減少數據冗餘，實現數據共享；
②為了提高存取效率，改善性能。
㈤ 資料庫的內連接和外連接有什麼區別
內連接：指連接結果僅包含符合連接條件的行，參與連接的兩個表都應該符合連接條件。
外連接：連接結果不僅包含符合連接條件的行同時也包含自身不符合條件的行。包括左外連接、右外連接和全外連接。
1、內連接
內連接，即最常見的等值連接，例:
SELECT*FROMTESTA,TESTBWHERETESTA.A=TESTB.A結果:
㈥ Hive內部表和外部表的區別是什麼
Hive中內部表與外部表的區別：
Hive 創建內部表時，會將數據移動到數據倉庫指向的路徑；若創建外部表，僅記錄數據所在的路徑，不對數據的位置做任何改變。在刪除表的時候，內部表的元數據和數據會被一起刪除，而外部表只刪除元數據，不刪除數據。這樣外部表相對來說更加安全些，數據組織也更加靈活，方便共享源數據。
需要注意的是傳統資料庫對表數據驗證是 schema on write（寫時模式），而 Hive 在load時是不檢查數據是否符合schema的，hive 遵循的是 schema on read（讀時模式），只有在讀的時候hive才檢查、解析具體的數據欄位、schema。
讀時模式的優勢是load data 非常迅速，因為它不需要讀取數據進行解析，僅僅進行文件的復制或者移動。
寫時模式的優勢是提升了查詢性能，因為預先解析之後可以對列建立索引，並壓縮，但這樣也會花費要多的載入時間。