数据库查询和插入速度取决于什么?

TPC-C benchmark record for SQL Server 每秒约16k个事务

OLTP事务处理

对于数据,请上载当前 world record is about 1TB in 30 minutes (如果仍然是最新的…)。每秒数万次的插入是非常雄心勃勃的,但如果在严肃的硬件上正确地完成,是可以实现的。链接中的文章包含ETL high troughput的提示和技巧(例如,使用多个上传流并将它们与NUMA节点关联)。

测量 因此,您可以找出瓶颈,然后询问 具体的 如何解决特定的botlenecks问题。一个好的起点是 Waits and Queues whitepaper .

1) 确定真正对速度至关重要的查询,这些查询应该具有最佳索引。

2) 填充因子在这里也很重要。这将为索引页提供空白空间,以便以后填充。当索引页已满(插入足够的行)时,需要花费更多的时间创建新页。但是,空页会占用磁盘空间。

我的诀窍是,对于每个应用程序,我设置优先级如下:

1) 读取速度(选择、一些更新、一些删除)-此优先级越高,我创建的索引越多

3) 磁盘空间效率—此优先级越高,我的填充率越高

SQL语句求值在这方面也有帮助,但这需要一个真正的专业人员,仔细的WHERE和JOIN分析可以帮助确定瓶颈以及查询所处的位置。启用“显示计划”和“查询计划”,评估所看到的内容并相应地进行计划。

再看看SQLServer2008,索引联接!

“丰富的关系依赖”模型不利于快速插入速度。必须为每个插入的记录检查每个约束(主键、值检查,尤其是外键)。这比“简单插入”要多得多。

并不是说你的插入没有违反约束,时间可能是全部在检查你的外键。除非你也有触发器,因为它们更糟糕。

当然,唯一可能的错误是,您的插入表是另一个表的“必须有子项”FK关系的父FK,而另一个表忘记在FK关系上为子FK端添加索引(这不是自动的,而且经常被忘记)。当然,这只是希望运气好。:-)

约束会增加少量性能损失。它还必须为每次插入更新索引。如果不将多个插入放入单个事务中,数据库服务器必须将每个插入作为一个新的、单独的事务执行,从而进一步降低速度。

每秒150个查询连接4个表听起来很正常,尽管我对您的数据了解不多。

“我一直期望它的速度相当快,每秒插入数万次,一旦建立连接,查询将花费毫秒。”

(a) 数据库性能99%取决于物理I/O的数量(除非您在某个小型站点中使用内存中的数据库,该数据库可以将所有物理I/O延迟到一天完成之后,这是无害的)。 (b) 数据库I/O不仅涉及到数据文件的实际物理I/O,还涉及到持久化日志/日志的物理I/O。。。(而且日志记录甚至经常以双模式(即两次)完成,因为大约20年左右)。

也就是说,您的消息似乎表达了一种期望,即“插入速度非常快(“每秒数万次”)”而“查询速度较慢”(“每查询毫秒数”,意味着“每秒少于1000次查询”)。这种期望是荒谬的。