linux伺服器
mysql 5.7
某個業務表資料量有2億多條，由於一開始設計的時候就做了分表，所以當前單錶資料有一千多萬。mysql單錶到一千多萬的時候，整體效能就會下降，特別是count這類查詢具體如下：
圖中可以很明顯的看出，即使走索引字段，但是count欄位也是要30秒以上，如果再稍微卡一下，那就更慢。具體業務流程的時候，列表查詢一次需要大約2分鐘才展示，而且是展示分頁的30條資料。這個使用者體驗就很差了。
今天我只是從業務的角度來說明解決方案，並不從mysql引數調優方面來說明。
首先業務流程中設計到count這個動作，對於2億的資料來說，確實是很慢，我的思路是直接用一張表來儲存表中當前的最大記錄值，如果是需要count的時候，直接去這個表中獲取這個值進行展示，不需要去整表count操作。
改完業務**實踐了一下，原來2分鐘才展示的頁面，現在是要1秒鐘就刷出來，使用者體驗也就上來了。
至於sql優化和mysql引數調優，我後面會再慢慢整理。
海量資料處理
1 有一千萬條簡訊，有重複，以文字檔案的形式儲存，一行一條，有 重複。請用5分鐘時間，找出重複出現最多的前10條。方法1 可以用雜湊表的方法對1千萬條分成若干組進行邊掃瞄邊建雜湊表。第一次掃瞄，取首位元組，尾位元組，中間隨便兩位元組作為hash code，插入到hash table中。並記錄其位址和...
海量資料處理
給定a b兩個檔案，各存放50億個url，每個url各占用64位元組，記憶體限制是4g，如何找出a b檔案共同的url？答案 可以估計每個檔案的大小為5g 64 300g，遠大於4g。所以不可能將其完全載入到記憶體中處理。考慮採取分而治之的方法。遍歷檔案a，對每個url求取hash url 1000...
海量資料處理
分而治之 hash對映 hash統計 堆 快速 歸併排序 300萬個查詢字串中統計最熱門的10個查詢。針對此類典型的top k問題，採取的對策往往是 hashmap 堆。hash統計 先對這批海量資料預處理。具體方法是 維護乙個key為query字串，value為該query出現次數的hashtab...