https://blog.csdn.net/yzllz001/article/details/54848513
數據庫訪問優化法則
要正確的優化SQL，我們需要快速定位能性的瓶頸點，也就是說快速找到我們SQL主要的開銷在哪里？而大多數情況性能最慢的設備會是瓶頸點，如下載時網絡速度可能會是瓶頸點，本地復制文件時硬盤可能會是瓶頸點，為什么這些一般的工作我們能快速確認瓶頸點呢，因為我們對這些慢速設備的性能數據有一些基本的認識，如網絡帶寬是2Mbps，硬盤是每分鍾7200轉等等。因此，為了快速找到SQL的性能瓶頸點，我們也需要了解我們計算機系統的硬件基本性能指標，下圖展示的當前主流計算機性能指標數據。
從圖上可以看到基本上每種設備都有兩個指標：
延時（響應時間）：表示硬件的突發處理能力；
帶寬（吞吐量）：代表硬件持續處理能力。
從上圖可以看出，計算機系統硬件性能從高到代依次為：
CPU——Cache(L1-L2-L3)——內存——SSD硬盤——網絡——硬盤
由於SSD硬盤還處於快速發展階段，所以本文的內容不涉及SSD相關應用系統。
根據數據庫知識，我們可以列出每種硬件主要的工作內容：
CPU及內存：緩存數據訪問、比較、排序、事務檢測、SQL解析、函數或邏輯運算；
網絡：結果數據傳輸、SQL請求、遠程數據庫訪問（dblink）；
硬盤：數據訪問、數據寫入、日志記錄、大數據量排序、大表連接。
根據當前計算機硬件的基本性能指標及其在數據庫中主要操作內容，可以整理出如下圖所示的性能基本優化法則：
這個優化法則歸納為5個層次：
1、 減少數據訪問（減少磁盤訪問）
2、 返回更少數據（減少網絡傳輸或磁盤訪問）
3、 減少交互次數（減少網絡傳輸）
4、 減少服務器CPU開銷（減少CPU及內存開銷）
5、 利用更多資源（增加資源）
由於每一層優化法則都是解決其對應硬件的性能問題，所以帶來的性能提升比例也不一樣。傳統數據庫系統設計是也是盡可能對低速設備提供優化方法，因此針對低速設備問題的可優化手段也更多，優化成本也更低。我們任何一個SQL的性能優化都應該按這個規則由上到下來診斷問題並提出解決方案，而不應該首先想到的是增加資源解決問題。
以下是每個優化法則層級對應優化效果及成本經驗參考：
| 優化法則 |
性能提升效果 |
優化成本 |
| 減少數據訪問 |
1~1000 |
低 |
| 返回更少數據 |
1~100 |
低 |
| 減少交互次數 |
1~20 |
低 |
| 減少服務器CPU開銷 |
1~5 |
低 |
| 利用更多資源 |
@~10 |
高 |
接下來，我們針對5種優化法則列舉常用的優化手段並結合實例分析。
二、Oracle數據庫兩個基本概念
數據塊(Block)
數據塊是數據庫中數據在磁盤中存儲的最小單位，也是一次IO訪問的最小單位，一個數據塊通常可以存儲多條記錄，數據塊大小是DBA在創建數據庫或表空間時指定，可指定為2K、4K、8K、16K或32K字節。下圖是一個Oracle數據庫典型的物理結構，一個數據庫可以包括多個數據文件，一個數據文件內又包含多個數據塊；
ROWID
ROWID是每條記錄在數據庫中的唯一標識，通過ROWID可以直接定位記錄到對應的文件號及數據塊位置。ROWID內容包括文件號、對像號、數據塊號、記錄槽號，如下圖所示：
三、數據庫訪問優化法則詳解
1、減少數據訪問
1.1、創建並使用正確的索引
數據庫索引的原理非常簡單，但在復雜的表中真正能正確使用索引的人很少，即使是專業的DBA也不一定能完全做到最優。
索引會大大增加表記錄的DML(INSERT,UPDATE,DELETE)開銷，正確的索引可以讓性能提升100，1000倍以上，不合理的索引也可能會讓性能下降100倍，因此在一個表中創建什么樣的索引需要平衡各種業務需求。
索引常見問題：
索引有哪些種類？
常見的索引有B-TREE索引、位圖索引、全文索引，位圖索引一般用於數據倉庫應用，全文索引由於使用較少，這里不深入介紹。B-TREE索引包括很多擴展類型，如組合索引、反向索引、函數索引等等，以下是B-TREE索引的簡單介紹：
B-TREE索引也稱為平衡樹索引(Balance Tree)，它是一種按字段排好序的樹形目錄結構，主要用於提升查詢性能和唯一約束支持。B-TREE索引的內容包括根節點、分支節點、葉子節點。
葉子節點內容：索引字段內容+表記錄ROWID
根節點，分支節點內容：當一個數據塊中不能放下所有索引字段數據時，就會形成樹形的根節點或分支節點，根節點與分支節點保存了索引樹的順序及各層級間的引用關系。
一個普通的BTREE索引結構示意圖如下所示：
如果我們把一個表的內容認為是一本字典，那索引就相當於字典的目錄，如下圖所示：
圖中是一個字典按部首+筆划數的目錄，相當於給字典建了一個按部首+筆划的組合索引。
一個表中可以建多個索引，就如一本字典可以建多個目錄一樣（按拼音、筆划、部首等等）。
一個索引也可以由多個字段組成，稱為組合索引，如上圖就是一個按部首+筆划的組合目錄。
SQL什么條件會使用索引？
當字段上建有索引時，通常以下情況會使用索引：
INDEX_COLUMN = ?
INDEX_COLUMN > ?
INDEX_COLUMN >= ?
INDEX_COLUMN < ?
INDEX_COLUMN <= ?
INDEX_COLUMN between ? and ?
INDEX_COLUMN in (?,?,...,?)
INDEX_COLUMN like ?||'%'（后導模糊查詢）
T1. INDEX_COLUMN=T2. COLUMN1（兩個表通過索引字段關聯）
SQL什么條件不會使用索引？
| 查詢條件 |
不能使用索引原因 |
| INDEX_COLUMN <> ? INDEX_COLUMN not in (?,?,...,?) |
不等於操作不能使用索引 |
| function(INDEX_COLUMN) = ? INDEX_COLUMN + 1 = ? INDEX_COLUMN || 'a' = ? |
經過普通運算或函數運算后的索引字段不能使用索引 |
| INDEX_COLUMN like '%'||? INDEX_COLUMN like '%'||?||'%' |
含前導模糊查詢的Like語法不能使用索引 |
| INDEX_COLUMN is null |
B-TREE索引里不保存字段為NULL值記錄，因此IS NULL不能使用索引 |
| NUMBER_INDEX_COLUMN='12345' CHAR_INDEX_COLUMN=12345 |
Oracle在做數值比較時需要將兩邊的數據轉換成同一種數據類型，如果兩邊數據類型不同時會對字段值隱式轉換，相當於加了一層函數處理，所以不能使用索引。 |
| a.INDEX_COLUMN=a.COLUMN_1 |
給索引查詢的值應是已知數據，不能是未知字段值。 |
| 注： 經過函數運算字段的字段要使用可以使用函數索引，這種需求建議與DBA溝通。 有時候我們會使用多個字段的組合索引，如果查詢條件中第一個字段不能使用索引，那整個查詢也不能使用索引 如：我們company表建了一個id+name的組合索引，以下SQL是不能使用索引的 Select * from company where name=? Oracle9i后引入了一種index skip scan的索引方式來解決類似的問題，但是通過index skip scan提高性能的條件比較特殊，使用不好反而性能會更差。
|
|
我們一般在什么字段上建索引？
這是一個非常復雜的話題，需要對業務及數據充分分析后再能得出結果。主鍵及外鍵通常都要有索引，其它需要建索引的字段應滿足以下條件：
1、字段出現在查詢條件中，並且查詢條件可以使用索引；
2、語句執行頻率高，一天會有幾千次以上；
3、通過字段條件可篩選的記錄集很小，那數據篩選比例是多少才適合？
這個沒有固定值，需要根據表數據量來評估，以下是經驗公式，可用於快速評估：
小表(記錄數小於10000行的表)：篩選比例<10%；
大表：(篩選返回記錄數)<(表總記錄數*單條記錄長度)/10000/16
單條記錄長度≈字段平均內容長度之和+字段數*2
以下是一些字段是否需要建B-TREE索引的經驗分類：
|
|
字段類型 |
常見字段名 |
| 需要建索引的字段 |
主鍵 |
ID,PK |
| 外鍵 |
PRODUCT_ID,COMPANY_ID,MEMBER_ID,ORDER_ID,TRADE_ID,PAY_ID |
|
| 有對像或身份標識意義字段 |
HASH_CODE,USERNAME,IDCARD_NO,EMAIL,TEL_NO,IM_NO |
|
| 索引慎用字段,需要進行數據分布及使用場景詳細評估 |
日期 |
GMT_CREATE,GMT_MODIFIED |
| 年月 |
YEAR,MONTH |
|
| 狀態標志 |
PRODUCT_STATUS,ORDER_STATUS,IS_DELETE,VIP_FLAG |
|
| 類型 |
ORDER_TYPE,IMAGE_TYPE,GENDER,CURRENCY_TYPE |
|
| 區域 |
COUNTRY,PROVINCE,CITY |
|
| 操作人員 |
CREATOR,AUDITOR |
|
| 數值 |
LEVEL,AMOUNT,SCORE |
|
| 長字符 |
ADDRESS,COMPANY_NAME,SUMMARY,SUBJECT |
|
| 不適合建索引的字段 |
描述備注 |
DESCRIPTION,REMARK,MEMO,DETAIL |
| 大字段 |
FILE_CONTENT,EMAIL_CONTENT |
如何知道SQL是否使用了正確的索引？
簡單SQL可以根據索引使用語法規則判斷，復雜的SQL不好辦，判斷SQL的響應時間是一種策略，但是這會受到數據量、主機負載及緩存等因素的影響，有時數據全在緩存里，可能全表訪問的時間比索引訪問時間還少。要准確知道索引是否正確使用，需要到數據庫中查看SQL真實的執行計划，這個話題比較復雜，詳見SQL執行計划專題介紹。
索引對DML(INSERT,UPDATE,DELETE)附加的開銷有多少？
這個沒有固定的比例，與每個表記錄的大小及索引字段大小密切相關，以下是一個普通表測試數據，僅供參考：
索引對於Insert性能降低56%
索引對於Update性能降低47%
索引對於Delete性能降低29%
因此對於寫IO壓力比較大的系統，表的索引需要仔細評估必要性，另外索引也會占用一定的存儲空間。
1.2、只通過索引訪問數據
有些時候，我們只是訪問表中的幾個字段，並且字段內容較少，我們可以為這幾個字段單獨建立一個組合索引，這樣就可以直接只通過訪問索引就能得到數據，一般索引占用的磁盤空間比表小很多，所以這種方式可以大大減少磁盤IO開銷。
如：select id,name from company where type='2';
如果這個SQL經常使用，我們可以在type,id,name上創建組合索引
create index my_comb_index on company(type,id,name);
有了這個組合索引后，SQL就可以直接通過my_comb_index索引返回數據，不需要訪問company表。
還是拿字典舉例：有一個需求，需要查詢一本漢語字典中所有漢字的個數，如果我們的字典沒有目錄索引，那我們只能從字典內容里一個一個字計數，最后返回結果。如果我們有一個拼音目錄，那就可以只訪問拼音目錄的漢字進行計數。如果一本字典有1000頁，拼音目錄有20頁，那我們的數據訪問成本相當於全表訪問的50分之一。
切記，性能優化是無止境的，當性能可以滿足需求時即可，不要過度優化。在實際數據庫中我們不可能把每個SQL請求的字段都建在索引里，所以這種只通過索引訪問數據的方法一般只用於核心應用，也就是那種對核心表訪問量最高且查詢字段數據量很少的查詢。
1.3、優化SQL執行計划
SQL執行計划是關系型數據庫最核心的技術之一，它表示SQL執行時的數據訪問算法。由於業務需求越來越復雜，表數據量也越來越大，程序員越來越懶惰，SQL也需要支持非常復雜的業務邏輯，但SQL的性能還需要提高，因此，優秀的關系型數據庫除了需要支持復雜的SQL語法及更多函數外，還需要有一套優秀的算法庫來提高SQL性能。
目前ORACLE有SQL執行計划的算法約300種，而且一直在增加，所以SQL執行計划是一個非常復雜的課題，一個普通DBA能掌握50種就很不錯了，就算是資深DBA也不可能把每個執行計划的算法描述清楚。雖然有這么多種算法，但並不表示我們無法優化執行計划，因為我們常用的SQL執行計划算法也就十幾個，如果一個程序員能把這十幾個算法搞清楚，那就掌握了80%的SQL執行計划調優知識。
由於篇幅的原因，SQL執行計划需要專題介紹，在這里就不多說了。
1.創建用戶時，指定限額
oracle數據庫的內存結構比較復雜，下面對pga/sga/uga做比較分析。
1. sga組成:
database buffer cache:包括 default pool,keep pool,recycle pool；
redo log buffer
share pool:包括 library cache,dictionary cache
large pool
java pool
streams pool
fixed sga
2.pga組成：
1）sql工作區：sort area(排序區),hash area(構造hash表）,bitmap merge area(索引區)
2）uga區
3.pga和uga比較：
uga：user global area ，是會話含義的內存區
為了保證數據可以被會話訪問到，所以mts模式屬於sga中的大池，專有模式屬於pga，屬於用戶的內存區。
uga保存當前會話相關的信息，比如會話登錄信息、pl／sql包的參數信息,綁定變量的值。
pga：program global area，是操作系統含義上的內存區，
可以理解為操作系統在一個進程啟動時，為他分配的內存空間
查詢使用 show pga;
4.sga和pga比較：
sga：共享數據塊，所有進程可以訪問,數據並發訪問
涉及lock，latch,鎖定和隊列
是數據庫最主要優化區域，一些重要的指標：data buffer hit,library hit(hard/soft parse),hot blocks
pga：為專有進程服務，進程間無法數據共享，數據獨占
無需鎖定機制
性能優化只需要考慮它的大小。
---------------------
數據庫屬於 IO 密集型的應用程序，其主要職責就是數據的管理及存儲工作。而我們知道，從內存中讀取一個數據庫的時間是微秒級別，而從一塊普通硬盤上讀取一個IO是在毫秒級別，二者相差3個數量級。所以，要優化數據庫，首先第一步需要優化的就是 IO，盡可能將磁盤IO轉化為內存IO。本文先從 MySQL 數據庫IO相關參數（緩存參數）的角度來看看可以通過哪些參數進行IO優化：
- query_cache_size/query_cache_type （global） Query cache 作用於整個 MySQL Instance，主要用來緩存 MySQL 中的 ResultSet，也就是一條SQL語句執行的結果集，所以僅僅只能針對select語句。當我們打開了 Query Cache 功能，MySQL在接受到一條select語句的請求后，如果該語句滿足Query Cache的要求（未顯式說明不允許使用Query Cache，或者已經顯式申明需要使用Query Cache），MySQL 會直接根據預先設定好的HASH算法將接受到的select語句以字符串方式進行hash，然后到Query Cache 中直接查找是否已經緩存。也就是說，如果已經在緩存中，該select請求就會直接將數據返回，從而省略了后面所有的步驟（如 SQL語句的解析，優化器優化以及向存儲引擎請求數據等），極大的提高性能。當然，Query Cache 也有一個致命的缺陷，那就是當某個表的數據有任何任何變化，都會導致所有引用了該表的select語句在Query Cache 中的緩存數據失效。所以，當我們的數據變化非常頻繁的情況下，使用Query Cache 可能會得不償失。Query Cache的使用需要多個參數配合，其中最為關鍵的是 query_cache_size 和 query_cache_type ，前者設置用於緩存 ResultSet 的內存大小，后者設置在何場景下使用 Query Cache。在以往的經驗來看，如果不是用來緩存基本不變的數據的MySQL數據庫，query_cache_size 一般 256MB 是一個比較合適的大小。當然，這可以通過計算Query Cache的命中率（Qcache_hits/(Qcache_hits+Qcache_inserts)*100)）來進行調整。query_cache_type可以設置為0(OFF)，1(ON)或者2(DEMOND)，分別表示完全不使用query cache，除顯式要求不使用query cache（使用sql_no_cache）之外的所有的select都使用query cache，只有顯示要求才使用query cache（使用sql_cache）。
- binlog_cache_size （global） Binlog Cache 用於在打開了二進制日志（binlog）記錄功能的環境，是 MySQL 用來提高binlog的記錄效率而設計的一個用於短時間內臨時緩存binlog數據的內存區域。一般來說，如果我們的數據庫中沒有什么大事務，寫入也不是特別頻繁，2MB～4MB是一個合適的選擇。但是如果我們的數據庫大事務較多，寫入量比較大，可與適當調高binlog_cache_size。同時，我們可以通過binlog_cache_use 以及 binlog_cache_disk_use來分析設置的binlog_cache_size是否足夠，是否有大量的binlog_cache由於內存大小不夠而使用臨時文件（binlog_cache_disk_use）來緩存了。
- key_buffer_size （global） Key Buffer 可能是大家最為熟悉的一個 MySQL 緩存參數了，尤其是在 MySQL 沒有更換默認存儲引擎的時候，很多朋友可能會發現，默認的 MySQL 配置文件中設置最大的一個內存參數就是這個參數了。key_buffer_size 參數用來設置用於緩存 MyISAM存儲引擎中索引文件的內存區域大小。如果我們有足夠的內存，這個緩存區域最好是能夠存放下我們所有的 MyISAM 引擎表的所有索引，以盡可能提高性能。此外，當我們在使用MyISAM 存儲的時候有一個及其重要的點需要注意，由於 MyISAM 引擎的特性限制了他僅僅只會緩存索引塊到內存中，而不會緩存表數據庫塊。所以，我們的 SQL 一定要盡可能讓過濾條件都在索引中，以便讓緩存幫助我們提高查詢效率。
- bulk_insert_buffer_size （thread）和key_buffer_size一樣，這個參數同樣也僅作用於使用 MyISAM存儲引擎，用來緩存批量插入數據的時候臨時緩存寫入數據。當我們使用如下幾種數據寫入語句的時候，會使用這個內存區域來緩存批量結構的數據以幫助批量寫入數據文件：insert … select …
insert … values (…) ,(…),(…)…
load data infile… into… (非空表) - innodb_buffer_pool_size（global）當我們使用InnoDB存儲引擎的時候，innodb_buffer_pool_size 參數可能是影響我們性能的最為關鍵的一個參數了，他用來設置用於緩存 InnoDB 索引及數據塊的內存區域大小，類似於 MyISAM 存儲引擎的 key_buffer_size 參數，當然，可能更像是 Oracle 的 db_cache_size。簡單來說，當我們操作一個 InnoDB 表的時候，返回的所有數據或者去數據過程中用到的任何一個索引塊，都會在這個內存區域中走一遭。和key_buffer_size 對於 MyISAM 引擎一樣，innodb_buffer_pool_size 設置了 InnoDB 存儲引擎需求最大的一塊內存區域的大小，直接關系到 InnoDB存儲引擎的性能，所以如果我們有足夠的內存，盡可將該參數設置到足夠打，將盡可能多的 InnoDB 的索引及數據都放入到該緩存區域中，直至全部。我們可以通過 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 計算緩存命中率，並根據命中率來調整 innodb_buffer_pool_size 參數大小進行優化。
- innodb_additional_mem_pool_size（global）這個參數我們平時調整的可能不是太多，很多人都使用了默認值，可能很多人都不是太熟悉這個參數的作用。innodb_additional_mem_pool_size 設置了InnoDB存儲引擎用來存放數據字典信息以及一些內部數據結構的內存空間大小，所以當我們一個MySQL Instance中的數據庫對象非常多的時候，是需要適當調整該參數的大小以確保所有數據都能存放在內存中提高訪問效率的。這個參數大小是否足夠還是比較容易知道的，因為當過小的時候，MySQL 會記錄 Warning 信息到數據庫的 error log 中，這時候你就知道該調整這個參數大小了。
- innodb_log_buffer_size （global）這是 InnoDB 存儲引擎的事務日志所使用的緩沖區。類似於 Binlog Buffer，InnoDB 在寫事務日志的時候，為了提高性能，也是先將信息寫入 Innofb Log Buffer 中，當滿足 innodb_flush_log_trx_commit 參數所設置的相應條件（或者日志緩沖區寫滿）之后，才會將日志寫到文件（或者同步到磁盤）中。可以通過 innodb_log_buffer_size 參數設置其可以使用的最大內存空間。
注：innodb_flush_log_trx_commit 參數對 InnoDB Log 的寫入性能有非常關鍵的影響。該參數可以設置為0，1，2，解釋如下：0：log buffer中的數據將以每秒一次的頻率寫入到log file中，且同時會進行文件系統到磁盤的同步操作，但是每個事務的commit並不會觸發任何log buffer 到log file的刷新或者文件系統到磁盤的刷新操作；
1：在每次事務提交的時候將log buffer 中的數據都會寫入到log file，同時也會觸發文件系統到磁盤的同步；
2：事務提交會觸發log buffer 到log file的刷新，但並不會觸發磁盤文件系統到磁盤的同步。此外，每秒會有一次文件系統到磁盤同步操作。此外，MySQL文檔中還提到，這幾種設置中的每秒同步一次的機制，可能並不會完全確保非常准確的每秒就一定會發生同步，還取決於進程調度的問題。實際上，InnoDB 能否真正滿足此參數所設置值代表的意義正常 Recovery 還是受到了不同 OS 下文件系統以及磁盤本身的限制，可能有些時候在並沒有真正完成磁盤同步的情況下也會告訴 mysqld 已經完成了磁盤同步。 - innodb_max_dirty_pages_pct （global）這個參數和上面的各個參數不同，他不是用來設置用於緩存某種數據的內存大小的一個參數，而是用來控制在 InnoDB Buffer Pool 中可以不用寫入數據文件中的Dirty Page 的比例（已經被修但還沒有從內存中寫入到數據文件的臟數據）。這個比例值越大，從內存到磁盤的寫入操作就會相對減少，所以能夠一定程度下減少寫入操作的磁盤IO。但是，如果這個比例值過大，當數據庫 Crash 之后重啟的時間可能就會很長，因為會有大量的事務數據需要從日志文件恢復出來寫入數據文件中。同時，過大的比例值同時可能也會造成在達到比例設定上限后的 flush 操作“過猛”而導致性能波動很大。
- query_cache_type : 如果全部使用innodb存儲引擎，建議為0，如果使用MyISAM 存儲引擎，建議為2，同時在SQL語句中顯式控制是否是喲你gquery cache
- query_cache_size: 根據 命中率（Qcache_hits/(Qcache_hits+Qcache_inserts)*100)）進行調整，一般不建議太大，256MB可能已經差不多了，大型的配置型靜態數據可適當調大
- binlog_cache_size: 一般環境2MB～4MB是一個合適的選擇，事務較大且寫入頻繁的數據庫環境可以適當調大，但不建議超過32MB
- key_buffer_size: 如果不使用MyISAM存儲引擎，16MB足以，用來緩存一些系統表信息等。如果使用 MyISAM存儲引擎，在內存允許的情況下，盡可能將所有索引放入內存，簡單來說就是“越大越好”
- bulk_insert_buffer_size: 如果經常性的需要使用批量插入的特殊語句（上面有說明）來插入數據，可以適當調大該參數至16MB～32MB，不建議繼續增大，某人8MB
- innodb_buffer_pool_size: 如果不使用InnoDB存儲引擎，可以不用調整這個參數，如果需要使用，在內存允許的情況下，盡可能將所有的InnoDB數據文件存放如內存中，同樣將但來說也是“越大越好”
- innodb_additional_mem_pool_size: 一般的數據庫建議調整到8MB～16MB，如果表特別多，可以調整到32MB，可以根據error log中的信息判斷是否需要增大
- innodb_log_buffer_size: 默認是1MB，系的如頻繁的系統可適當增大至4MB～8MB。當然如上面介紹所說，這個參數實際上還和另外的flush參數相關。一般來說不建議超過32MB
- innodb_max_dirty_pages_pct: 根據以往的經驗，重啟恢復的數據如果要超過1GB的話，啟動速度會比較慢，幾乎難以接受，所以建議不大於 1GB/innodb_buffer_pool_size(GB)*100 這個值。當然，如果你能夠忍受啟動時間比較長，而且希望盡量減少內存至磁盤的flush，可以將這個值調整到90，但不建議超過90
Mysql優化總結
一、索引
1、創建索引：
（1）．ALTER TABLE
ALTER TABLE用來創建普通索引、UNIQUE索引或PRIMARY KEY索引。
ALTER TABLE table_name ADD INDEX index_name (column_list)
ALTER TABLE table_name ADD UNIQUE (column_list)
ALTER TABLE table_name ADD PRIMARY KEY (column_list)
（2）、CREATE INDEX
CREATE INDEX可對表增加普通索引或UNIQUE索引。
CREATE INDEX index_name ON table_name (column_list)
CREATE UNIQUE INDEX index_name ON table_name (column_list)
2、查看索引
mysql> show index from tblname;
mysql> show keys from tblname;
3、刪除索引
可利用ALTER TABLE或DROP INDEX語句來刪除索引。類似於CREATE INDEX語句，DROP INDEX可以在ALTER TABLE 內部作為一條語句處理，語法如下。
DROP INDEX index_name ON talbe_name
ALTER TABLE table_name DROP INDEX index_name
ALTER TABLE table_name DROP PRIMARY KEY
索引：http://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html
**explain +select ·····用來獲取select語句的執行的相關信息及索引的使用等
**describe table table_name;
**analyze table table_name;查看表的信息，幫助優化
**show 查看執行狀態
二、my.ini中的配置
http://www.chinaz.com/program/2009/1210/100740.shtml
mysql > show status; 可以查看具體的設置 服務器的狀態
具體的配置呀什么，沒有親自試驗過
三、數據表引擎
1、MyISAM：mysql默認的
2、InnoDB：支持事務、鎖、外鍵、聚簇索引
引擎介紹：http://blog.csdn.net/cheungjustin/article/details/5999880
http://limaolinjia.blog.163.com/blog/static/539162282011012145139/
四、索引的類型：
1、B-Tree索引
2、hash索引
具體的參考還是一）
五、事務
數據表引擎使用InnoDB
http://www.cnblogs.com/winner/archive/2011/11/09/2242272.html
六、存儲過程
經編譯和優化后存儲在數據庫服務器中，運行效率高，可以降低客戶機和服務器之間的通信量，有利於集中控制，易於維護 （P247）
http://blog.sina.com.cn/s/blog_52d20fbf0100ofd5.html
七、mysql profiling（mysql性能分析器）優化sql語句
查看SQL執行消耗系統資源的信息
++++需要開啟+++
具體使用：http://www.jiunile.com/mysql-profiling%E7%9A%84%E4%BD%BF%E7%94%A8.html
八、慢查詢日志
++++需要開啟++++
通過慢日志查詢可以知道哪些SQL語句執行效率低下，那些sql語句使用的頻率高等
對MySQL查詢語句的監控、分析、優化是MySQL優化非常重要的一步。開啟慢查詢日志后，由於日志記錄操作，在一定程度上會占用CPU資源影響mysql的性能，但是可以階段性開啟來定位性能瓶頸。
具體參考：http://blog.csdn.net/renzhenhuai/article/details/8839874
關於mysql的一些講解：http://www.ccvita.com/category/mysql