SQL Server 2000 性能问题 - 大表

发布于 2024-10-04 23:51:55 字数 88 浏览 3 评论 0原文

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

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

干杯

Have a large table that is fast approaching 11 million records. (20 columns in the table).

My question is, is there a performance issue that I should be thinking about in terms of the Number of rows in a table?

Cheers

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

独自←快乐 2024-10-11 23:51:55

这取决于如何使用表中的数据。
是否存在大量读取、大量写入?
数据是否已存储且从未更新等。

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

It depends on how the data in the table is used.
Are there a lot of reads, a lot of writes?
Is the data stored and never updated, etc.

Without more info, the answer is "most likely"

童话里做英雄 2024-10-11 23:51:55

取决于您的主键以及您如何使用它。
如果大多数时候,数据仅通过 pk 访问,并且 pk 是基本数字类型(整数),那么通常会很快。

但如果你使用 where 条件,也许你需要调整它。性能调整基于您查询的方式。

这是我的建议,

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

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

depends on your primary key and how u use it.
if most of the time, data is accessed only by pk and pk is basic number type(integer) it will be usual fast.

but if u use where condition maybe u need to tune it up. performance tuning is based on how u query it.

here's my tips

  • equal operator(=) provide best performance.
  • or operator sometime slower performance. separate into 2 query and union it maybe faster.

select * from tableA where a = 'aaa'
union
select * from tableA where a = 'bbb'

以往的大感动 2024-10-11 23:51:55

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

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

但是,如果您的增长明显更高,例如每天约 110 万条记录,那么您将需要很快开始计划,因为您可能会开始以令人不安的速度遇到问题。

As others have commented there's nothing particularly huge about 11 million records and usage is pretty important but what's probably more important is table growth.

If your growth is ~110K daily (or 1% daily) you'll be able to monitor performance comfortably before you'll have to start needing to address problems by upping execution timeout values, reworking queries or taking more drastic measures like upgrading hardware, SQL Version or database sharding.

However if you growth is significantly higher, e.g. ~1.1 Million records daily, than you'll need to start planning very soon, because its likely that you'll start encountering issues at an uncomfortable pace.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文