经常听人说数据库IO性能不好，但毕竟没有感性认识。下面我们来实际测试下常用的Oracle和MySQL的JDBC读取性能。之所以测试JDBC，是因为大部分应用都是用JAVA写的，所以JDBC只能用来访问数据。这里我们只测试使用JDBC读取数据，生成Java记录对象（毕竟在应用中只能用到这一步），不做任何计算。1、数据源使用TPCH生成的数据，测试时选择customer表。数据记录为3000万行和8个字段。它生成的原始文本文件名为customer.tbl，文件大小为4.9G。使用数据库提供的数据导入工具将该文件中的数据导入到Oracle和MySQL的数据表中。2、测试环境测试在一台Intel服务器上完成，2颗Intel2670CPU，主频2.6G，共16核，内存64G。数据库表数据和文本文件存储在同一个SSD硬盘上。所有测试均在服务器本地完成，无需消耗网络传输时间。3、数据库读取测试使用Oracle提供的JDBC接口，用SQL语句执行数据读取。Java写起来比较麻烦，测试用SPL脚本执行：MySQL的测试代码类似，这里不再赘述。第二次的测试结果（时间单位：秒）可能会更快，因为操作系统有硬盘缓存。因为我们主要测试JDBC的读取时间，所以以第二次为准，减少数据库本身从硬盘读取的影响。每秒读取的行数也是按照秒计算的，也就是说Oracle每秒可以读取10万多行数据，MySQL大约是8万行。当然这个值和表中字段的数量和类型有关（customer表有8个字段），只是一个参考。4.文本文件对比仅从上面的数据量来看，我们并没有多少感性认识。让我们再次阅读文本文件进行比较。方法是一样的，从文件中读取数据，解析出记录，不做任何计算。编写如下SPL脚本执行测试：测试结果为42秒！这意味着读取文本比读取Oracle快281/42=6.69倍，比MySQL快381/42=9.07倍！我们知道文本解析是一件很麻烦的事情，但即便如此，从文本文件中读取数据要比从数据库中读取快很多。Oracle和MySQL的IO实在是太慢了！5.二进制模式我们再进一步看看使用二进制模式的存储格式的读取性能，并与文本进行比较。为了便于对比，这次换一个更大的表，使用TPCH中的orders表，有3亿行数据，9个字段。文本阅读的代码与上面类似，阅读时间测试为438秒。然后，我们把这个文本文件转换成一个SPL组表，然后写了一个代码测试：测试结果是164秒，大约只有文本阅读的三分之一。这是一件合理的事情，因为二进制数据不再需要解析，直接生成对象即可，计算量少很多，所以速度更快。需要注意的是，虽然表文件采用了列存格式，但是这里读取的是所有的列，而且内容不比正文少，并没有发挥列存的优势。事实上，因为读取所有列，使用列存储会吃点苦头，如果使用SPL集文件（一种行存储格式）会更快。6.并行提速通过从文件中取数据也很容易实现并行，对于文本表和组表都可以很容易地编写并行程序。还是以上面的订单表为例进行测试，使用4个线程取号。文本访问代码：组表访问代码：用SPL很容易实现数据切分和并行计算。测试结果为：text119秒grouptable43秒与serial相比，接近线性提升，充分利用了CPU的多核。数据库中的数据不容易简单地实现分段并行。它需要使用WHERE条件拼写出来。结果很难判断是并行度不够还是WHERE执行损失太大。测试结果的参考意义会打折扣，这里就不做了。向上。7、结论数据库（Oracle和MySQL）的JDBC性能非常非常差！它比文本文件差5倍以上。当使用二进制数据时，读取性能将比文本提高3倍。也就是说，一个格式合理的二进制文件将比数据库有15倍以上的优势。考虑到并行因素，完全有可能比数据库快几十、几百倍。当关心性能和数据量很大时，不要从数据库中读取数据进行计算！如果真的需要读出来再计算（有时候用SQL写复杂的过程计算很难），就不要用数据库来存了（大数据都是历史，基本不会再改了，可以提前读出来），用text都比数据库强，当然用binary更好（推荐SPL组表，哈哈）。不要将时间浪费在阅读等非计算任务上。
