比如在我們專案裡乙個表的資料量很大的時候，建立時間建索引，統計數量時，查詢7天的資料，如果加其他無索引的條件，例如 status=1的時候，耗時巨大。
此表在相同時間段內，插入的資料不平均，導致時間索引在整個時間內不均衡，即如上在查詢7天資料的時候，查詢出1月10-1月17的數量為700w+,1月20-1月27的資料為200w+,這樣在加入條件status=1後，掃瞄行數即為10-17的為700w+，即耗時時間為暴增。一次來看是用建立時間的索引來增加查詢效率並不理想。
此查詢主要分為3類：一類為使用者自己查詢，一類為後台查詢，最後一類為自動匹配查詢。
最後一類有聯和索引可以忽略。使用者自己查詢和後台查詢存在相同問題。使用者自己查詢會走使用者id的關聯索引，但是使用者id不是最優索引。即使用者自己查詢和後台查詢相同，在查詢的時候分為兩類，一種是無高效率索引字段查詢（可看做無條件查詢），一種是有高效索引字段查詢。在有高效索引字段查詢的時候，查詢效率很高，此中情況忽略。在無高效索引字段查詢的時候，會存在查詢慢的問題。此查詢拆分兩條sql,一條 取列表資料 有limit限制，即查詢時間較短，另一條為查詢數量的sql(此sql需要獲取總數量，在存在無索引欄位的時候查詢時間較長（status=1）)，即可得出在分頁查詢的時候查詢總數的時候慢（select count(*) …）。
實現統計資料量，每個使用者有效資料，無效資料，總資料以及所有資料的有效資料，無效資料。查詢數量的時候可以取這些統計的數量，即使用者查詢的時候取對應使用者的有效數，後台查詢的時候取所有資料的有效數。即在前端來看查詢結果一樣，也有對應的分頁，效率較高，目前資料來看會在1秒以內，而之前邏輯為15秒外。
第一條sql優化，在使用上述解決方案的時候，第一條sql在查詢較大頁數的時候會存在效率問題，此可以檢視limit的原理。例如：limit 5000000,100的意思掃瞄滿足條件的5000100行，扔掉前面的500w行，返回最後的100行，當然慢了。此sql優化方案。優化，在不存在status=1的情況下，只取id,50w資料的時間為160±ms,在500w的時候為1.6±s,即只能保證在5w也每頁10條的效率。取值先只取id的效率比取*的效率高，秒內相差10倍。
1，50w 1632ms,500w 15975ms
select * from goods_info limit 5000000,10;
2，50w 80ms,500w 788ms
select * from goods_info a where a.id >= (select b.id from goods_info b limit 5000000, 1) limit 10;
3，50w 82m,500w 786ms
select * from goods_info a join (select id from goods_info limit 5000000, 10) b on a.id = b.id;
Jar Hell 問題解決方案
最近看到溫紹錦的jvm基礎，裡面看到這個jar hell問題的解決方法，之前遇到過一次，是乙個資源檔案，當時覺得挺麻煩，不知道還有這個方法，很棒，特地整理了下，記錄到這裡來，這個部落格開了好長時間了，一直以來也懶得寫東西，以後會堅持更新些。classloader classloader thread...
top K問題解決方案
1.使用最大最小堆。求最大的數用最小堆，求最小的數用最大堆。2.quick select演算法。使用類似快排的思路，根據pivot劃分陣列。3.使用排序方法，排序後再尋找top k元素。4.使用選擇排序的思想，對前k個元素部分排序。5.將1000 個數分成m組，每組尋找top k個數，得到m k個數...
Ajax post亂碼問題解決方案
今天測試乙個ajax元件的時候遇到亂碼問題，在網上找了很多解決方案都未能解決，原因可能我出現亂碼的問題不在傳輸過程，而且是在頁面上就已經出現亂碼了，現象很奇怪，我直接把引數賦值為中文後alert，發現是亂碼，所以不管我怎麼設定和在後台解碼都依然是亂碼。後來找到原因，共分兩點 第一 我的meta標籤設...