我上一个回复说“这只是掩盖了问题而已”，现在你成功掩盖了90%以上的问题。上面没细说我为什么得到这么个结论，这回掰开详细说说。
-
为什么会出现OOM异常？
OOM有两种情况，一种是执行引擎检测到某个查询所需要的内存超过了配置中的限制，从而主动抛出OOM异常；另一种是执行引擎申请的内存数量超过操作系统可用物理内存，从而被OS杀掉进程，这是种被动OOM。很不幸的是我在TiDB中这两种OOM都遇到过，前者是“Out Of Memory Quota!”，在这个讨论 TiDB 5.4面对业务方超级复杂的大SQL，直接Out Of Memory Quota! - TiDB / 部署&运维管理 - TiDB 的问答社区 (asktug.com)中我表明了观点。而后者被动OOM则是代码内存管理缺陷，没有节制地分配内存，并且没做好缓存的淘汰策略导致的问题。 -
为什么说出现OOM是执行引擎不够优化的表现？
举例来说，如果我要排序的数据有1G，可以直接申请1G内存，用快速排序，这种代码在绝大多数电脑上都能搞定。但如果我要排序的数据有10G，在8G内存的电脑上就会OOM了。如果我的代码多考虑一些情况，在检测到内存不够用的时候将中间结果先保存到硬盘，用外排序算法，那么只用几十MB的内存就能完成任务，代码再优化一些1T数据也能搞定。
你的建议是用升级到64G内存，如果我的业务中99%的任务排序都不超过60G数据，那升级确实解决了99%的问题。但是大数据时代有一个基本的前提：数据是无法在单独一台服务器中存储并计算的。或者说，数据规模增长的速度远高于硬件性能增长的速度。不管你64G甚至是256G，都远远小于数据规模。分布式数据库的理念就是为了解决这个矛盾：一台存不下我存到多台，一台内存不够用我就同时利用多台的内存。数据太大就加CPU、加内存的理念是IOE（IBM、Oracle、EMC）解决方案的典型观点，几TB的内存只是小型机的门槛，这在某些领域仍然适用，但不是分布式数据库解决扩展性问题的思路。
TiDB很好地解决了分布式系统存储容量问题以及存取性能问题，但OOM的问题反应了TiDB还没有解决单节点内存不够用的问题。也就是说，TiDB存在单点内存瓶颈。这在大数据时代OLAP领域是个硬伤。
再说点乐观的话题。TiDB目前存在的OOM问题不是架构上的问题。相反，TiDB的存算分离与MPP架构是我最看好的分布式数据库架构。OOM问题是完全可以解决，也是以后一定要解决的问题。在这方面MapReduce和Spark都是很好的参考。
讲了这么多，最后再总结一下我的核心观点：OOM反映的本质问题是TiDB的OLAP引擎需要优化，而硬件、配置的优化只能解决一部分问题，但解决不了单点内存瓶颈这一本质问题。