10-04 16—20

16. 簡述觸發器、函數、視圖、存儲過程？

觸發器：觸發器是一個特殊的存儲過程，它是MySQL在insert、update、delete的時候自動執行的代碼塊。

create trigger trigger_name
　　 after/before insert /update/delete on 表名
　　 for each row
　　 begin
　　 sql語句：（觸發的語句一句或多句）
　　 end

函數：MySQL中提供了許多內置函數，還可以自定義函數（實現程序員需要sql邏輯處理）

自定義函數創建語法：
　　 創建：CREATE FUNCTION 函數名稱(參數列表) 　
　　　       RETURNS 返回值類型 　函數體
 　　修改：ALTER FUNCTION 函數名稱 [characteristic ...]
　　 刪除：DROP FUNCTION [IF EXISTS] 函數名稱
　　 調用：SELECT 函數名稱(參數列表)

視圖：視圖是由查詢結果形成的一張虛擬表，是表通過某種運算得到的一個投影

create view view_name as select 語句

存儲過程：把一段代碼封裝起來，當要執行這一段代碼的時候，
可以通過調用該存儲過程來實現（經過第一次編譯后再次調用不需要再次編譯，比一個個執行sql語句效率高）

 create procedure 存儲過程名(參數,參數,…)
　　 begin
　　 //代碼
　　 end

17. 列舉 創建索引但是無法命中索引的8種情況。

• 1、如果條件中有or，即使其中有條件帶索引也不會使用(這也是為什么盡量少用or的原因）
• 2、對於多列索引，不是使用的第一部分(第一個)，則不會使用索引
• 3、like查詢是以%開頭
• 4、如果列類型是字符串，那一定要在條件中將數據使用引號引用起來,否則不使用索引
• 5、如果mysql估計使用全表掃描要比使用索引快,則不使用索引
• 6 對小表查詢
• 7 提示不使用索引
• 8 統計數據不真實
• 9.單獨引用復合索引里非第一位置的索引列.

18. 優化數據庫？提高數據庫的性能

1. 對語句的優化
   ①用程序中，保證在實現功能的基礎上，盡量減少對數據庫的訪問次數；
   通過搜索參數，盡量減少對表的訪問行數,最小化結果集，從而減輕網絡負擔；
   ②能夠分開的操作盡量分開處理，提高每次的響應速度；在數據窗口使用SQL時，盡量把使用的索引放在選擇的首列；算法的結構盡量簡單；
   ③在查詢時，不要過多地使用通配符如 SELECT * FROM T1 語句，要用到幾列就選擇幾列如：
   SELECT COL1,COL2 FROM T1；
   ④在可能的情況下盡量限制盡量結果集行數如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,因為某些情況下用戶是不需要那么多的數據的。
   ⑤不要在應用中使用數據庫游標，游標是非常有用的工具，但比使用常規的、面向集的SQL語句需要更大的開銷；按照特定順序提取數據的查找。
2. 避免使用不兼容的數據類型
   例如float和int、char和varchar、binary 和varbinary是不兼容的。
   數據類型的不兼容可能使優化器無法執行一些本來可以進行的優化操作。
   例如:
   SELECT name FROM employee WHERE salary ＞ 60000
   在這條語句中,如salary字段是money型的,則優化器很難對其進行優化,因為60000 是個整型數。我們應當在編程時將整型轉化成為錢幣型,而不要等到運行時轉化。 若在查詢時強制轉換，查詢速度會明顯減慢。
3. 避免在WHERE子句中對字段進行函數或表達式操作。
   若進行函數或表達式操作，將導致引擎放棄使用索引而進行全表掃描。
4. 避免使用!=或＜＞、IS NULL或IS NOT NULL、IN ，NOT IN等這樣的操作符
5. 盡量使用數字型字段
6. 合理使用EXISTS,NOT EXISTS子句。
7. 盡量避免在索引過的字符數據中，使用非打頭字母搜索。
8. 分利用連接條件
9. 消除對大型表行數據的順序存取
10. 避免困難的正規表達式
11. 使用視圖加速查詢
12. 能夠用BETWEEN的就不要用IN
13. DISTINCT的就不用GROUP BY
14. 部分利用索引
15. 能用UNION ALL就不要用UNION
16. 不要寫一些不做任何事的查詢
17. 盡量不要用SELECT INTO語句
18. 必要時強制查詢優化器使用某個索引
19. 雖然UPDATE、DELETE語句的寫法基本固定，但是還是對UPDATE語句給點建議：
    a) 盡量不要修改主鍵字段。
    b) 當修改VARCHAR型字段時，盡量使用相同長度內容的值代替。
    c) 盡量最小化對於含有UPDATE觸發器的表的UPDATE操作。
    d) 避免UPDATE將要復制到其他數據庫的列。
    e) 避免UPDATE建有很多索引的列。
    f) 避免UPDATE在WHERE子句條件中的列。

