本文只針對mysql進行相關方面的說明。
首先我要問，「資料索引是有序無序的？」。答：「當然是有序的了。」
再問，乙個sql語句可以有幾個索引？你先別往下看結果，你這想下,可以使用幾個索引呢？
正確的是：「1個」。有人肯定會疑惑。對，當初我接受這個概念也是挺納悶的，後來在實際中得到了解答。那麼，你需自己找答案了。
在有序的情況下，通過索引查詢乙個資料是無需遍歷索引記錄的；
極端情況下，資料索引的查詢效率為二分法查詢效率，趨近於 log2(n)；
在進行索引分析和sql優化時，可以將資料索引字段想象為單一有序序列，並以此作為分析的基礎。
如以下的sql，如何進行優化呢？
1
select*fromuserwherearea=』$area』and***=』$***』orderbylastlogindesclimit 0,30;
假設，這是在高訪問量的情況下，高頻率的情況下如何進行優化？
答：建立復合索引.
area+***+lastlogin 三個欄位的復合索引,如何理解？
1 如果只使用area會怎樣？搜尋會把符合area的結果全部找出來，然後在這裡面遍歷，選擇命中***的並排序。 遍歷所有 area=』$area』資料。
2 如果使用了area+***，略好，仍然要遍歷所有area=』$area』 and ***=』$***』資料，然後在這個基礎上排序。
3 area+***+lastlogin復合索引時（切記lastlogin在最後），該索引基於area+***+lastlogin 三個字段合併的結果排序。
不知道到這你是否看明白沒有？？這個不妨你在本地打個環境。自己動手試試看。
下面我用我自己的工作中的案例說下，這索引前後的區別：
我們有個業務需求是這樣的：
select*from`cu_banuser`whereuid =386264andfid =2orderby`endtime`
1 這是一張表結構 如圖。此表只有乙個主鍵作為索引。
那麼我們用explain看下吧: 關於explain，強烈建議：請大家自己baidu，有必要去了解認識它。
explainselect*from`cu_banuser`whereuid =386264andfid =2orderby`endtime`
下面的是其explain的結果：
看到其中的 type possible_keys 尤其是rows了嗎?影響的結果集是2751行。
2 我們現在將uid做為索引：
再explain下：
看劃線的，你們會驚喜的發現 rows已經是2了。證明我們的努力沒有白費。
3 我們繼續新增剩下的索引fid；
好，我們再explain下，看結果：
你會發現什麼呢？呵呵，對了rows=1了。
4 繼續給endtime加索引
explain看下：
我們的rows=1了，很明顯的如果在大資料量的情況下，我們的獲得的成果是很可喜的！我們一切從大數量出發。
好，不知道你注意到開篇就提到的2個問題吧？第二個問題是什麼？乙個sql用幾個索引？答案是1個。
看到這，不知道你有沒有感悟出來呢？我們在實際工作中用到最多的就是復合索引！
這就是你為什麼看到上圖的框中的索引是這麼建的!
補充下 從最好到最差的連線型別為 ：
const、eq_reg、ref、range、index和all
綜上所述：
1 乙個sql只用乙個索引；
2在實際工作中用到最多的是復合索引；
3 復合索引有嚴格的順序之分；
4 遵循偏左原則
；
MySQL資料庫臨時提高效能的方法
連線數量超過max connections時，新來的連線會被拒絕。這時有一些臨時解決辦法 注意這些辦法都是有損的 kill掉那些占用連線但未進行事務操作的執行緒，注意如果資料庫端主動斷開連線，客戶端是不能立刻感知的。讓資料庫建立連線時跳過許可權驗證階段，重啟資料庫，並使用 skip grant ta...
Redis高效能資料庫
redis高效能資料庫 redis 本質上是乙個非關係型資料庫，採用鍵值的方式記錄資料，由於其獨特的執行模式和資料儲存模式，在作用上通常可以用來當做關係型資料庫的快取來使用，從而提高資料查詢效率 redis最大特點 執行速度很快 原因 1 redis使用c語言開發，和作業系統的相容性更強，執行效率更...
提高資料庫效能
一 問題的提出 在應用系統開發初期，由於開發資料庫資料比較少，對於查詢sql語句，複雜檢視的的編寫等體會不出sql語句各種寫法的效能優劣，但是如果將應用系統提交實際應用後，隨著資料庫中資料的增加，系統的響應速度就成為目前系統需要解決的最主要的問題之一。系統優化中乙個很重要的方面就是sql語句的優化。...