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使用的是B-Tree
SQL語句的優化
1) 儘量避免耗時操作。
帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啓動SQL引 執行，耗費資源的排序(SORT)功能。DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序
2) 如果無需排除重複值或是操作集無重複則用UNION ALL， UNION更費事（因爲要比較）
UNION因爲會將各查詢子集的記錄做比較，故比起UNION ALL ，通常速度都會慢上許多。一般來說，如果使用UNION ALL能滿足要求的話， 務必使用UNION ALL。還有一種情況大家可能會忽略掉，就是雖然要求幾個子集的並集需要過濾掉重複記錄，但由於腳本的特殊性，不可能存在重複記錄，這時便應該使用UNION ALL，如xx模塊的某個查詢程序就曾經存在這種情況，見，由於語句的特殊性，在這個腳本中幾個子集的記錄絕對不可能重複，故可以改用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 product7) 儘量少做重複的工作
儘量減少無效工作，但是這一點的側重點在客戶端程序，需要注意的如下：
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) 服務器的負載均衡