19. 數據庫負載均衡

負載均衡集群是由一組相互獨立的計算機系統構成，通過常規網絡或專用網絡進行連接，由路由器銜接在一起，各節點相互協作、共同負載、均衡壓力，對客戶端來說，整個群集可以視為一台具有超高性能的獨立服務器。
1、 實現原理
實現數據庫的負載均衡技術，首先要有一個可以控制連接數據庫的控制端。在這里，它截斷了數據庫和程序的直接連接，由所有的程序來訪問這個中間層，然后再由中間層來訪問數據庫。這樣，我們就可以具體控制訪問某個數據庫了，然后還可以根據數據庫的當前負載采取有效的均衡策略，來調整每次連接到哪個數據庫。
2、 實現多據庫數據同步
對於負載均衡，最重要的就是所有服務器的數據都是實時同步的。這是一個集群所必需的，因為，如果數不據實時、不同步，那么用戶從一台服務器讀出的數據，就有別於從另一台服務器讀出的數據，這是不能允許的。所以必須實現數據庫的數據同步。這樣，在查詢的時候就可以有多個資源，實現均衡。比較常用的方法是Moebius for SQL Server集群，Moebius for SQL Server集群
采用將核心程序駐留在每個機器的數據庫中的辦法，這個核心程序稱為Moebius for SQL Server 中間件，主要作用是監測數據庫內數據的變化並將變化的數據同步到其他數據庫中。數據同步完成后客戶端才會得到響應，同步過程是並發完成的，所以同步到多個數據庫和同步到一個數據庫的時間基本相等；另外同步的過程是在事務的環境下完成的，保證了多份數據在任何時刻數據的一致性。正因為Moebius 中間件宿主在數據庫中的創新，讓中間件不但能知道數據的變化，而且知道引起數據變化的SQL語句，根據SQL語句的類型智能的采取不同的數據同步的策略以保證數據同步成本的最小化。
數據條數很少，數據內容也不大，則直接同步數據。數據條數很少，但是里面包含大數據類型，比如文本，二進制數據等，則先對數據進行壓縮然后再同步，從而減少網絡帶寬的占用和傳輸所用的時間。 數據條數很多，此時中間件會拿到造成數據變化的SQL語句， 然后對SQL語句進行解析，分析其執行計划和執行成本，並選擇是同步數據還是同步SQL語句到其他的數據庫中。此種情況應用在對表結構進行調整或者批量更改數據的時候非常有用。
3、 優缺點
優點：

1. 擴展性強：當系統要更高數據庫處理速度時，只要簡單地增加數據庫服務器就 可以得到擴展。
2. 可維護性：當某節點發生故障時，系統會自動檢測故障並轉移故障節點的應用，保證數據庫的持續工作。
3. 安全性：因為數據會同步的多台服務器上，可以實現數據集的冗余，通過多份數據來保證安全性。另外它成功地將數據庫放到了內網之中，更好地保護了數據庫的安全性。
4. 易用性：對應用來說完全透明，集群暴露出來的就是一個IP
   缺點：
   a) 不能夠按照Web服務器的處理能力分配負載。
   b) 負載均衡器(控制端)故障，會導致整個數據庫系統癱瘓。

20. 數據庫三大范式？

什么是范式：簡言之就是，數據庫設計對數據的存儲性能，還有開發人員對數據的操作都有莫大的關系。所以建立科學的，規范的的數據庫是需要滿足一些 規范的來優化數據數據存儲方式。在關系型數據庫中這些規范就可以稱為范式。
什么是三大范式：
第一范式：當關系模式R的所有屬性都不能在分解為更基本的數據單位時，稱R是滿足第一范式的，簡記為1NF。滿足第一范式是關系模式規范化的最低要求，否則，將有很多基本操作在這樣的關系模式中實現不了。
第二范式：如果關系模式R滿足第一范式，並且R得所有非主屬性都完全依賴於R的每一個候選關鍵屬性，稱R滿足第二范式，簡記為2NF。
第三范式：設R是一個滿足第一范式條件的關系模式，X是R的任意屬性集，如果X非傳遞依賴於R的任意一個候選關鍵字，稱R滿足第三范式，簡記為3NF.
注：關系實質上是一張二維表，其中每一行是一個元組，每一列是一個屬性