【问题标题】:SQL Server 2000 Perforamance Question - Large TableSQL Server 2000 性能问题 - 大表
【发布时间】:2010-11-29 15:34:33
【问题描述】:

拥有一个快速接近 1100 万条记录的大表。 (表中有 20 列)。

我的问题是,我是否应该考虑表中的行数方面的性能问题?

干杯

【问题讨论】:

  • 这个表是怎么使用的??您针对它运行什么样的查询?那些被指数很好地覆盖了吗?你有很多插入、更新、删除吗??
  • +1 @Marc_s - 我们需要更多关于您的桌子及其使用方式的信息。
  • 有 1100 万条记录,可能不会。只要您对最常见的查询有适当的索引,1100 万条记录实际上并没有那么大。
  • 1100 万条记录足够大,服务器和磁盘配置很重要。如果它只是放在一个驱动器上,那么世界上所有的索引都无济于事。

标签: sql sql-server sql-server-2000 sqlperformance


【解决方案1】:

这取决于如何使用表中的数据。 有很多读,很多写吗? 数据是否已存储且永不更新等。

没有更多信息,答案是“最有可能”

【讨论】:

  • 实际上,正确的答案是:“这取决于”:-)
  • 表索引良好,仅在夜间数据同步期间接收更新。在工作日有很多从表中读取
  • @marc_s:我仍然认为这是“最有可能”而不是“取决于”;-) 不需要考虑性能的那种大小的表格很少见
【解决方案2】:

取决于您的主键以及您如何使用它。 如果大多数情况下,数据只能由 pk 访问,并且 pk 是基本数字类型(整数),它通常会很快。

但如果你使用 where 条件,你可能需要调整它。性能调整是基于你如何查询它。

这是我的建议

  • 等号运算符 (=) 提供最佳性能。
  • 或操作员有时会降低性能。分成2个查询并合并它可能更快。

从表 A 中选择 *,其中 a = 'aaa' 联盟 select * from tableA where a = 'bbb'

【讨论】:

    【解决方案3】:

    正如其他人所评论的那样,1100 万条记录并没有什么特别大的地方,使用量非常重要,但可能更重要的是表的增长。

    如果您每天的增长率约为 110K(或每天 1%),那么您将能够轻松地监控性能,然后您必须开始需要通过增加执行超时值、重新处理查询或采取更严厉的措施来解决问题,例如升级硬件、SQL 版本或数据库分片。

    但是,如果您的增长明显更高,例如每天大约 110 万条记录,而您很快就需要开始计划了,因为您可能会开始以不舒服的速度遇到问题。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-04-24
      • 2011-10-13
      • 1970-01-01
      • 2019-04-13
      • 2011-03-04
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多