查詢：
db.comment.find().skip(0).limit(*).sort()
//按照ctime排序
沒有報錯，查詢時間不到1s
db.comment.find().skip(0).limit(*).sort()
//按照like排序
報錯：超時，發現查詢時間為2s到3s
此圖為無索引為什麼會出現這個問題呢？當時很困惑，ctime與like的級別是一樣的，都沒有加索引且都是int型資料，為什麼乙個查詢不到1s，乙個要2s＋?
突然一道金光射入我的腦子我一下就明白了！！
因為如果按ctime排序的話，這個陣列就為有序陣列，如果按like排序的話，這個陣列就為無序陣列。無序陣列排序比有序排序的時間複雜度要大。
note：一條記錄在新增時ctime是遞增的，而like是離散的數字
怎樣才能讓db.comment.find().skip(0).limit(*).sort()的查詢效率變高？
在不影響業務的情況下，我選擇了給like新增索引，但如何新增索引是個問題了。一般我們都知道不給選擇性低的字段新增索引，因為這個不能提高效率。那該如何做呢？
策略是建立組合索引包括這個低選擇性的字段。（即：選擇性高的字段＋選擇性低的字段）
方案一
db.comment.ensureindex()
//新增組合索引
此圖索引為從圖上看出，還是索引沒有起作用，這是因為組合索引中，用右邊的字段索引，索引不起作用。
方案二
db.comment.ensureindex()
//新增組合索引
此圖索引為發現效率明顯提高了很多
了解組合索引的優化原理請讀:10gen工程師談mongodb組合索引的優化
關於mysql資料庫索引
mysql選擇性 Mysql索引的選擇性
對於索引的使用，mysql並不一直都是用採用正確的決定的。參考乙個簡單的表 create table r2 id int 11 default null,id1 int 11 default null,cname varchar 32 default null,key id1 id1 engine ...
索引的選擇性
索引的選擇性是指索引列中不同值的數目與表中記錄數的比。如果乙個表中有2000條記 錄，表索引列有1980個不同的值，那麼這個索引的選擇性就是1980 2000 0.99。乙個索引的選擇性越接近於1，這個索引的效率就越高。如果是使用基於cost的最優化，優化器不應該使用選擇性不好的索引。如果是使用基於...
索引的選擇性
索引的選擇性是指索引列中不同值的數目與表中記錄數的比。如果乙個表中有2000條記 錄，表索引列有1980個不同的值，那麼這個索引的選擇性就是1980 2000 0.99。乙個索引的選擇性越接近於1，這個索引的效率就越高。如果是使用基於cost的最優化，優化器不應該使用選擇性不好的索引。如果是使用基於...