eWEEK Labs/PC Labs 可以说是做基准测试的老大了，早在 1993年 10月份他们的姐妹杂志 PC Magazine 就做过同样的测试。这次和 PC Magazine 合作测试了五种数据库在 Java 应用服务器上的表现，结果显示 MySQL 最新的 4.0.1 版本性能可以和 Oracle 9i 媲美， 垫低的当然是微软的 SQL Server 2000 。 
测试的这五种数据库是：IBM 的 DB2 7.2 FixPack 5，微软的 SQL Server 2000 企业版 SP2， MySQL AB 的 MySQL 4.0.1 Max， Oracle 的 Oracle9i 企业版 9.0.1.1.1 以及 Sybase 的 ASE (Adaptive Server Enterprise) 12.5.0.1。
测试兼容性也是基准测试的一个主要目的，所有的数据库都在同样的硬件条件下测试：
HP NetServer LT 6000r 带有四颗 700MHz Xeon CPU， 2GB 内存以及 24 台 10000 rpm 的 9.1GB Ultra3 SCSI 磁盘，操作系统为 Windows 2000 Advanced Server SP2。
测试的应用程序是一个叫做 Nile 的基于 Web 的书店应用。Nile 采用了 Empirix 公司的测试套件 6.0 ，能加载 50 到 10000 个并发用户。
测试采用的应用服务器是 BEA 的 WebLogic 6.1 SP1，并用 JSP 编写了 Nile 应用。
每种测试运行一个小时产生五万张订单，15 万到 20万相关的记录数，我们得到的最好的伸缩性是在两台 6路 HP NetServer LT 6000r （ 4GB 内存，千兆网卡）服务器上运行6个 WebLogic 例程。HTTP 流量均衡的分配到这六个例程中。
测试的总体结果显示 Oracle9i 和 MySQL 有最好的性能和伸缩性，但是 9i 仅仅略微比 MySQL 好一些，ASE, DB2, Oracle9i 和 MySQL 到达 550 个并发用户时已经“力不从心”了，ASE 的性能下降到了每秒 500 个页面，比 9i 和 MySQL 要低 100 个页面，DB2 在高负荷情况下，性能下降也很厉害，只有每秒 200 个页面了。
由于 JDBC 驱动存在问题，SQL Server 在整个测试中都只能达到每秒 200 个页面。
驱动，内存优化和数据库设计问题是影响性能的主要因素，经过手工细调后的性能会和没有调优的性能差两倍。
Oracle 和 MySQL 的驱动具有完整的 JDBC 特色和稳定性（MySQL的员工采用了Mark Matthews 编写的 JDBC 驱动，因为他们没有自己的 JDBC 驱动程序）。
为各种数据库找到最好的内存配置是一件具有挑战性的工作，我们在这个问题上花了好几天。
SQL Server 和 MySQL 的配置最简单，而 Oracle9i 是最复杂的。 9i 采用了很多独立的内存缓冲，每个数据库连接需要消耗很大的内存（大约 400KB），而 DB2 只需要 177 KB， SQL Server, MySQL 和 ASE 都只需要 50KB 就够了，结果是 9i 的数据和执行计划的缓冲就比别的数据库要小。
MySQL 的高性能源自采用了内存内的查询结果集缓冲，这是 4.0.1 的新特色，我们不采用这个缓冲的话， MySQL 的性能会下降三分之二。另外， MySQL 的员工还根据表的不同采用不同的数据库引擎。
所有的订单表采用 MySQL 的 InnoDB 引擎（支持事务，行锁，多版本同步），目录和用户表则不需要事务支持，采用了 MySQL 的轻量的，非事务的 MyISAM 引擎。
MySQL 4.0.1 的新引入的高速查询缓冲引人注目，其他的数据库没有这个特色。如果查询的文本具有和缓冲中一模一样的匹配的话，MySQL 能直接从缓冲去数据，而不需要编译查询语句，取锁或者搜索索引，这项技术在表不被经常更新的情况下十分有用。
微软的 SQL 2000 虽然在 Java 平台上没有上好表现，但是当我们用 ASP.Net 重写基准测试，并采用 IIS 5.0 ，和 OLE DB 连接，得到的结果或许会让 Bill Gates 松口气，每秒 870 个页面。
在测试前，我们邀请五家公司派员参与测试，只有 MySQL 和 Sybase 欣然前往，IBM 只是答应通过电子邮件交流，微软和 Oracle 都拒绝参加。因此他们的数据库调整都是我们代劳的。
在测试中，我们惊奇的发现驱动程序是问题的最大根源。
在五种被测试的数据库中，只有 9i 和 MySQL 能连续运行 Nile 8个小时，DB2 的 JDBC 驱动不支持可更新的结果集，因此我们只能打开所有的结果集（采用 CONCUR_READ_ONLY），采用 SQL update 语句来更新，最终还是通过了 8个小时的稳定性测试。
在采用 Sybase 的 JConnect 5.5 驱动时，我们发现当应用请求的结果集包含双向游标时，JConnect 把整个结果集存储在客户端的内存里来增加后续游标的命令处理速度，这项工作在低负荷时还马马虎虎，但是当用户达到上百时，应用服务器消耗了几百兆的内存。 结果不到 8 个小时，我们的 6个 应用服务器进程统统挂起了。
为了解决这个问题，我们把应用的浏览逻辑重新改写，只采用前向游标（JConnect 不在客户端内存缓冲），为了保证查阅到前面的图书，我们需要把相同的查询运行两遍，得到图书的总数然后得到图书的数据，这样就影响了 ASE 的性能。
但是，这样做的结果是 ASE 的能整夜的跑基准测试，客户端能从 C/S 结构的应用中获益，但是对于应用服务器而言，这是一个可怜的选择。
微软的 JDBC 设计有缺陷，在 WebLogic 的控制台上我们发现每次 Java 虚拟机作garbage collection，释放出来的内存就少了一些，所以微软的 JDBC 驱动用不到 8 小时就歇菜了。