前言：7月13號 至7月26號面試總結

比較棘手的的問題：

近來面試找工作經常會遇見這種問題： 做過資料庫優化嗎？大資料量基礎過嗎？系統反應慢怎麼查詢？

這時候就需要你談一下sql優化相關的內容 ，   一下幾個方面

1、慢查詢

2、索引

3、拆分表

資料庫索引變快
全部檢索（掃描）
系統整合


二叉樹演算法--》索引檔案   物理位置
log2N  檢索10次可以檢索2的10次方個數（1024）

全文索引，主要是針對對檔案，文字的檢索, 比如文章, 全文索引針對MyISAM有用.
select * from articles where match(title,body) against(‘database’); 【可以】

唯一索引
unique空串（null）可以放多個 如果是具體的內容則不能重複

a: 肯定在where條經常使用 
b: 該欄位的內容不是唯一的幾個值(sex)  （只有三個資料形成2級二叉樹）
c: 欄位內容不是頻繁變化. 

聯合索引

分表、水平分割

知識點、專案

sql優化（查詢9:1）
1. 儘量使用列名(Oracle9i之後, *和列名一樣)
   在業務密集的SQL當中儘量不採用IN操作符，用EXISTS 方案代替。

2、模糊查詢like
關鍵詞%yue%，由於yue前面用到了“%”，因此該查詢必然走全表掃描，除非必要，否則不要在關鍵詞前加%，

3 二者都能使用盡量使用where （與having比較）
where 先過濾（資料就少了）在分組  

4: 理論上，儘量使用多表連線（join）查詢（避免子查詢）

show status like 'uptime';
show [session|global] status like 'com_select';
show status like 'connections';
慢查詢（預設10秒）
show status like 'slow_querties';


以安全模式啟動


SHOW INDEX FROM emp

BTREE

20180327更新

B樹：有序陣列+平衡多叉樹；

B+樹：有序陣列連結串列+平衡多叉樹；

從上圖你能看到，一個內結點x若含有n[x]個關鍵字，那麼x將含有n[x]+1個子女

為什麼說B⁺-tree比B 樹更適合實際應用中作業系統的檔案索引和資料庫索引？

1）B⁺樹的磁碟讀寫代價更低

B⁺樹的內部結點並沒有指向關鍵字具體資訊的指標。因此其內部結點相對於B樹更小。如果把所有同一內部結點的關鍵字存放在同一盤塊中，那麼盤塊所能容納的關鍵字數量也越多。一次性讀入記憶體中的需要查詢的關鍵字也就越多。相對來說IO讀寫次數也就降低了。

2) B⁺-tree的查詢效率更加穩定

由於非終結點並不是最終指向檔案內容的結點，而只是葉子結點中關鍵字的索引。所以任何關鍵字的查詢必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數據的查詢效率相當。

MySQL索引實現

MyISAM索引檔案和資料檔案是分離的，索引檔案僅儲存資料記錄的地址。因此，MyISAM中索引檢索的演算法為首先按照B+Tree搜尋演算法搜尋索引，如果指定的Key存在，則取出其data域的值，然後以data域的值為地址，讀取相應資料記錄。而在InnoDB中，表資料檔案本身就是按B+Tree組織的一個索引結構，這棵樹的葉結點data域儲存了完整的資料記錄。

MyISAM的索引方式也叫做“非聚集”的