一、sql數據庫優化
1、索引
建立索引是數據庫優化各種方案之中成本最低，見效最快的解決方案，一般來講，數據庫規模在幾十萬和幾百萬級別的時候見效最快，即便是有不太複雜的表關聯，也能大幅度提高sql的運行效率。
建立索引需要注意的地方
1、索引一般加在查詢條件的關鍵字上，如果有多個查詢條件關鍵字，還可以添加組合索引，寫sql的時候需要注意，索引字段和sql字段需要保持一致，否則索引會無效。
2、建立索引的字段要區分度比較高，比如user表中有一個性別字段，性別字段無非男女兩種值，區分度不好，建立索引效果不好，要選擇區分度高的字段
3、建立組合索引，可以持續提升sql運行效率，但是也不要盲目，同樣的要注意區分度，如果區分度不夠高，就不要加了，多個字段，儘可能把區分度高的字段放在前面，另外，還要注意索引長度，這個索引要同時兼顧索引長度和區分度的平衡
4、索引會大幅提升查詢效率，但是也會損耗查詢後修改效率，要注意兼顧平衡，使用在一次插入，多次查詢的表上效果最好，同時要注意的是，組合索引會不可避免的增加索引長度，會增加索引存儲空間，注意索引長度和區分度平衡
5.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重複時，SQL查詢可能不會去利用索引
6.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因爲 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
7.在使用索引字段作爲條件時，如果該索引是複合索引，那麼必須使用到該索引中的第一個字段作爲條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應儘可能的讓字段順序與索引順序相一致。
MySQL索引實現
MyISAM索引文件和數據文件是分離的，索引文件僅保存數據記錄的地址。因此，MyISAM中索引檢索的算法爲首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，則取出其data域的值，然後以data域的值爲地址，讀取相應數據記錄。而在InnoDB中，表數據文件本身就是按B+Tree組織的一個索引結構，這棵樹的葉結點data域保存了完整的數據記錄。
MyISAM的索引方式也叫做“非聚集”的
2、分庫分表分區
索引適合應對百萬級別的數據量，千萬級別數據量使用的好，勉強也能湊合，但如果是上億級別的數據量，索引就無能爲力了，因爲單索引文件可能就已經上百兆或者更多了，那麼，輪到的分表分區登場了
分庫
可以按照業務分庫，分流數據庫併發壓力，使數據庫表更加有條理性。可以把查詢庫和系統庫(增刪改比較頻繁的表)分開了，這樣如果有大查詢，不影響系統庫
分表的方法
1、如果這個業務是有流程的，那麼我們通常會設計一個歷史表或者歸檔表，用來存放歷史數據，這樣能保證實時數據效率比較高
2、針對某一張大表，可以根據查詢條件分成多張表，比如時間，我們可以將半個月或者10天的數據放到一張表裏(看具體數據量，個人認爲3000W是個上限，最好控制到百萬級別)，每過10天，我們就自動創建一張數據庫表，然後將數據插入，如此，按照時間查詢，就要先定位去那種表中去取數，這樣，效率能夠得到大幅度提升.
當然，這麼解決也有問題，比如跨表，需要union多張表，而且跨表沒法支持索引
3、一般來講，數據庫中的大表畢竟只是一少部分，僅需要對這少部分大表進行分表就可以了，沒必要小表也進行分表，增加維護開發難度
分區
分區的實現道理和分表一樣，也是將相應規則的數據放在一起，唯一不同的是分區你只需要設定好分區規則，插入的數據會被自動插入到指定的區裏。當然查詢的時候也能很快查詢到需要區，相當於是分表對外透明瞭，出現跨表數據庫自動幫我們合併做了處理，使用起來比分表更加方便。
但是分區也有自己的問題，每一個數據庫表的併發訪問是有上限的，也就是說，分表能夠抗高併發，而分區不能，如何選擇，要考慮實際情況
3、數據庫引擎
mysql比較常用的數據庫引擎有兩種，一種是innodb、一種是myisam
在一個千萬級數據量複雜sql測試中，myisam的效率大概能夠比innodb快1-2倍，雖然效率提升不是很明顯，但是也有提升，後來查過一些資料，說之所以mysiam快，是因爲他的數據存儲結構、索引存儲結構和innodb不一樣的，mysiam的索引結構是在內存中存的
當然，mysiam也有弱點，那就是他是表級鎖，而innodb是行級鎖，所以，mysiam適用於一次插入，多次查詢的表，或者是讀寫分離中的讀庫中的表，而對於修改插入刪除操作比較頻繁的表，就很不合適了
4、預處理
一般來說，實時數據(當天的數據)還是比較有限的，真正數據量比較大的是歷史數據，基於大表歷史數據的查詢，如果再涉及一些大表關聯，這種sql是非常難以優化的
實時數據(當天數據)
通過對對業務的抽象，可以放在緩存裏面，提升系統運行效率
歷史數據
大數據表歷史數據且有表關聯，通過常規sql難以優化，但是該數據通常有個共性，就是第二天去查詢前一天的數據做分析報表，也就是說對時效性要求不高，這種情況的解決方案是預處理
處理：
將這些複雜表關聯sql寫成個定時任務在半夜執行，將執行的結果存入到一張結果表中，第二天直接查詢結果表,如此，效率能得到十分明顯提升
5、讀寫分離
在數據庫併發大的情況下，最好的做法就是進行橫向擴展，增加機器，以提升抗併發能力，而且還兼有數據備份功能
二、SQL語句具體操作
1.對查詢進行優化，應儘量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應儘量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
3.應儘量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
4.應儘量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查詢也將導致全表掃描：
select id from t where name like '%abc%'
7.應儘量避免在 where 子句中對字段進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改爲:
select id from t where num=100*2
8.應儘量避免在where子句中對字段進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
應改爲:
select id from t where name like 'abc%'
9.不要在 where 子句中的“=”左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
10.不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0
這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
create table #t(...)
11.很多時候用 exists 代替 in 是一個好的選擇：
select num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
12.儘量使用數字型字段，若只含數值信息的字段儘量不要設計爲字符型，這會降低查詢和連接的性能，並會增加存儲開銷。
這是因爲引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對於數字型而言只需要比較一次就夠了。
13.儘可能的使用 varchar 代替 char ，因爲首先變長字段存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的字段內搜索效率顯然要高些。
14.任何地方都不要使用 select * from t ，用具體的字段列表代替“*”，不要返回用不到的任何字段。
15.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
16.臨時表並不是不可使用，適當地使用它們可以使某些例程更有效，例如，當需要重複引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
17.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，爲了緩和系統表的資源，應先create table，然後insert。
18.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
19.儘量避免使用遊標，因爲遊標的效率較差，如果遊標操作的數據超過1萬行，那麼就應該考慮改寫。
20.使用基於遊標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
21.與臨時表一樣，遊標並不是不可使用。對小型數據集使用 FAST_FORWARD 遊標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。
22.在結果集中包括“合計”的例程通常要比使用遊標執行的速度快。如果開發時間允許，基於遊標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
23.儘量避免大事務操作，提高系統併發能力。
24.儘量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
25.不要在查詢=前面使用函數，否則會導致索引不生效，舉個栗子，where str=substring(“hello world”,6,8),這樣是可以走索引的，但是 where substring(str,6,8)=“hello world” 是不會命中索引的
三、數據庫訪問性能優化
要正確的優化SQL，我們需要快速定位能性的瓶頸點，也就是說快速找到我們SQL主要的開銷在哪裏？
而大多數情況性能最慢的設備會是瓶頸點，如下載時網絡速度可能會是瓶頸點，本地複製文件時硬盤可能會是瓶頸點，爲什麼這些一般的工作我們能快速確認瓶頸點呢，因爲我們對這些慢速設備的性能數據有一些基本的認識，如網絡帶寬是2Mbps，硬盤是每分鐘7200轉等等。
計算機系統硬件性能從高到代依次爲：
CPU——Cache(L1-L2-L3)——內存——SSD硬盤——網絡——硬盤
根據數據庫知識，我們可以列出每種硬件主要的工作內容：
CPU及內存：緩存數據訪問、比較、排序、事務檢測、SQL解析、函數或邏輯運算；
網絡：結果數據傳輸、SQL請求、遠程數據庫訪問（dblink）；
硬盤：數據訪問、數據寫入、日誌記錄、大數據量排序、大表連接。
根據當前計算機硬件的基本性能指標及其在數據庫中主要操作內容，可以整理出如下圖所示的性能基本優化法則：
這個優化法則歸納爲5個層次：
1、 減少數據訪問（減少磁盤訪問）
2、 返回更少數據（減少網絡傳輸或磁盤訪問）
3、 減少交互次數（減少網絡傳輸）
4、 減少服務器CPU開銷（減少CPU及內存開銷）
5、 利用更多資源（增加資源）
由於每一層優化法則都是解決其對應硬件的性能問題，所以帶來的性能提升比例也不一樣。傳統數據庫系統設計是也是儘可能對低速設備提供優化方法，因此針對低速設備問題的可優化手段也更多，優化成本也更低。我們任何一個SQL的性能優化都應該按這個規則由上到下來診斷問題並提出解決方案，而不應該首先想到的是增加資源解決問題。
以下是每個優化法則層級對應優化效果及成本經驗參考：
四、爲什麼說B+tree比B 樹更適合實際應用中操作系統的文件索引和數據庫索引？
1）B+樹的磁盤讀寫代價更低
B+樹的內部結點並沒有指向關鍵字具體信息的指針。因此其內部結點相對於B樹更小。如果把所有同一內部結點的關鍵字存放在同一盤塊中，那麼盤塊所能容納的關鍵字數量也越多。一次性讀入內存中的需要查找的關鍵字也就越多。相對來說IO讀寫次數也就降低了。
2) B+-tree的查詢效率更加穩定
由於非終結點並不是最終指向文件內容的結點，而只是葉子結點中關鍵字的索引。所以任何關鍵字的查找必須走一條從根結點到葉子結點的路。所有關鍵字查詢的路徑長度相同，導致每一個數據的查詢效率相當。
五、優化實例
（1）插入數據
1.導入大批量數據
這個需要先關閉索引，插入數據後再打開索引。
1.1.針對MyISAM引擎可以通過以下方式提高導入數據效率，但是Innodb並不能提高這個效率。
命令：alter table user disable keys; //關閉所有索引
alter table user enable keys; // 開啓索引
1.2.對於Innodb類型的表，由於Innodb的表是根據主鍵的順序保存的，所以將導入的數據按照主鍵的順序，可以提高效率
1. 2.1在導入數據前關閉唯一性校驗也可以提高效率 set unique_checks=0
1.2.2 關閉自動提交，set auto-commit=0 採用手動提交也可以提高效率
2.優化insert語句
2.1如果同時插入多行，採用多個值表更好。
inset into test values(1,2),(1,3),(2,3);
（2）排序 order by
目標：儘量減少額外的排序，通過索引直接返回有序數據。
排序情況有以下兩種結果：
1.通過有序索引順序掃描直接返回有序數據。這裏分析結果Extra：Using index ;例如：
explain select customer_id from customer order by store_id; //這裏customer_id是主鍵，store_id是索引
2. 通過返回數據進行排序，explain 返回的Extra結果是Using fileSort。這個是不好的。例如：
explain select * from cutomer order by store_id;//store_id是一個索引
方案：1>:where和order by使用相同的索引，並且order by 的順序和索引順序（如果複合索引）相同
2>:order by 字段都是同爲升序或者降序，否則索引不生效，使用了Using fileSort
3>:當filesort索引無法避免情況下，想辦法加快fileSort操作，設計到兩次掃描算法和一次掃描算法，看情況使用某一種。
兩次掃描算法：根據條件取出排序字段和行指針信息，之後再排序區排序，如果排序區不夠在新建臨時表。完成排序後在通過指針回表讀取記錄。
一次掃描算法：一次性取出滿足條件的行的所有字段。然後再排序區完成排序後，直接輸出數據，這個排序的時候內存消耗比較大，但是相比兩次效率又高。
（3）分組group by 優化
默認情況下group by 對字段分組的時候，會排序。這和在查詢order by 的情況類似。
1. 如果在在分組的時候不需要排序，最好關掉排序命令：order by null。
explain select name sum(money) from user group by name order by null;
（4）優化嵌套查詢
1.某些子查詢可以通過join來代替。
理由：join不需要在內存中創建一個臨時表來存儲數據。
explain select * from customer where customer_id not in (select customer_id from payment) ;
上面的語句用下面的語句代替
explain select * from customer a left join payment b on a.customer_id=b.customer where b.customer_id is null;
（5）優化or條件
1. 對於單獨的兩個索引
explain select * from sales where id=2 or year =1998; //id和year都是索引
這兩個索引都是被使用到了的，但是這個查詢時分別對兩個條件進行查詢，然後union兩個結果的。
2. 如果對複合索引(id 和year是複合索引)，那麼如果不能使用到索引，採用全文掃描。
（6）優化分頁查詢
常見的分頁查詢，查詢到“limit 2000,20”;時候就會出現先查詢前面2200個，然後拋棄前面2000個，造成查詢和排序代價非常大。優化方式如下：
1.在索引上完成排序分頁的操作。根據主鍵關聯回原表查詢所需要的其他內容。
explain select a.last_name , a.first_name from user a inner join (select id from user order by id limit 2000,20) b on a.id=b.id;
2.把limit查詢轉換成某一個位置查詢。可以通過把上一頁的最後一條記錄記下來。
select * from payment order by rental_id desc limit 2000,20; //這樣效率非常低下
如上面是通過 rental_id 降序來排列的 ，那麼我們在查詢 limit 1800,20時候，記錄下2000位置的rental_id,加入這裏的rental_id的值，假設這裏的值是“5000” ，那麼sql語句就可以轉換成如下：
select * from payment where rental_id < 5000 order by rental_id desc limit 20;
注意事項： 這個只適合在排序字段不會出現重複值的特定環境，能夠減輕分頁翻頁的壓力，如果排序字段出現重複值，那麼就會出現記錄丟失。
（7）使用SQL提示
常見的SQL提示如下：
1. use index 這個表示希望sql去參考的索引，就可以讓mysql不在考慮其他可用的索引了
explain select count(*) from user user index(idx_user_id);
2.ingore index 只是單純的希望mysql忽略一個索引，或者多個。
explain select count(*) from rental ignore index(idx_rental_date)
3.force index 強制mysql使用一個索引
explain select * from user force index (idx_fk_inventory_id) where inventory_id >1;
默認inventory_Id都是大於1的，所以一般會全表掃描，如果強制使用這個所以，那麼msyql還是會使用這個索引。