錯誤資料導致優化器不識別（高階優化手法用盡，結果盡然是這樣）

自己原文公眾號： https://mp.weixin.qq.com/s/Zt2_WCCi0V0Y82NzWKx7lQ

有個人找到我說語句太慢。語句核心部分是這樣的。我提煉一下。

SELECT * FROM log a WHERE a.create_time >= to_date('2018-01-01', 'yyyy-mm-dd') AND a.create_time <= to_date('2021-06-30', 'yyyy-mm-dd')。我第一反應你這個查3年必然慢。當然事情如果就這樣簡單，就不用寫這個帖子了。因為我讓他試了一下我查一年和查3年的執行計劃居然是一樣的。更加想不到的是查一個月和查3年也是一樣的，都是全表。

       看到這裡大家第一反應是沒索引對嗎？這個我當然也想到了。我讓他看了一看有的。而且看這個SQL的語法就知道是Oracle的。索引對型別也對。

       那麼干擾執行計劃的最大可能是統計資訊，我讓他看了一下也是不久前收集的，應該問題不大。但是抱著奇葩的心理就奇葩來一下。這裡考驗的就是幹不幹做了？憑藉經驗這個壓力不大因為全表資料才幾千萬（表不過億在我這裡都不好意思叫大表）。反饋給我果然7秒完成了。定睛一看執行計劃，它居然是紋絲不動。

      那麼索引有問題？儘管Oracle可以線上create index還可以開並行，但是這個我覺得操作比統計資訊重太多了。等低峰時候在做，告知他先等等。在這期間我想到了直方圖。發現了點問題。這個時間怎麼才兩個桶？不科學啊。

難道說讓我遇到了可遇不可求的高階問題？經常看高手們如何推算統計資訊以及玩轉資料分佈，這次終於有機會看看了。不過多年工作中Oracle的統計資訊和直方圖一直很給力，雖然看到過一些極端案例有問題，但是我自己沒遇到過。後來我讓他嘗試了我的想法，給出了直方圖的更改。

     直方圖針對列做了以後終於不是2個了，達到了我的預期。再過來看執行計劃，快哭了。還是依舊。在直方圖做的時候順帶也線上重建索引了。也就是說中高低端的手法基本都用了，沒效果。我估計今天要折在這裡了。

    好吧，既然如此怎麼都不給面子，那麼就抱著最後一絲希望讓我們來看看這些資料長什麼樣子吧？抽了10條資料一看。

很好很好。原來樣本資料說明了一切。我讓開發把語句改成了。

SELECT * FROM log a WHERE a.create_time >= to_date('2021/08/01', 'yyyy/mm/dd') AND a.create_time <= to_date('2021/08/30', 'yyyy/mm/dd')。這次結果是我們預期的了。

     主要原因是有些程式寫入的時候時間格式不是標準的格式，而我們用標準格式去查到了年以後就是比/和-後面都沒有用了。所以這就是之前為什麼直方圖就2個。只有2020和2021。即使我強刷直方圖也沒用。好在這個表沒有即使/又是-的。

    雖然解決了，差點以為是妖孽問題。要是隻處理後臺我估計就無法解決了，最後是實地考察解決了問題。Oracle的統計資訊和直方圖還是給力的。當然MySQL和PG這些也是可以的。