這其實都算不上最佳化

    很多場景下，我覺得加索引這個其實都不能算是最佳化。
    多年前聽到一個故事說一個DBA去了銀行，回來被一個銀行裡面稱之為大神。DBA的同事們說來給我們講講你怎麼最佳化的？該DBA說，實在說不出口啊。我僅僅是加了一個索引而已。而已，而已，而已。
    我們在工作中有兩類最常見：一類是沒建立索引，比如我剛才說的。這種連開發都知道應該建立索引。一個幾億的表，一查就慢，開發自己也知道不建立索引說不過去了。都會主動的加對應的索引。
    今天我還遇到一個問題，開發過來說建立個索引吧。我說你看看這個邏輯呢？開發看後直搖頭，這種沒有用。

     那麼就是我們說的第二類。就是索引在那裡，但是select的時候沒用他。比如select * from t where a!='完成'。因為完成和未完成都不少。一般來說索引也建立在不去經常修改的列上。少初級開發會寫出上述的SQL，因為他理解是查詢未完成的就是查詢全部未完成的。語法上沒錯就行。至於是不是看看3年前未完成的要不要處理？他不管。如果問他要不要每次都看看一年前的未處理？智商正常的通常會想想說，應該不用，那麼就未處理的不用每次都去看。但是我們也不能排除這個世上就有一根筋的，他們會說要的，就是從最開始的那條做起。（這種是揹著牛頭不認賬的，可能心裡知道錯了，但是嘴上一定死扛）遇到後者這種，我的建議是不要繼續說下去了。不在一個世界中。

    今天這個處理未完成的場景，我建議加個時間，每次檢檢視看一個月內有沒有未完成。其實這種每5分鐘的定時任務，每次看當天有沒有就足夠了。這樣改了以後效能大概提升了20倍左右。不過這種太過基礎，我依然覺得這種都不能算是最佳化。感覺是我大學剛畢業時候處理的一樣。到2022年了，這種問題其實在全國依然很普遍。

    昨天晚上在TiDB的版主會上，大家群情激奮的討論最佳化器，都很專業。只是看到SQL時候，我覺得我都心疼最佳化器，這寫的實在是不講道理。論最佳化器而言大家公認Oracle做的最好，那麼沒有Oracle那麼強大最佳化器的資料庫我們就要好好的去寫一些質量高的SQL才行。SQL的質量就是決定了系統的質量。