1.實踐中如何優化mysql

1) SQL語句及索引的優化

2) 資料庫表結構的優化

3) 系統配置的優化

4) 硬體優化

2.索引的底層實現原理和優化

在 DB2 資料庫中索引採用的是 B+ 樹的結構，索引的葉子節點上包含索引鍵的值和一個指向資料地址的指標。DB2 先查詢索引，然後通過索引裡記錄的指標，直接訪問表的資料頁。

B+樹。B+樹是應資料庫所需而出現的一種B樹的變形樹。

B+樹的特點：

（1）所有葉節點包含全部關鍵字及指向相應記錄的指標，而且葉節點中將關鍵字按大小順序排列，並且相鄰葉節點按大小順序相互連結起來。

（2）所有分支節點（可看做索引的索引）中僅包含它的各個子節點（即下一級的索引塊）中關鍵字的最大值即指向其子節點的指標。

（3）B+樹中，葉節點包含資訊，所有非葉結點僅起到索引作用，非葉節點中的每個索引項只含有對應子樹的最大關鍵字和指向該子樹的指標，不含有該關鍵字對應記錄的儲存地址。

（4）葉節點包含了所有的關鍵字，即在非葉節點出現的關鍵字也會出現在葉子節點中。

B+樹有兩個頭指標，一個指向根節點，另一個指向關鍵字最小的葉節點。B+樹進行兩種查詢運算：從最小關鍵字開始的順序查詢，另一種從根節點開始的多路查詢。

原理：葉子節點是按關鍵字大小順序排列，且增加了指向下一個葉子節點的指標。

優化：InnoDB建議大部分表使用預設的自增的主鍵作為索引

MsSql、DB2使用的是B+Tree，Oracle及Sysbase使用的是

SQL語句的優化

1) 儘量避免耗時操作。

帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啟動SQL引 執行，耗費資源的排序(SORT)功能。DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序

2) 如果無需排除重複值或是操作集無重複則用UNION ALL， UNION更費事（因為要比較）

UNION因為會將各查詢子集的記錄做比較，故比起UNION ALL ，通常速度都會慢上許多。一般來說，如果使用UNION ALL能滿足要求的話， 務必使用UNION ALL。還有一種情況大家可能會忽略掉，就是雖然要求幾個子集的並集需要過濾掉重複記錄，但由於指令碼的特殊性，不可能存在重複記錄，這時便應該使用

3) 避免在WHERE子句中使用in，not  in，or 或者having。可以使用 exist 和not exist代替 in和not in。可以使用錶鏈接代替 exist。Having可以用where代替，如果無法代替可以分兩步處理。例子

SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN
(SELECT CUSTOMER_NAME FROM CUSTOMER)

SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist
(SELECT CUSTOMER_NAME FROM CUSTOMER)

4) 不要在建立的索引的資料列上進行下列操作:（1）避免對索引欄位進行計算操作

（2）避免在索引欄位上使用not，<>，!=

（3）避免在索引列上使用IS NULL和IS NOT NULL

（4）避免在索引列上出現數據型別轉換

（5）避免在索引欄位上使用函式

例如：where trunc(create_date)=trunc(:date1)雖然已對create_date 欄位建了索引，但由於加了TRUNC，使得索引無法用上。此處正確的寫法應該是where create_date>=trunc(:date1) and create_date

（6）避免建立索引的列中使用空值。

5) 查詢的模糊匹配

儘量避免在一個複雜查詢裡面使用 LIKE '%parm1%'—— 紅色標識位置的百分號會導致相關列的索引無法使用，最好不要用。

解決辦法:

其實只需要對該指令碼略做改進，查詢速度便會提高近百倍。改進方法如下：

a、修改前臺程式——把查詢條件的供應商名稱一欄由原來的文字輸入改為下拉列表，使用者模糊輸入供應商名稱時，直接在前臺就幫忙定位到具體的供應商，這樣在呼叫後臺程式時，這列就可以直接用等於來關聯了。

