版本
2008年8月21日，完成测试1的Oracle_Win、Mysql_Li、Mysql _Win、MSSQL部分。
2008年8月22日，完成测试2的Oracle_Win、Mysql_Li、Mysql _Win、MSSQL部分。
2008年8月23日，文档整理。
2008年8月25日，完成postgresql linux版本的测试1、测试2。
2008年8月27日，完成postgresql windows版本的测试1、测试2。
1.背景
这不是数据库性能的综合测试，这里只测试插入，并且是用JDBC插入。这是针对某种应用的某模块的简单模拟，不可能适用所有的情况。
假设系统的基本情况是，有后台线程要不停的读取数据，并写入流水表，写入以后就不会update。没有人使用系统的时候，就没有查询，偶尔才会有人来使用。查询的时候，因为数据量比较大，性能优化也是一个重要的问题，但不在本文讨论范围之内。
本文还没有完成，测试3还没有进行，并缺少Oracle Linux版本和PostgreSQL的数据。计划将来补上。
2.测试方法
测试1，简单表测试
建立3个一模一样的小表，只有3个数字类型的字段，一个主键，没有另外建索引。对不同的数据库执行以下测试：
A.用1个线程写一个表
B.用2个线程同时写2个不同的表
C.用2个线程写同一个表
D.用3个线程同时写3个不同的表
E.用3个线程写同一个表
每50条为一批进行批量操作，每5秒进行一次采样，稳定运行一段时间以后，取每秒插入的数据条数进行比较。用多个线程并发进行操作可以检查对双核CPU的利用效果。
测试2，普通表测试
与测试1相同，但是表不一样，建立3个一模一样的表。表包含10个各种字段，另外再单独建3个索引。
测试3，超大表测试（TODO）
与测试1相同，但是表不一样，建立3个一模一样的表。表包含100个以上的字段，10个索引。系统中有类似这样的流水表。
3.环境定义
3.1.硬件环境定义
笔记本
CPU Core Duo T2350（双核，1.86G）
硬盘120G
内存2G
Java程序和数据库跑在一个机器上测试确实不太好，不过只有这样的条件。另外，在小型客户那里的生产环境，有把数据库和Java应用服务器安装在一个机器的情况，因此这样也能说明一些问题。
3.2.操作系统定义
Windows平台：Windows XP Pro SP2，文件系统NTFS
Linux平台：Ubuntu 8.04，文件系统EXT3
Windows 平台上已经尽可能停用了无关的程序，比如杀毒软件等。
CPU在负载低的时候会自动降频到800M，在Windows下，使用软件RMClock将主频强制稳定在1.86G，避免CPU频率调整可能带来的性能波动。Linux下没有做这个处理（因为不知道用什么软件）。
为了偷懒是在Eclipse里面运行的，不过应该没有太多的影响。程序在循环中没有生成垃圾对象，不清楚数据库驱动程序会不会，但是应该不会频繁GC吧。
3.3.待测试数据库环境定义
| 数据库 | OS | 缩写 | 说明 |
| Oracle 10g 10.2.01 | Windows | Oracle_win | JDBC驱动程序用的安装Oracle后自带的。先整理磁盘碎片，然后建立新的表空间和用户，数据表空间5G，临时表空间200M，重做日志文件3×50M。 |
| Oracle 10g 10.2.01 | Linux | Oracle_Li | |
| MS SQL Server 2005 SP2 | Windows | MSSQL | JDBC驱动程序为jtds1.2.2。磁盘碎片整理后建立数据库文件5G，日志文件100M。 |
| MySQL 5.1.26 RC | Linux | Mysql_Li | 存储引擎为InnoDB。JDBC驱动为mysql-connector-java-5.1.6-bin.jar |
| MySQL 5.1.26 RC | Windows | Mysql_Win | 存储引擎为InnoDB。JDBC驱动为mysql-connector-java-5.1.6-bin.jar |
| Postgresql 8.3.3 |
Linux | Pgsql_Li | JDBC3 Postgresql Driver, Version 8.3-603。 |
| Postgresql 8.3.3 |
Windows | Pgsql_Win | JDBC3 Postgresql Driver, Version 8.3-603。 |
数据库没有再做什么优化，简单的调整内存之类的参数，对测试结果基本没有影响。
4.测试结果
明细结果在附件（Eclipse工程）的result中。有的测试重复做过多次，基本上数据都是稳定的。
文件名命名规则是：数据库_s_线程数_表相同或不相同，s表示simple，n表示normal
输出每行表示一次采样，5秒1次，“本阶段平均”表示这5秒的平均速度，“共处理”是进程启动以后处理记录的总和，“平均”是根据启动后处理的记录总数和总时间计算出来的：
normal_evt 2170/s normal_evt 2050/s normal_evt 2170/s 本阶段平均6390/s 共处理3,1950条 平均6390/s
4.1.结果数据
测试1，简单表，3字段，1主键，无索引
| 条/秒 | 1线程1表 | 2线程2表 | 2线程1表 | 3线程3表 | 3线程1表 |
| Oracle_Li |
|||||
| Oracle_Win | 3,7205 | 5,6065 | 4,2437 | 5,0640 | 4,6861 |
| Mysql_Li | 1,0287 | 2,0449 | 1,2751 | 2,0397 | 1,4239 |
| Mysql_Win | 1020 | 1173 | 1167 | 1706 | 1671 |
| MSSQL | 2975 | 5584 | 5561 | 7705 | 7703 |
| Pgsql_Li | 1,3882 |
2,1870 | 2,2225 | 2,2402 | 2,4181 |
| Pgsql_Win | 1,0241 | 1,7287 | 1,7323 | 1,7153 | 1,8160 |
测试2，普通表，10字段，1主键，3索引
| 条/秒 | 1线程1表 | 2线程2表 | 2线程1表 | 3线程3表 | 3线程1表 |
| Oracle_Li | |||||
| Oracle_Win | 1,9989 | 2,2001 | 1,8419 | 2,2442 | 1,8643 |
| Mysql_Li | 5857 | 1,0226 | 5890 | 1,0204 | 6180 |
| Mysql_Win | 973 | 1152 | 1142 | 1685 | 1595 |
| MSSQL | 2692 | 5155 | 5150 | 7173 | 6922 |
| Pgsql_Li | 8763 | 1,1492 | 1,2935 | 1,0141 | 1,2517 |
| Pgsql_Win | 7043 | 9997 | 9671 | 1,2274 | 1,2645 |
4.2.结果分析
不同的数据库在不同的方式下表现不一样，取最好的成绩，结果是Oracle_Win > Mysql_Li > MSSQL >> Mysql_Win。具体情况可以看上面的表。
除了Oracle以外，其他的数据库插入的性能都很稳定。
CPU占用率通常在20%~60%之间，随着线程数的增加略有提高。
下面对单个数据库做分析：
4.2.1.Mysql_Li
mysql的特点是，当使用2个线程插入2个不同的表时，性能立刻提高了整整一倍，使用3个线程插入3个表的时候却，相比2线程2表没有提高。看起来，要用至少两个线程才能充分利用双核的两个CPU（其实是4个线程，2个java线程，2个数据库线程，但是java线程资源占用率较小，主要瓶颈还是在数据库）。
当使用多个线程同时入1个表时，性能只是稍微有点提高。
4.2.2.Mysql_Win
都说Mysql Windows版本性能不行，没想到差那么多。但是有两个很有意思的特点（MS SQL差不多也有这样的特点）：第一是测试2的数据比测试1几乎没有下降，而测试2的表要复杂的多，看来mysql有个瓶颈在我们不知道的地方，使得面对一个很简单的表，速度也上不去；第二是不断增加线程，性能始终能够提高，后来我又做了4线程和5线程的测试，仍然如此，不过提高的幅度越来越小。
4.2.3.Oracle_Win
插入性能很不稳定。如果把采样时间缩短为1秒，会发现大部分时间性能是基本稳定的，但每隔一小段时间，会基本失去响应（插入速度能降低到200以下），估计是重做日志的切换引起的，Oracle重做日志是3×50M。
随着数据量的增加，性能稍有下降，因此每次测试先都先truncate表，测试1的5次运行每次都在单表数据量达到1000w时结束测试，测试2在500w时结束测试。尚未测试在极大的数据量情况下会怎么样，但oracle在这种情况下的表现应该是久经考验的，估计可能到了一定的程度会稳定吧。
oracle的数据相当的好，并且其他数据库往往需要增加线程来获得更好的成绩，而oracle在1个线程的情况下能得到相对最好的成绩，增加线程以后提高不多。
当使用2个线程入2个表时，测试1提高50%，测试2略微提高。3个线程入3表则没有提高。
多个线程入同一个表的时候，测试1性能只有一些提高，而测试2竟出现了下降，但这种情况也不是不可思议的，测试2有10个字段，包括主键有4个索引，多个线程可能在争夺资源中出现了锁定。
cpu占有率波动很大，通常在10%~70%左右以大约20秒的周期剧烈波动，随着线程数的增加，占有率稍有上升。cpu占有率低时，写入速度也急剧下降，应该是切换重做日志引起。
最初做Oracle这个测试的时候，是把表建在一个已经有很多数据的表空间里面。后来，做碎片整理，然后新建表空间和用户，再测试，性能提高了30%。
4.2.4.MSSQL
MSSQL的特点和Windows下的Mysql差不多，测试1和测试2数据相当，似乎有别的瓶颈。刚开始的时候，数据真是非常可怜（与它假象的对手oracle相比），不过在增加线程后出现了可观的提高，不然就要沦落为和Mysql_win一个量级了。
4.2.5.Pgsql_Li
Postgresql的数据比mysql略高。
4.2.6.Pgsql_Win
postgresql在windows下性能只出现了少量下降。有一个特点是在3个线程的时候CPU占用率接近到100%。