MySql在創建索引優化時須要注意的問題

什麼狀況下應該創建索引 索引優化及分析

表的主關鍵字
自動創建惟一索引
如zl_yhjbqk（用戶基本狀況）中的hbs_bh（戶標識編號）

表的字段惟一約束
ORACLE利用索引來保證 數據的完整性
如lc_hj（流程環節）中的lc_bh+hj_sx（流程編號+環節順序）

直接條件查詢的字段
在SQL中用於條件約束的字段
如zl_yhjbqk（用戶基本狀況）中的qc_bh（區冊編號）
select * from zl_yhjbqk where qc_bh=’<????甼曀???>7001’

查詢中與其它表關聯的字段
字段經常創建了外鍵關係
如zl_ydcf（用電成份）中的jldb_bh（計量點表編號）
select * from zl_ydcf a,zl_yhdb b where a.jldb_bh=b.jldb_bh and b.jldb_bh=’540100214511’

查詢中排序的字段
排序的字段若是經過索引去訪問那將大大提升排序 速度
select * from zl_yhjbqk order by qc_bh（創建qc_bh索引）
select * from zl_yhjbqk where qc_bh=’7001’ order by cb_sx（創建qc_bh+cb_sx索引，注：只是一個索引，其中包括qc_bh和cb_sx字段）

查詢中統計或分組統計的字段
select max(hbs_bh) from zl_yhjbqk
select qc_bh,count(*) from zl_yhjbqk group by qc_bh


什麼狀況下應不建或少建索引
表記錄太少
若是一個表只有5條記錄，採用索引去訪問記錄的話，那首先需訪問索引表，再經過索引表訪問數據表，通常索引表與數據表不在同一個數據塊，這種狀況下ORACLE至少要往返讀取數據塊兩次。而不用索引的狀況下ORACLE會將全部的數據一次讀出，處理速度顯然會比用索引快。
如表zl_sybm（使用部門）通常只有幾條記錄，除了主關鍵字外對任何一個字段建索引都不會產生性能優化，實際上若是對這個表進行了統計分析後ORACLE也不會用你建的索引，而是自動執行全表訪問。如：
select * from zl_sybm where sydw_bh=’5401’（對sydw_bh創建索引不會產生性能優化）

常常插入、刪除、修改的表
對一些常常處理的業務表應在查詢容許的狀況下儘可能減小索引，如zl_yhbm，gc_dfss，gc_dfys，gc_fpdy等業務表。
數據重複且分佈平均的表字段
假如一個表有10萬行記錄，有一個字段A只有T和F兩種值，且每一個值的分佈機率大約爲50%，那麼對這種表A字段建索引通常不會提升數據庫的查詢速度。
常常和主字段一塊查詢但主字段索引值比較多的表字段
如gc_dfss（電費實收）表常常按收費序號、戶標識編號、抄表日期、電費發生年月、操做標誌來具體查詢某一筆收款的狀況，若是將全部的字段都建在一個索引裏那將會增長數據的修改、插入、刪除時間，從實際上分析一筆收款若是按收費序號索引就已經將記錄減小到只有幾條，若是再按後面的幾個字段索引查詢將對性能不產生太大的影響。

對千萬級MySQL數據庫創建索引的事項及提升性能的手段

1、注意事項：
首先，應當考慮表空間和磁盤空間是否足夠。咱們知道索引也是一種數據，在創建索引的時候勢必也會佔用大量表空間。所以在對一大表創建索引的時候首先應當考慮的是空間容量問題。

其次，在對創建索引的時候要對錶進行加鎖，所以應當注意操做在業務空閒的時候進行。

2、性能調整方面：
首當其衝的考慮因素即是磁盤I/O。物理上，應當儘可能把索引與數據分散到不一樣的磁盤上（不考慮陣列的狀況）。邏輯上，數據表空間與索引表空間分開。這是在建索引時應當遵照的基本準則。

其次，咱們知道，在創建索引的時候要對錶進行全表的掃描工做，所以，應當考慮調大初始化參數db_file_multiblock_read_count的值。通常設置爲32或更大。

再次，創建索引除了要進行全表掃描外同時還要對數據進行大量的排序操做，所以，應當調整排序區的大小。
  9i以前，能夠在session級別上加大sort_area_size的大小，好比設置爲100m或者更大。
  9i之後，若是初始化參數workarea_size_policy的值爲TRUE，則排序區從pga_aggregate_target裏自動分配得到。

最後，創建索引的時候，能夠加上nologging選項。以減小在創建索引過程當中產生的大量redo，從而提升執行的速度。

MySql在創建索引優化時須要注意的問題 設計好MySql的索引可讓你的數據庫飛起來，大大的提升數據庫效率。設計MySql索引的時候有一下幾點注意： 1，建立索引 對於查詢佔主要的應用來講，索引顯得尤其重要。不少時候性能問題很簡單的就是由於咱們忘了添加索引而形成的，或者說沒有添加更爲有效的索引致使。若是不加 索引的話，那麼查找任何哪怕只是一條特定的數據都會進行一次全表掃描，若是一張表的數據量很大而符合條件的結果又不多，那麼不加索引會引發致命的性能下 降。可是也不是什麼狀況都非得建索引不可，好比性別可能就只有兩個值，建索引不只沒什麼優點，還會影響到更新速度，這被稱爲過分索引。 2，複合索引 好比有一條語句是這樣的：select * from users where area=’beijing’ and age=22; 若是咱們是在area和age上分別建立單個索引的話，因爲mysql查詢每次只能使用一個索引，因此雖然這樣已經相對不作索引時全表掃描提升了不少效 率，可是若是在area、age兩列上建立複合索引的話將帶來更高的效率。若是咱們建立了(area, age, salary)的複合索引，那麼其實至關於建立了(area,age,salary)、(area,age)、(area)三個索引，這被稱爲最佳左前綴 特性。所以咱們在建立複合索引時應該將最經常使用做限制條件的列放在最左邊，依次遞減。 3，索引不會包含有NULL值的列 只要列中包含有NULL值都將不會被包含在索引中，複合索引中只要有一列含有NULL值，那麼這一列對於此複合索引就是無效的。因此咱們在數據庫設計時不要讓字段的默認值爲NULL。 4，使用短索引 對串列進行索引，若是可能應該指定一個前綴長度。例如，若是有一個CHAR(255)的 列，若是在前10 個或20 個字符內，多數值是唯一的，那麼就不要對整個列進行索引。短索引不只能夠提升查詢速度並且能夠節省磁盤空間和I/O操做。 5，排序的索引問題 mysql查詢只使用一個索引，所以若是where子句中已經使用了索引的話，那麼order by中的列是不會使用索引的。所以數據庫默認排序能夠符合要求的狀況下不要使用排序操做；儘可能不要包含多個列的排序，若是須要最好給這些列建立複合索引。 6，like語句操做 通常狀況下不鼓勵使用like操做，若是非使用不可，如何使用也是一個問題。like 「%aaa%」 不會使用索引而like 「aaa%」可使用索引。 7，不要在列上進行運算 select * from users where YEAR(adddate) 8，不使用NOT IN和操做 NOT IN和操做都不會使用索引將進行全表掃描。NOT IN能夠NOT EXISTS代替，id3則可以使用id>3 or id 轉載（http://blog.sina.com.cn/s/blog_40e5b6370100f0vy.html）