这个问题是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。
