1：只對 where 和 order by 子句中需要的列新增索引，多餘的索引智慧型導致不必要的硬碟空間愛你消耗。
每次修改表資訊時會更新索引，因此有索引的表效能會相應降低。
2：對於要使用索引的列要使用屬性 not null ， 這樣就永遠不會儲存 null 值。
3：最好用唯一化索引，一般情況下，當查詢優化程式發現某個資料在超過30%的行裡都有出現時，通常會不使用索引而進行全盤掃瞄。
4：索引長度盡量短。如果要對乙個字元型新增索引，比如給 char(50) 字段新增索引，如果它的前10個位元組不同而後面的基本相同，那麼可以支隊這前10個位元組建立索引
這樣能減少索引多佔的空間，又可以加快檢索速度。
5：要充分利用最左側字首，這是針對復合索引而言的，例如對某錶中的 c1 , c2 , c3 三個列建立了乙個復合索引，索引項的順序為 c1 , c2 , c3
可在查詢時支隊 c2 , c3 作為條件，那麼基本上是用不到所建立的復合索引，因為他們都沒有做左側的 c1 字段， 在對一下條件進行檢索時會使用該索引
c1 , c2 , c3
c1 , c2
c1編輯結束；
從接觸php以來 一直沒做過真正的大型專案，頂多就做一些 **啊 ~ 個人部落格呀 ~ 中介網啊 這種小型**。
最近在做乙個**網，體積不大，但是我手裡的資料量不大不小 ~
前幾天為了乙個查詢 兩表互聯 例如 表 a 和表 b 進行 a right join b 的時候沒什麼異常。
但是由於查詢結果不是很理想 應當用 a left join b 才是對的。結果這乙個聯表 給我聯了 好幾分鐘都沒有回應。
分析後發現，2個表相聯的條件是 a 表的主鍵 和 b 表的乙個儲存 a 表id列 即 a left join b on a.id = b.aid
而b.aid 沒有索引。 當我給 b.aid 加上索引 在查詢結果發現 恢復了原來的速度。查詢沒有任何異常。
對索引 一直是 只是了解而並非真正的體驗過。 因為當我學會索引的時候 我沒有特意的用迴圈給2個表加10萬條資料進行聯表的測試。
這次的經驗 我知道 原來 索引是這麼的重要。
今天我想徹底對mysql索引進行了解。結果在網上蒐集了一些資料 一下的我對索引的解說
mysql 索引
普通索引 index
唯一索引 uniqe
全文索引 fulltext
其中 主鍵也是唯一索引。這個應該誰都知道。
首先建立兩個表 分別是 a1 和 a2 每個表中只有乙個字段 id 沒有設定索引 每個表有5000條記錄
(其實最初我拿10000萬條資料測試 結果等的不耐煩了，改了5000條也等了一小會呢 呵呵)
開始聯表
select * from a1 left join a2 on a1.id = a2.id
耗費時間如圖
現在給兩個列增加索引 在試一試
alter table a1 add index(id);
alter table a2 add index(id);
結果很明顯，快了多少我就不說了。想象一下，如果你的資料量達到幾萬甚至幾十萬的情況下
在你是初級程式設計師的階段 還不了解 mysql索引的情況下 明明sql語句沒有問題 一查就是漫長的進度條 會不會很鬱悶啊。。 呵呵
就算有索引和無索引有如此大的差距 ， 但也別有 每個列 都要加索引的念頭。因為索引壞處被他的好處給掩蓋了。
索引列的資訊是儲存在 索引檔案中，資料表中的資料是儲存在資料檔案中。
據我了解 聯錶帶索引的表時速度快的原因 是因為 帶有索引的列 在索引檔案中會被排序。
例如數字1 - 5000 而沒有索引的列在資料表中是沒有排序的。
因此我在聯兩個表時 a1.id left a2.id 的時候 a2中的id 和 a1中的id 互相匹配的過程中 他們會來回 5000 x 5000 次
由於沒有索引列沒有排序過，在實際聯表時 因為是 left join 所以 首先 a2.id 要和 a1.id 的 1號相匹配
那麼在第一次匹配的時候 a2.id 的 1號 和 a1.id 的1號匹配了。但此時 匹配並非停止 a2表中的還會繼續往下找
檢查 1號下面的 id 是否還是 1 以此類推 他在和 a1.id 中的 1號相聯的時候 他匹配了 5000次
當與 a1.id 的 2號匹配的時候 還是一樣會去匹配 5000次。
而對有索引的列來說 因為索引列的資料排序過，會忽略不必要的匹配 所謂排序(據我了解) 當我給 a2.id 加索引的那一刻
索引檔案中的 a2.id 這個列 會把所有資料 從大到小排序 即 1 - 5000
那麼在聯表時 當 a2.id 的 1號跟 a1.id 1號相匹配之後 明確知道 接下來在a2.id 中在沒有 1號了 直接會跟
a1.id 的2號開始匹配 一次類推 結果 他只匹配5000次。
也就是說 在沒有索引的情況下 上面的聯表會進行 2500萬次的匹配，而設定索引之後 僅匹配 5000次。
由於上述測試是使用 left join ，事實上只需要給 a2 的 id 加索引就可以了。給 a1.id 加索引是多餘了。
誰適合加索引？ 簡單來說的話 where 條件中的列 或 left join on 列 = 列 時 看聯表方向 此時是 第二個列適合加索引。
那麼誰又不適合加索引呢？ 列的資料重複率較高的列和修改率較高的列。
原因是，重複列較高的列，例如 性別，他只有 男 和 女 這2個資料 如果設定了索引，那麼只會增加無用的磁碟空間。
把男女排序了 也就是 男 和 女 這2個資料，設定索引 沒有任何意義。
修改率高的列，上面說過，索引是會排序的，那麼如果把修改率高的列設了索引 那麼每一次修改操作結束之後
索引檔案也會重新排列所有資料，這樣以來 雖然在查詢時能提高效能上的問題，但是在修，增的時候並非如此。
多列索引
如果目前有乙個使用者表，分別有 姓名 ， 年齡 ， ** 等列 (假設這些列是最常被查詢的)
有乙個使用者管理頁中有乙個搜尋部分 會根據 輸入的 姓名 ， 年齡 ， ** 來搜尋此人的詳細記錄。
那麼這個時候到底給那乙個列加索引比較好呀？ (因為mysql一次只能使用乙個索引，據我了解)
此時可以使用多列索引
alter table user add index user_age_phone(user , age , phone)
建立多列索引之後 如查詢
where user='abc' and age = 25 and phone = 1234
mysql 直接會匹配 user = 'abc' 這一項 在去匹配 age = 25 這一項 接著去匹配 phone 這一樣，三個條件 僅僅3次匹配就得到結果了。
那麼如果不使用多列索引的話 我們也只能給其中的一項列建立索引，假設 我們給 user 列建立了索引，那麼當執行上述查詢之後
因為 user 被設有索引 因此 找到 abc 只需要一次匹配 之後的操作 他首先會排除 年齡不是 25歲的記錄 在去排除 **不是 1234 的記錄。
這麼以來 雖然 比 沒有任何索引的情況好了很多 但是最終查詢結果並非是理想。
至於什麼列需要家索引，什麼列不需要加索引 只能在實際情況中分析了。
【索引的使用】
在一下幾種情況下 mysql 在查詢中即使有索引也不會去使用
1：在多列索引，查詢條件中用的不是最座標的列，那麼此時是不會使用索引。
2：like查詢時 % 出現在第一位也不會使用索引
3：條件中有 or 也不會使用索引。
4：索引列型別是字串，可在查詢中省略了 引號(有時字串型別列也會儲存數字)，此時不會使用索引
5：如果 mysql 估計使用全表掃瞄比使用索引快，他也不會使用索引。
【如何檢測所建立的索引是否有效(或者說索引使用情況)】
show status like 'handler_read%'
handler_read_key 越高越好
handler_read_rnd_next 越高越不好
Win10磁碟整理在哪裡？Win10磁碟整理怎麼用
首先，請大家在win10系統桌面上對著 站擊右鍵，在彈出的選單中點選選擇 屬性 按鈕，開啟 站屬性頁面。開啟 站屬性設定頁面之後，請確保沒有關閉 站功能，即選擇檔案刪除操作之後是將檔案放入 站而非直接刪除，如果開啟直接刪除檔案功能的話，win10系統中的磁碟清理功能將預設處於關閉狀態。接下來，請大家...
win7磁碟整理碎片怎麼操作
整理方法 首先點選頁面底部的 開始 選單按鈕，在彈出的選單欄中點選 所有程式 選擇 附件 然後點選 系統工具 雙擊開啟 磁碟碎片整理程式 選擇需要進行碎片整理的磁碟 最後選擇 磁碟分析 點選 磁碟碎片整理 即可。點選win7電腦開始選單，然後在彈出的選單欄中點選所有程式，找到 附件 點開選單欄的 附...
mysql 整理索引 Mysql索引整理
1 mysql基本單位是頁，大小為16kb 16384 1024 頁是為了增加查詢效率，減少io的互動 區域性性原理 2 頁與頁之間是雙向鍊錶，插入的時候會根據主鍵id進行排序 單葉資料結構.jpg 3 在頁上有乙個頁目錄，相當於把資料進行分組，存放的是當前組最小的主鍵id，指標並且指向對應的資料 ...