任何拋開業務談大資料量的sql最佳化都是瞎扯

標籤：

周三去某線上旅遊公司面試。被問到了一個關於資料量大的最佳化問題。問題是：一個主外部索引鍵關聯表，主表有一百萬資料，外部索引鍵關聯表有一千萬的資料，要求做一個串連。

本人接觸過單表資料量最大的就是將近兩億行曆史資料（某電訊廠商一業務一年資料）做查詢，所有查詢相關列必須做索引，而且還要保證不會出現全表掃描情況。也從來沒有試過把這麼多資料全部拿出來放記憶體中。只好回答說“再怎麼做最佳化估計都不行，這資料量太大了，效能肯定吃不銷。我只能告訴儘可能的添加過濾條件，不要一次用這麼多的資料來做串連，能分批做就分批做吧”。

面試人員告訴我，比如說我們的機票業務，我們只把北上廣熱門城市的放在緩衝中，即時重新整理即可。其他的每次去查詢資料庫即可，不必一次把所有的資料全部串連出來放到記憶體中。

我只能呵呵了，沒有業務讓我去最佳化一個sql，這不是扯淡麼。

 

關於這種大資料量最佳化問題，讓我理解最深刻就是分表做法。因為我們公司有個業務需要即時上傳資料，每天小百萬資料，而且還要做查詢。於是分表來做，每天產生一張表，然後把前一天的表添加索引，查詢的時候可以根據日期來擷取表名。盡量少查詢當天資料，因為沒有索引比較慢。添加索引的話因為即時插入資料，索引的維護代價比較大，所以選擇第二天添加前一天表的索引。

任何拋開業務談大資料量的sql最佳化都是瞎扯