来运行这些测试的脚本文件是¤here中的一个修改的版本。我所改良的版本是连接在这页上的。但是我本人不是一个TCL程序员，我所修改的版本只是由于数据库的需要。如果你看到一些错误影响了测试的结果，请你发送你的结果到这里。

所有的数据库都有自己默认的设置。如果是SQLite，我就使用二进制。

测试所运行的环境是1.6GHz Sempron，1GB随机存取内存，7200rpm SATA 硬盘， Windows 2000 + SP4 和所有的更新材料。

考虑到SQL的一些细小的变化，原来的测试脚本被改变了，因而可以使之在所有的数据库引擎下都可以运行。如果是MySQL，我就必须改变 CREATE TABLE 语句，使之可以使用InnoDB and MyISAM 存储引擎，如果是InnoDB引擎则关闭自动更新数据库模式（即使文档要求BEGIN自动执行，但实际上却不是如此）如果是Firebird 我则必须把BEGIN改成SET TRANSACTION.
除了上述情况外，所有的数据库使用同样的SQL执行。

所有的SELECTs在一个行里被执行三次，平均的时间在结果中显示。

我不知道如何在windows下如何刷新磁盘缓冲器。这个脚本使用 Linux中的sync命令来执行刷新过程。如果你知道如何在windows下执行刷新，请告知我。你也许在{link: ¤http://www.checksum.org/ cso/downloads/ from here}调试NTSync。

如果你想要个除了数字的解释，我建议你读¤original tests. 那里所讲的大部分在这里都是使用的。

我觉得在测试6中服务器也许做了下列操作：

  CREATE INDEX t1_b ON t1(b);
  CREATE INDEX t2_b ON t2(b);
  SELECT t1.a FROM t1 INNER JOIN t2 ON t1.b=t2.b;
  DROP INDEX t1_b;
  DROP INDEX t2_b;

上面的查询，当在同样的数据库里运行时，就像测试6中的查询，可以在0.5 秒内完成，而不是14+秒。 事实上它比测试7的时间还要快一点，但这是由于可变的运行时间状态。

我不太清楚测试8中的Postgres有什么问题， 如果你知道的话，并且如果你认为那个特殊的测试使Postgres有问题是因为连接了SQL，请你告知我。

A Speak UP: Postgres是用来默认安装的，在shoebox上运行。如果被使用在默认设置中用来做一系列的测试，它运行的并不太理想。Postgres只有一个 sync模式来保证ACID的一致性。Postgres依据它静态数据库中的数据来决定如何执行查询。数据只有通过"Analyze" 命令来更新。其他数据库也许用不同的命令来跟踪那些数据。在其他无事务处理的插入测试中，如果想看到一个7200 RPM的驱动在0.7 秒内做1000 次的I/O操作是非常困难的。 sync会强制每个事务处理程序在硬盘里执行，它就是每个INSERT操作。

Reply: 从测试开始运行后，Postgres的conf文件就被调试了一些。我正在把conf文件连接到所有数据库，这样任何人都可以评论并提出修改意见，因而在 sync测试中的ACID一致性方面使所有数据库都使用大致相同的硬件资源和函数。一旦所有数据库的输入都被收集到的时候，我将重新执行测试。
在实际操作中，Postgres在每个查询之前就运行ANALYZE到底是不是很经常呢？如果是的话，我将更新测试脚本使之在每个测试前运行ANALYZE。
测试1是非常奇怪的，这一点我也同意。如果每个处理程序只使用一个fsync，理想中完美的数据库也要用8秒以上的时间来完成这个测试。

Another speak UP :-) : 在大量插入或大部分行被更新后分析表格。产生的统计量将允许planner为SELECTs -选择一个最有效的查询计划。一个典型的例子就是一个充满数据的表格具有数百万个记录，如果之前从没被分析过， planner也许认为表格只有100行，然后从目录扫描中按顺序来扫描表格，但这也许会和实际上的表格大小相差甚远。还要注意的是， PostgreSQL在高并发加载数据时表现的非常出色。我也考虑到扩大测试，这样你就可以在同一时刻在多个事务处理程序中有数十个连接既读又写数据。可 以在性能更优越的硬件上把测试扩展到数百个甚至数千个连接。

