比 ORACLE 快 N 倍不稀奇，这么轻才是王道
Oracle 是普遍使用的数据库，它不是专业的分析型数据库，在数据量较大时常常会计算性能不佳，影响用户体验。现在有不少新的分析型数据库在性能上比 Oracle 更快，甚至可以说远超。那么在 Oracle 性能不足时，替换成这些数据库看起来就能解决问题了。
事情却没这么简单。
首先，这些新数据库通常并不能完全替代 Oracle。Oracle 并不只是用于 OLAP，还会用于 OLTP，而这些跑得更快的分析数据并没有 OLTP 的能力（支持 OLTP 的新数据库，包括 HTAP 鼓吹者，如果不借助更大的集群，却未必能比 Oracle 跑得快了），于是就要和 Oracle 共存，摆上两个数据库。
退一步讲，即便当前的 Oracle 只用于 OLAP，也不见得能被完全替代。Oracle 对复杂 SQL 的支持相当好，优化也做得很好，之所以慢，主要是因为同时要支持 OLTP，无法采用列存。这些新数据库如果占不到列存便宜时（全表大部分列都要被引用到），面对很多复杂 SQL 时，因为优化经验不足，在同样硬件资源下还不见得跑得过 Oracle，经常也要借助集群才行。另外，Oracle 还有超强的存储过程功能，这也是很多新数据库欠缺的能力，如果应用中有这类运算，也仍然要继续用 Oracle 了。
不能全部替代，就意味着需要有两套数据库，各自做各自擅长的运算，总体看起来用户体验能变得更好。
再退一步讲，即便新数据库在功能性能上都能完全替代 Oracle，那还有一个迁移风险的问题。对于，实际正在跑的业务，也不敢贸然全部迁到新数据库上，一般也要采用两库并存逐步迁移的方案。
还有商务问题，使用 Oracle 的通常是高端商用用户，一般也会采购商用数据库，这是一笔不菲的成本。这类用户对引入新数据库这类架构调整的事务也非常谨慎，很难做到随时扩容，经常会一次性买够数年的容量，这在前期又会造成浪费。
| esProc SPL | StarRocks | ClickHouse | Oracle | |
| q1 | 9.7 | 14.0 | 15.4 | 114.3 |
| q2 | 1.3 | 0.6 | 17.3 | 1.9 |
| q3 | 8.8 | 9.8 | 内存溢出 | 165.8 |
| q4 | 4.9 | 5.7 | 内存溢出 | 158.4 |
| q5 | 8.9 | 13.1 | 内存溢出 | 174.5 |
| q6 | 4.5 | 3.9 | 4.8 | 126.7 |
| q7 | 10.5 | 12.4 | 内存溢出 | 181.5 |
| q8 | 6.9 | 8.3 | 内存溢出 | 209.7 |
| q9 | 16.8 | 21.3 | 内存溢出 | 256.0 |
| q10 | 8.3 | 11.1 | 58.3 | 195.6 |
| q11 | 0.9 | 1.3 | 6.7 | 8.7 |
| q12 | 4.9 | 4.8 | 10.7 | 186.0 |
| q13 | 12.1 | 21.3 | 134.1 | 33.3 |
| q14 | 3.3 | 4.6 | 10.2 | 170.0 |
| q15 | 4.7 | 7.1 | 11.2 | 161.8 |
| q16 | 2.7 | 2.9 | 4.0 | 10.8 |
| q17 | 5.3 | 4.2 | 44.6 | 156.5 |
| q18 | 6.4 | 20.8 | 内存溢出 | 416.8 |
| q19 | 5.8 | 6.0 | >600 | 144.1 |
| q20 | 5.2 | 5.2 | 31.2 | 171.0 |
| q21 | 11.9 | 14.5 | 语法错误 | 360.7 |
| q22 | 2.5 | 1.9 | 8.4 | 37.7 |
| 总计 | 146.3 | 194.8 | - | 3441.8 |
可以看出，因为不是专业的分析型数据库，Oracle 的计算性能确实不占优，但功能全面，所有题都能跑出来。详细测试报告可参考 SPL 计算性能系列测试：TPCH 。
