一次分割槽查詢異常的分析

    節前我處理了一個問題。先上圖，可以看出來查詢這個表，有兩個條件，一個是code一個是實際。最終執行查了5000萬行資料。歷時900秒。當然最後也是查了個寂寞，沒查到。

對於5000萬掃查了900秒，這個我既能理解，又不能理解。

能理解的是掃描5000萬用900多秒，說的過去。 不能理解是。從2022年1月開始到現在這個表一共才2億條。 我每月一個分割槽，查詢一個星期，怎麼也在月的分割槽中。那個code的一個星期資料在150萬左右。不應該會查到5000萬。

即使不帶code，一個星期也就700萬。

不過我依然相信這個5000萬是實際發生的。

我當時就想一個月大不了就700萬，要到5000萬，那要8個700萬差不多。

等等，說到這裡，我似乎發現了什麼。七八五十六啊，因為差不多現在這個表也就是八九個分割槽的樣子。

那麼我只查code發現大約4300萬左右。那麼說明在實際查詢過程中，那一個星期資料的code資料，被認為只有一個星期而沒有code。而在這種情況下，一個星期的和平時一個月資料量大致相等，又變成了跨所有分割槽執行。

是不是bug我不好說。因為不是每次都這樣。這情況倒是第一次遇到。在Oracle中只要時間落在一個月度中的，是不會產生跨月度分割槽的。

這可能是最佳化器不同，Oracle最佳化器目前還是最厲害的。

也許看到這裡有人說MySQL的分割槽不好，不過我用到現在也就是這個場景出了跨分割槽的問題。如果時間選擇不是一週，而是3天或者5天，是沒有問題的。或者說一週的資料量和一個月資料量相差很遠，不造成資料庫誤判也是沒有問題的。

MySQL分割槽還是利大於弊。