公司网站建设怎么,wordpress导入不了,怎么做科技小制作视频网站,便宜质量好的国产手表返回#xff1a;SQLite—系列文章目录
上一篇#xff1a;用于 SQLite 的异步 I/O 模块#xff08;二十四#xff09;
下一篇#xff1a;SQLite—系列文章目录 注意#xff1a;本文档非常非常旧。它描述了速度比较 SQLite、MySQL 和 PostgreSQL 的古老版本。
这里… 返回SQLite—系列文章目录
上一篇用于 SQLite 的异步 I/O 模块二十四
下一篇SQLite—系列文章目录 注意本文档非常非常旧。它描述了速度比较 SQLite、MySQL 和 PostgreSQL 的古老版本。
这里的数字已经变得毫无意义。此页面仅保留 作为历史文物。
摘要
进行了一系列测试来测量 SQLite 2.7.6、PostgreSQL 7.1.3 和 MySQL 3.23.41。 以下是一般情况 从这些实验中得出的结论 SQLite 2.7.6 明显更快有时高达 10 或 比默认的 PostgreSQL 7.1.3 安装快 20 倍 在 RedHat 7.2 上执行最常见的操作。 SQLite 2.7.6 通常更快有时 比 MySQL 3.23.41 快两倍以上 对于最常见的操作。 SQLite 执行 CREATE INDEX 或 DROP TABLE 的速度不如 其他数据库。但这并不被视为问题因为 这些都是不常见的操作。 如果将多个操作组合在一起则 SQLite 效果最佳 单个事务。
此处显示的结果带有以下注意事项 这些测试没有试图衡量多用户性能或 优化涉及多个联接和子查询的复杂查询。 这些测试位于相对较小的大约 14 兆字节数据库上。 它们不衡量数据库引擎对更大问题的扩展程度。
测试环境
用于这些测试的平台是具有 1GB 或内存的 1.6GHz Athlon 和 IDE 磁盘驱动器。操作系统是 RedHat Linux 7.2带有 一个库存内核。
默认情况下使用的 PostgreSQL 和 MySQL 服务器在 红帽 7.2。PostgreSQL 版本 7.1.3 和 MySQL 版本 3.23.41。 没有努力调整这些引擎。特别注意 RedHat 7.2 上的默认 MySQL 配置不支持 交易。不必支持事务MySQL 速度优势大但SQLite仍然能够在大多数上保持自己的优势 测试。
我被告知 RedHat 7.3 中的默认 PostgreSQL 配置 不必要地保守它被设计成 在具有 8MB RAM 的机器上工作而 PostgreSQL 可以 通过一些知识渊博的配置可以更快地运行 调音。 Matt Sergeant 报告说他已经调整了他的 PostgreSQL 安装 并重新运行如下所示的测试。他的结果表明 PostgreSQL 和 MySQL 的运行速度大致相同。对于 Matts 结果访问
过时的 URL http://www.sergeant.org/sqlite_vs_pgsync.html SQLite在与出现的相同配置中进行了测试 在网站上。它是使用 -O6 优化和 -DNDEBUG1 开关它禁用了许多“assert”语句 在 SQLite 代码中。-DNDEBUG1 编译器选项大约翻了一番 SQLite的速度。
所有测试均在静止的机器上进行。 使用一个简单的 Tcl 脚本来生成和运行所有测试。 可以在 SQLite 源代码树中找到此 Tcl 脚本的副本 在文件 tools/speedtest.tcl 中。
所有测试中报告的时间代表挂钟时间 在几秒钟内。为 SQLite 报告两个单独的时间值。 第一个值是 SQLite 的默认配置其中 已打开完整磁盘同步。打开同步 onSQLite 执行 在关键点进行 fsync 系统调用或等效调用 确保关键数据具有 实际上已写入磁盘驱动器表面。同步 是保证数据库完整性所必需的如果 操作系统崩溃或计算机意外关闭电源 在数据库更新过程中。第二次报告SQLite是 关闭同步时。关闭同步后 SQLite 有时要快得多但存在 操作系统崩溃或意外断电可能 损坏数据库。一般来说同步SQLite 时间用于与 PostgreSQL 进行比较这也是 synchronous和异步 SQLite 时间用于 与异步MySQL引擎的比较。
测试 11000 个插入
创建表 t1a INTEGER b INTEGER c VARCHAR100; 插入 t1 值1,13153一万三千一百五十三; 插入 t1 值2,75560七万五千五百六十; ......省略 995 行 插入 t1 值998,66289六万六千二百八十九; 插入 t1 值999,2432224,322; 插入 t1 值1000,94142九万四千一百四十二; PostgreSQL4.373MySQL的0.114SQLite 2.7.613.061SQLite 2.7.6 nosync0.223
因为它没有中央服务器来协调访问 SQLite 必须关闭并重新打开数据库文件从而使数据库失效 其缓存用于每个事务。在此测试中每个 SQL 语句 是一个单独的事务因此必须打开和关闭数据库文件 并且缓存必须刷新 1000 次。尽管如此异步 SQLite的版本仍然几乎与MySQL一样快。注意慢了多少 但是同步版本是。SQLite 调用 fsync 之后 每个同步事务以确保所有数据都安全打开 继续之前的磁盘表面。在 13 秒的大部分时间里 同步测试时SQLite 处于空闲状态等待磁盘 I/O 完成。
测试 2事务中有 25000 个 INSERT
开始; 创建表 t2a INTEGER b INTEGER c VARCHAR100; 插入 t2 值1,59672五万九千六百七十二; ......省略 24997 行 INSERT INTO t2 VALUES24999,89569八万九千五百六十九; 插入 t2 值 25000,9466694,666; 犯; PostgreSQL4.900MySQL的2.184SQLite 2.7.60.914SQLite 2.7.6 nosync0.757
当所有 INSERT 都放入事务中时SQLite 不再需要 关闭并重新打开数据库或使其在每个语句之间的缓存失效。 它也没有 必须做任何 fsyncs 直到最后。当解开束缚时 这样SQLite 比 PostgreSQL 和 MySQL 快得多。
测试 3索引表中有 25000 个 INSERT
开始; 创建表 t3a INTEGER b INTEGER c VARCHAR100; 在 t3c 上创建索引 i3; ......省略 24998 行 插入 t3 值24999,88509八万八千五百九; 插入 t3 值 25000,84791八万四千七百九十一; 犯; PostgreSQL8.175MySQL的3.197SQLite 2.7.61.555SQLite 2.7.6 nosync1.402
有报告称 SQLite 在索引表上表现不佳。 最近添加了此测试以反驳这些谣言。的确 SQLite在创建新索引条目方面不如其他引擎快 请参阅下面的测试 6但它的整体速度仍然更好。
测试 4100 个没有索引的 SELECT
开始; SELECT count* avgb FROM t2 WHERE b0 AND b1000; 从 t2 开始选择 count* avgb其中 b100 和 b1100; ......省略了 96 行 SELECT count* avgb FROM t2 WHERE b9800 AND b10800; 从 t2 开始选择 count*avgb其中 b9900 和 b10900; 犯; PostgreSQL3.629MySQL的2.760SQLite 2.7.62.494SQLite 2.7.6 nosync2.526
此测试对没有索引的 25000 个条目表执行 100 次查询 因此需要全表扫描。以前版本的 SQLite 用于 在此测试中比 PostgreSQL 和 MySQL 慢但最近的表现 增强功能提高了它的速度因此它现在是最快的 的组。
测试 5字符串比较中的 100 个 SELECT
开始; SELECT count* avgb FROM t2 WHERE c LIKE %one%; SELECT count* avgb FROM t2 WHERE c LIKE %two%; ......96 行省略 SELECT count* avgb FROM t2 WHERE c LIKE %99%; SELECT count* avgb FROM t2 WHERE c LIKE %one hundred%; 犯; PostgreSQL13.409MySQL的4.640SQLite 2.7.63.362SQLite 2.7.6 nosync3.372
此测试仍执行 100 次全表扫描但它使用 使用字符串比较而不是数值比较。 SQLite的速度是PostgreSQL的三倍以上大约是PostgreSQL的30% 比MySQL更快。
测试 6创建索引
在 t2a 上创建索引 i2a; 在 t2b 上创建索引 i2b; PostgreSQL0.381MySQL的0.318SQLite 2.7.60.777SQLite 2.7.6 nosync0.659
SQLite 在创建新索引方面速度较慢。这不是一个大问题 因为新索引并不经常创建但它是 正在处理中。希望SQLite的未来版本会做得更好 这里。
测试 75000 个带有索引的 SELECT
SELECT count* avgb FROM t2 WHERE b0 AND b100; 从 t2 开始选择 count*avgb其中 b100 和 b200; SELECT count* avgb FROM t2 WHERE b200 AND b300; ......4994 行省略了 SELECT count* avgb FROM t2 WHERE b499700 AND b499800; SELECT count* avgb FROM t2 WHERE b499800 AND b499900; 从 t2 开始选择 count* avgb其中 b499900 和 b500000; PostgreSQL4.614MySQL的1.270SQLite 2.7.61.121SQLite 2.7.6 nosync1.162
当这三个数据库引擎都有要使用的索引时它们的运行速度都更快。 但SQLite仍然是最快的。
测试 81000 个没有索引的更新
开始; 更新 t1 设置 bb*2其中 a0 和 a10; 更新 t1 设置 bb*2其中 a10 和 a20; ......省略 996 行 UPDATE t1 SET bb*2 WHERE a9980 AND a9990; 更新 t1 设置 bb*2其中 a9990 和 a10000; 犯; PostgreSQL1.739MySQL的8.410SQLite 2.7.60.637SQLite 2.7.6 nosync0.638
对于这个特定的UPDATE测试MySQL始终如一 五次或十次 比 PostgreSQL 和 SQLite 慢。我不知道为什么。MySQL是 通常是一个非常快的引擎。也许这个问题已经解决了 在更高版本的 MySQL 中。
测试 925000 个带有索引的更新
开始; 更新 t2 设置 b468026 其中 a1; 更新 t2 设置 b121928 其中 a2; ......省略 24996 行 UPDATE t2 SET b35065 WHERE a24999; 更新 t2 设置 b347393 其中 a25000; 犯; PostgreSQL18.797MySQL的8.134SQLite 2.7.63.520SQLite 2.7.6 nosync3.104
在最近的 2.7.0 版本中SQLite 的运行速度与 MySQL 在此测试中。但是最近对SQLite的优化还有更多 更新速度提高了一倍以上。
测试 1025000 个带有索引的文本 UPDATE
开始; 更新 t2 SET c148,382 WHERE a1; 更新 t2 SET c366,502 WHERE a2; ......省略 24996 行 UPDATE t2 SET c383,999 WHERE a24999; 更新 t2 SET c256,830 WHERE a25000; 犯; PostgreSQL48.133MySQL的6.982SQLite 2.7.62.408SQLite 2.7.6 nosync1.725
同样SQLite 的 2.7.0 版曾经以大致相同的速度运行 作为 MySQL。但是现在 2.7.6 版本比 MySQL 快两倍多并且 比 PostgreSQL 快 20 倍以上。
公平地说PostgreSQL开始在这个测试中失败。一个 知识渊博的管理员也许能够让 PostgreSQL 运行很多 通过稍微调整和调整服务器来加快速度。
测试 11从 SELECT 插入
开始; 插入 t1 从 t2 中选择 bac; 插入 t2 从 t1 中选择 bac; 犯; PostgreSQL61.364MySQL的1.537SQLite 2.7.62.787SQLite 2.7.6 nosync1.599
在此测试中异步 SQLite 仅比 MySQL 慢一点。 MySQL似乎特别擅长INSERT...SELECT 语句。 PostgreSQL 引擎仍在跳动 - 它使用的 61 秒的大部分时间 在等待磁盘 I/O 上花费了时间。
测试 12不带索引的 DELETE
从 t2 中删除其中 c 像 %fifty%; PostgreSQL1.509MySQL的0.975SQLite 2.7.64.004SQLite 2.7.6 nosync0.560
SQLite 的同步版本是本次测试中组中最慢的 但异步版本是最快的。 区别在于执行 fsync 所需的额外时间。
测试 13使用索引执行 DELETE 操作
从 t2 中删除其中 A10 和 A20000; PostgreSQL1.316MySQL的2.262SQLite 2.7.62.068SQLite 2.7.6 nosync0.752
这个测试很重要因为它是为数不多的 PostgreSQL 比 MySQL 快。异步 SQLite 是 但是比其他两个都快。
测试 14大 DELETE 之后的大 INSERT
插入 t2 选择 * 从 t1; PostgreSQL13.168MySQL的1.815SQLite 2.7.63.210SQLite 2.7.6 nosync1.485
一些旧版本的 SQLite版本 2.4.0 之前 在 DELETE 的序列后跟新的 INSERT。如此测试所示 问题现已解决。
测试 15一个大的 DELETE后跟许多小的 INSERT
开始; 从 t1 中删除; 插入 t1 值1,1071910,719; ......省略 11997 行 插入 t1 值11999,72836七万二千八百三十六; 插入 t1 值12000,64231六万四千二百三十一; 犯; PostgreSQL4.556MySQL的1.704SQLite 2.7.60.618SQLite 2.7.6 nosync0.406
SQLite 非常擅长在事务中执行 INSERT这可能 解释了为什么它在这个测试中比其他数据库快得多。
测试 16删除表
删除表 t1; 下降表 t2; 下降表 t3; PostgreSQL0.135MySQL的0.015SQLite 2.7.60.939SQLite 2.7.6 nosync0.254
在删除表方面SQLite比其他数据库慢。 这可能是因为当 SQLite 删除一个表时它必须经过 擦除数据库文件中处理该表的记录。MySQL 和 另一方面PostgreSQL 使用单独的文件来表示每个表 因此他们只需删除文件即可删除表速度要快得多。
另一方面删除表并不是一个非常常见的操作 因此如果SQLite需要更长的时间那不被视为一个大问题。
