資料庫效能的賣家秀和買家秀

     好幾天沒寫了，這段時間積累了一點要說的問題。 上週遇到華為的一個朋友，在提及資料庫的時候很多效能指標。首先我不懷疑他的指標，我覺得十有八九就是真的。現在只要拿出的資料，基本都靠譜。因為如果離譜的資料，同行會質疑的。不過我說了一下就是在實際環境中，通常使用者連這個百分之一的都達不到。這不是說產品不行，而是使用者不行。

     我們資料庫從業者爭論資料庫效能看哪些指標，集中式還是分散式。（昨天看還到一篇文章寫分散式和集中式的TPS和QPS等對比），至於看TPS、 QPS還是看RT等，一時半會很難說服對方。而我剛才說的實際環境中其實不管看哪個指標，都沒達到。這是因為官方的資料都是實驗室的理想資料，而實際環境是非常惡劣的。我國現狀是應用開發人員對資料庫不瞭解，需求怎麼說我就怎麼做。實際上需求的邏輯都錯了，他也不管。再加上資料庫沒有好的設計，SQL幾千幾萬行，甚至一個SQL上百MB也有。這些來自使用者實際使用的毒打，導致資料庫什麼效能都是被摁在地上摩擦了。

     從前POC可能就是做幾百條資料,現在大家被忽悠多了，都有心眼了.有可能測的時候資料量1000萬級別甚至是上億的資料量。曾經看到了幾個國產資料庫的廠商吐槽說使用者測試他們的產品要求1000萬的表不建立索引測試效能。廠商覺得委屈。但是其實這是我們國內現狀。因為大部分業務場景即使用Oracle，也是沒索引的。這就是國內現狀。說白了只管功能，效能不是他的考核指標。只要功能邏輯對了就行。不過在我處理各個企業的一些問題時候發現。有的時候功能邏輯都不對。

    所以使用者知道自己現狀是什麼，很少能控制開發質量的。那麼在A資料庫上亂寫能抗住，那麼換B資料庫別指望應用開發改程式。一樣亂寫就看能不能支援了。不能支援的就不考慮了。

    這就是我說的資料庫效能的賣家秀（認為設計師良好的，開發是高水平的），而實際上是隻有廠商想不到的，沒有開發人員做不到的。笛卡爾積瞭解一下？需要經歷一下現實的毒打。

    我們看到TPCC的資料驚人，那是沒見到我們真實環境的表設計、需求和SQL。用這個情況去套TPCC，別說打榜了。當機不當機還一說呢。

   華為有個朋友說，希望我提供一下真實使用者的場景看看他們產品怎麼預防。我看到了不一樣的華為產品態度。他們不是說自己遙遙領先的那夥。我對他們的態度表示讚賞。我別的沒有，這方面的血淚教訓太多了，而這些在網際網路公司是不多見的，這和企業的基因有關。

   基於以上的結論，亂寫導致的效能問題，在分散式資料庫上OB和TiDB等也會出現問題，這個和單機還是分散式沒有關係。迪麗熱巴穿的好看的衣服，一個200斤的人去穿，別說好看了，衣服會不會OOM被撐開都兩說，這和單獨上衣還是連衣裙沒關係。主要是現狀是大家身材管理都不到位。

   可能只有重視起來和管理到位才能減少和避免這類問題的發生，比如現在酒駕就幾乎見不到了。到了這種時候，再談資料庫效能怎麼測試以及分散式和集中式的效能。