database no sharding

不止一次看到簡歷上寫著從事過XX專案，分庫分表。但凡這樣寫的有以下幾種可能：

1、胡說八道的

2、看別人有抄的

3、簡單做過（反而最有問題，才多少資料量就分庫分表？可見沒有最佳化能力）

4、真正場景需要（這種人應該在國內TOP20的公司不會找我面試）

    隨便國內找一個ACE級別的（無論是Oracle MySQL還是PG的）都不會一上來就勸人家分庫分表。專家都知道1000萬以下，甚至1億以下都不叫事。

     我記得好幾年以前接到過一個電話，對方說在招人，我說我不換工作。對方說可以談談技術嘛？我說隨便說兩句可以。對方說如果1000萬的大表查詢很慢怎麼辦？

     我心中基本猜出大概了，這家公司能力不行啊。區區1000萬就慢，往後日子別過了。我大概給他們說了一下，應該如何如何。對方一聽就說，你就是我們要的人，來吧。我說不去。這家公司叫善林金融。聽過的朋友舉個手。

     我是因為後來這家公司出事了才聽過的。原來是業務和技術都有問題。

     以前在DTCC有人就在會場問，如果一個表1000萬查詢很慢怎麼辦？嘉賓一般回答都會這樣說：“不會的，去看看一定是索引沒建好。”

    分庫分表問題太多了。弊大於利。

    1、按照一個維度分了，那麼只要不是按照這個維度的查詢，必然跨庫。

    2、需要一箇中介軟體知道怎麼分的，當然沒有太好的中介軟體，有時候開發自己在程式中判斷（自己挖坑自己埋）

    3、不是一個庫一致性沒有保障（備份恢復一片和其他所有片對得上嗎？）

    4、不是一個庫排序沒有保障

    5、不是一個庫鎖沒有保障

呼蘭在程式設計師吐槽大會上說：產品經理舉個手，相當於問不懂技術的舉個手。

同樣一上來就說分庫分表的相當於說，我不打算用索引了，我就打算要用機器抗