這個問題是2016年的問題，現在是2021年底，GPU資料庫已經基本GG了。我解釋下一些基本的原因。
資料庫的「瓶頸」是個非常復雜的問題，把資料庫瓶頸歸結於IO肯定是不準確的，因為每個資料庫系統、每種workload的瓶頸都不一樣。通常來說，我們把資料庫分為TP(事務)和AP（分析）。GPU資料庫的目標場景是AP，所以我們的討論限定在AP場景。我說下GPU的一些核心缺點。
- 視訊記憶體不足。 GPU的視訊記憶體空間比較有限，復雜的AP SQL通常是比較吃記憶體的。正常情況下，如果記憶體不足就要落盤，涉及到落盤的場景GPU就搞不定了 。還有一些其他方面的原因，展開講就需要討論很多細節了。阿裏內部的同學可以去ATA看下我的文章，有詳細分析。
- 並行不足 。資料庫通常是高並行場景，GPU處理不了。
- 不劃算 。即使是AP資料庫，瓶頸也不是都在計算上。有的SQL瓶頸可能在網路，有的可能在計算，有的在IO。花大價錢買了GPU卻只能加速計算，其實是很不經濟的。有這個預算可能不如升級下ECS的規格。
- 現有的AP資料庫，計算的瓶頸普遍不在硬體上 。做硬體加速的前提，是軟體的最佳化空間已經被壓榨幹凈了。但是目前的分析性資料庫系統（OLAP）的軟體效能遠遠沒有被壓榨幹凈。雖然已經有很多論文研究了很多資料庫計算引擎的最佳化方法（SIMD，向量化，codegen等），但是產品實踐上落地的還非常少。尤其是國內資料庫圈子，真正懂資料庫引擎的人少之又少。隨便誰看了兩篇文章都可以評論下資料庫計算引擎該怎麽設計，但是大多數人實際上連概念都搞不清楚。
5. 系統設計理念問題 。資料庫系統普遍對通用性要求非常高。比如今天有個使用者有10種workload(T0-T9)，資料庫不需要每個workload都跑的很完美，但是至少需要每個都能跑。如果用GPU加速資料庫，由於我上文提到的種種原因，結果很可能是：T0/T1跑的很好，T3-T5效能還不如CPU，T6及以上由於視訊記憶體不足等原因跑不通。這種情況對於一個資料庫產品來說，顯然是無法接受的。
澄清一下，我沒有針對GPU啊，我是說「硬體加速」這個idea在資料庫領域，都不work。