Reply: 对于ANALYZE，在表格发生重大变化后，我将尽全力做我所能做的，并把它加入到测试脚本中。我认为这点我还是能做到的。我计划把ANALYZE花费的 时间包含到对Postgress测试中。我认为这是非常合理的，因为没有任何的其他数据库有这样特殊的措施，并且AFAICT ANALYZE是非常快的。
不需怀疑的是，Postgres在高并发性的测试中会表现得很出色。但如果你需要数百个同步的复写器或读卡器，你则不太可能对SQLite感兴趣。所以，到现在为止，我还没有运行这些测试的意向。

关于结果的一些注释：

• 时间是以秒为单位的，它代表了背景时钟的时间。
• nosync如果是SQLite就意味着SQLite用PRAGMA synchronous=OFF运行; ，如果是MySQL则意味着表格的类型是MyISAM。
• sync如果是SQLite意味着SQLite用PRAGMA synchronous=FULL; ，如果是MySQL就意味着表格的类型是InnoDB。

Comment: 你可以通过安装postgresql.conf中的'fsync = false' 来关闭PostgreSQL中的syncing (ie: nosync)。 这个安装不是很轻松，但是这会便于和其他数据库中你正在关闭或打开的sync做对比。另外，在变化很大的表格中运行analyze是很普遍的。通常情况 下，PostgreSQL认为使用中的表格的行自始至终是被插入的，被更新的和被删除的，而通常的运行的规模和统计量是不变的。因为整体的统计量不会变化 很多，所以你可能不会在every查询前运行analyze。 但你可能运行 'vacuum analyze' 来标记一些可以替换的行和更新统计量。在表格有些改动后，这样的测试对analyze非常有意义。如果表格是可以再生的（行可以更新和被删除），应该运行 vacuum and/or vacuum full 。 测试8如果不运行analyze可能会出现一些问题， Postgres不使用索引也许是因为它运行默认统计量，这意味着只有100行或像100行这样的情况下有顺序的浏览会更快一些。 另外一个优点是每个查询都用'explain analyze'来重新运行Postgres并同时提供输出量，以此来验证正在使用的查询计划。

Reply: nosync测试运行起来很简单，这样可以使SQLite的开发者和使用者对之有更好的理解。 MySQL被加入到mix，因为AFAIK对于MYSQL的运行来说是一个特别常见的设置。此外，我对sync的表现非常感兴趣，因为它是最常见的操作模 式。对于MySQL中的Except ，我不知道三年中它会不会改变。

Comment:我下拉网页postgresql.conf注意到你打开了行级别的数据统计。这对于有许多查询的测试来说是有些负面影响的。为什么你这样做？
另外我建议一些测试的准备好的语句版本在支持它的数据库里运行。

Reply: 我认为我没有改变它，也许他是默认装成那样的。我所做的改动只是在邮寄目录中，这里是相关参考：

  shared_buffers=10000
  effective_cache_size=100000
  work_mem=10000
  vacuum_cost_delay=50
  autovacuum=on
  autovacuum_vacuum_scale_factor=0.2

关于应答的说明: Postgres 8.x 的默认装置definitely有

  #stats_row_level = false

在他们默认的设置中，你应该关闭row stats collector，从新运行测试。

关于测试

Test 1: 1000 INSERTs

CREATE TABLE t1(a INTEGER, b INTEGER, c VARCHAR(100));
INSERT INTO t1 VALUES(1,13153,'thirteen thousand one hundred fifty three');
INSERT INTO t1 VALUES(2,75560,'seventy five thousand five hundred sixty');
... 995 lines omitted
INSERT INTO t1 VALUES(998,66289,'sixty six thousand two hundred eighty nine');
INSERT INTO t1 VALUES(999,24322,'twenty four thousand three hundred twenty two');
INSERT INTO t1 VALUES(1000,94142,'ninety four thousand one hundred forty two');