b、直接修改後臺——根據輸入條件，先查出符合條件的供應商，並把相關記錄儲存在一個臨時表裡頭，然後再用臨時表去做複雜關聯

6) 避免使用臨時表
(1)除非卻有需要，否則應儘量避免使用臨時表，相反，可以使用表變數代替;
(2)大多數時候(99%)，表變數駐紮在記憶體中，因此速度比臨時表更快，臨時表駐紮在TempDb資料庫中，因此臨時表上的操作需要跨資料庫通訊，速度自然慢。

可以使用聯合(UNION)來代替手動建立的臨時表

MySQL 從 4.0 的版本開始支援 UNION 查詢，它可以把需要使用臨時表的兩條或更多的 SELECT 查詢合併的一個查詢中。在客戶端的查詢會話結束的時候，臨時表會被自動刪除，從而保證資料庫整齊、高效。使用 UNION 來建立查詢的時候，我們只需要用UNION作為關鍵字把多個SELECT語句連線起來就可以了，要注意的是所有 SELECT 語句中的欄位數目要想同。下面的例子就演示了一個使用 UNION的查詢。

程式碼如下:

SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM author
UNION
SELECT Name, Supplier FROM product

7) 儘量少做重複的工作儘量減少無效工作，但是這一點的側重點在客戶端程式，需要注意的如下：
A、 控制同一語句的多次執行，特別是一些基礎資料的多次執行是很多程式設計師很少注意的
B、減少多次的資料轉換，也許需要資料轉換是設計的問題，但是減少次數是程式設計師可以做到的。
C、杜絕不必要的子查詢和連線表，子查詢在執行計劃一般解釋成外連線，多餘的連線錶帶來額外的開銷。
D、合併對同一表同一條件的多次UPDATE，比如
UPDATE EMPLOYEE SET FNAME='HAIWER' WHERE EMP_ID=' VPA30890F'
UPDATE EMPLOYEE SET LNAME='YANG' WHERE EMP_ID=' VPA30890F'
這兩個語句應該合併成以下一個語句
UPDATE EMPLOYEE SET FNAME='HAIWER',LNAME='YANG'
WHERE EMP_ID=' VPA30890F'
E、UPDATE操作不要拆成DELETE操作+INSERT操作的形式，雖然功能相同，但是效能差別是很大的。
F、不要寫一些沒有意義的查詢，比如
SELECT * FROM EMPLOYEE WHERE 1=2

Where後面的原則

第一個原則：在where子句中應把最具限制性的條件放在最前面。

第二個原則：where子句中欄位的順序應和索引中欄位順序一致。

select field3,field4 from tb where upper(field2)='RMN'不使用索引。
如果一個表有兩萬條記錄，建議不使用函式；如果一個表有五萬條以上記錄，嚴格禁止使用函式！兩萬條記錄以下沒有限制。

3.什麼情況下設定了索引但無法使用，索引無效

1) 以”%”開頭的LIKE語句，模糊匹配：紅色標識位置的百分號會導致相關列的索引無法使用

2) Or語句前後沒有同時使用索引

3) 資料型別出現隱式轉化（如varchar不加單引號的話可能會自動轉換為int型，會使索引無效，產生全表掃描。）

4) 在索引列上使用IS NULL 或IS NOT NULL操作。索引是不索引空值的，所以這樣的操作不能使用索引，可以用其他的辦法處理，例如：數字型別，判斷大於0，字串型別設定一個預設值，判斷是否等於預設值即可

5) 在索引欄位上使用not，<>，!=，eg<> 操作符（不等於）：不等於操作符是永遠不會用到索引的，因此對它的處理只會產生全表掃描。 用其它相同功能的操作運算代替，如 a<>0 改為 a>0 or a<0

6) 對索引欄位進行計算操作

7) 在索引欄位上使用函式

4.如何設計一個高併發的系統

1) 資料庫的優化，包括合理的事務隔離級別、SQL語句優化、索引優化

2) 使用快取、儘量減少資料庫IO

3) 分散式資料庫、分散式快取

4) 伺服器的負載均衡