周三去某在線旅游公司面試。被問到了一個關(guān)于數(shù)據(jù)量大的優(yōu)化問題。問題是：一個主外鍵關(guān)聯(lián)表，主表有一百萬數(shù)據(jù)，外鍵關(guān)聯(lián)表有一千萬的數(shù)據(jù)，要求做一個連接。

本人接觸過單表數(shù)據(jù)量最大的就是將近兩億行歷史數(shù)據(jù)（某運營商一業(yè)務一年數(shù)據(jù)）做查詢，所有查詢相關(guān)列必須做索引，而且還要保證不會出現(xiàn)全表掃描情況。也從來沒有試過把這么多數(shù)據(jù)全部拿出來放內(nèi)存中。只好回答說“再怎么做優(yōu)化估計都不行，這數(shù)據(jù)量太大了，性能肯定吃不銷。我只能告訴盡可能的添加過濾條件，不要一次用這么多的數(shù)據(jù)來做連接，能分批做就分批做吧”。

面試人員告訴我，比如說我們的機票業(yè)務，我們只把北上廣熱門城市的放在緩存中，實時刷新即可。其他的每次去查詢數(shù)據(jù)庫即可，不必一次把所有的數(shù)據(jù)全部連接出來放到內(nèi)存中。

我只能呵呵了，沒有業(yè)務讓我去優(yōu)化一個sql，這不是扯淡么。

?

關(guān)于這種大數(shù)據(jù)量優(yōu)化問題，讓我理解最深刻就是分表做法。因為我們公司有個業(yè)務需要實時上傳數(shù)據(jù)，每天小百萬數(shù)據(jù)，而且還要做查詢。于是分表來做，每天生成一張表，然后把前一天的表添加索引，查詢的時候可以根據(jù)日期來獲取表名。盡量少查詢當天數(shù)據(jù)，因為沒有索引比較慢。添加索引的話因為實時插入數(shù)據(jù)，索引的維護代價比較大，所以選擇第二天添加前一天表的索引。

轉(zhuǎn)載于:https://www.cnblogs.com/qishiguilai/p/4265239.html

總結(jié)

以上是生活随笔為你收集整理的任何抛开业务谈大数据量的sql优化都是瞎扯的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。