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

Question

在我的工作中，我们有一个小型数据库（如200个表格，总共可能有100万行左右）。

我一直认为它的速度非常快，每秒数十万次插入，并且一旦连接建立，查询就会花费几毫秒。

恰恰相反，我们遇到了一些性能问题，因此我们每秒只能进行几百次插入和查询，即使是最简单的插入也是如此。

我不确定这是标准的行为/表现，还是我们做错了什么。例如，1500个查询意味着在一个键列上连接4个表大约需要10秒。在不违反任何约束条件的情况下，使用简单插入将xml格式的300K数据加载到数据库中需要3分钟。

数据库是SQL Server 2005，具有丰富的关系依赖模型，意味着对数据的大量关系和分类以及分类代码和其他一些事项的全套检查约束。

那些时候对吗？如果没有，可能会影响性能？ （所有查询都在索引列上完成）

Answer 1

索引是这里的一个主要因素，如果正确完成它们可以很好地加速Select语句，但请记住索引会使插入陷入困境，服务器不仅会更新数据，还会更新索引。这里的诀窍是：

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

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

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

1）读取速度（SELECT，Some UPDATE，Some DELETE） - 优先级越高，我创建的索引越多 2）写入速度（INSERT，Some Update，Some DELETE） - 优先级越高，我创建的索引越少 3）磁盘空间效率 - 优先级越高，填充因子越高

请注意，此知识通常适用于SQL Server，您的里程可能因不同的DBMS而异。

SQL语句评估也可以在这里提供帮助，但这需要一个真正的专家，小心的WHERE和JOIN分析可以帮助确定瓶颈以及您的查询所处的位置。打开SHOWPLAN和查询计划，评估您看到的内容并进行相应的计划。

另请参阅SQL Server 2008，索引连接！

Answer 2

进行粗略的比较：TPC-C benchmark record for SQL Server每分钟约有1.2万个事务处理，并且在过去4年左右就是这样（由64 CPU OS限制）。这是每秒16k交易的平台。这是在超高端机器，64个CPU，大量RAM，每个NUMA节点的亲和客户端和服务器短剥离的I / O系统（仅使用每个主轴的1-2％）。请记住那些是TPC-C事务，因此它们包含多个操作（我认为平均每次读取4-5次，每次写入1-2次）。

现在，您应该将这一顶级硬件缩小到实际部署，并将在哪里设置您对整个 OLTP事务处理的预期。

对于数据上传，当前world record is about 1TB in 30 minutes（如果仍然是当前的......）。每秒几万个插件是非常雄心勃勃的，但是如果在严肃的硬件上正确完成，则可以实现。链接中的文章包含ETL高吞吐量的提示和技巧（例如，使用多个上传流并将它们与NUMA节点关联）。

根据您的情况，我建议首先衡量，以便找出瓶颈，然后询问具体的问题如何解决特定的botlenecks。一个很好的起点是Waits and Queues whitepaper。

Answer 3

“Rich Relational Dependency”模型不利于快速插入速度。必须为每个插入的记录检查每个约束（主键，值检查，尤其是外键）。这比“简单插入”要多得多。

并不是说你的插入没有违反约束，时间可能就是检查你的外键。除非你也有触发器，因为它们甚至更糟。

当然有可能唯一错误的是你的Insert表是必备子项的父FK“另一个表的FK关系，忘记为子FK方添加一个索引关于FK关系（这不是自动的，经常被遗忘）。当然，这只是希望得到幸运。： - ）

Answer 4

约束增加了一个小的性能损失。它还必须更新每个插入的索引。如果您不将多个插入放入单个事务中，则数据库服务器必须将每个插入作为一个新的单独事务执行，从而进一步降低它。

150个查询/秒加入4个表听起来很正常，但我对您的数据知之甚少。

Answer 5

“我一直认为它的速度非常快，每秒数十万次插入，并且一旦连接建立，查询需要几毫秒。”

（a）数据库性能取决于物理I / O量的99％（除非您在使用内存数据库的某个小型站点中，这可以无害地推迟所有物理I / O直到一天之后已经完成了）。 （b）数据库I / O不仅涉及数据文件的实际物理I / O，还涉及持久保存日志/日志/ ...的物理I / O（并且日志通常甚至以双模式完成（即两次）因为说大约二十年左右）。 （c）“插入量”对应于“物理I / O量”的方式完全取决于数据库设计者可用于优化物理设计的选项。关于这一点，一般只能说一件事：SQL系统大多数都失败了（提供将“数万个插入”转换为“几百个”物理I / O所需的选项）。意思是“成千上万的插入”通常也意味着“成千上万的物理I / O”，这通常意味着“数十秒”。

那就是说，你的消息似乎表达了一种期望，即插入速度非常快（“每秒数万”），而“查询速度较慢”（“每个查询的毫秒数”，暗示“每个查询少于1000个查询”第二”）。这种期望是荒谬的。