SQL表大小和查询性能

问题描述

我们有许多来自Web服务的项目；每个项目包含未知数量的属性.我们将它们存储在具有以下架构的数据库中.

We have a number of items coming in from a web service; each item containing an unknown number of properties. We are storing them in a database with the following Schema.

项目
-ItemID
-ItemName

Items
- ItemID
- ItemName

属性
-PropertyID
-PropertyName
-PropertyValue
-PropertyValueType
-TransmitTime
-ItemID [fk]

Properties
- PropertyID
- PropertyName
- PropertyValue
- PropertyValueType
- TransmitTime
- ItemID [fk]

由于每次存储Web服务时，它都会存储每个项目的属性，因此属性表变得越来越大.我的问题是:什么时候应该停止将新记录添加到属性"表，并根据它们的传输时间来存档较旧的属性"记录?属性表何时会变得太大，并花费很长时间查询?有经验吗?

The properties table is growing quite large since it stores the properties for each item, each time the web service is called. My question is this: at what point should we stop adding new records to the Properties table, and archive older Property records according to their transmit time? When does the properties table become too large, and take too long to query? Is there a rule of thumb?

谢谢.

推荐答案

没有经验法则

一些想法:

• 定义大"(我们有1.6亿行表)
• 您现在有问题吗?如果没有，请不要解决
• 您是否运行了事件探查器或某些过时的dmvs以查找瓶颈(缺少索引等)
• 如果您需要掌握数据，则无法将其存档
• 您可以对表进行分区

这篇关于SQL表大小和查询性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！