☰

我是否应该将主表分区为 2 百万行？

tag-icon • tag-icon sql-server sql-server-2005 database database-performance
我是否应该将主表分区为 2 百万行？

我是一名开发人员，需要一些 DBA 建议。
我们开始遇到 MSSQL2005 数据库的性能问题。事件的可见影响主要是服务器上的 CPU 占用率过高，但运营报告称它还消耗了 SAN 的资源（并非总是如此）。问题的主要来源肯定是某些应用程序，但我想知道我们是否应该对一些主表进行分区以减轻 I/O 压力。
一个文件的基础大小约为 60GB。
主表（订单）有 210 万行，每行 215 个冒号（但没有一个是巨大的）。
我们有一个整数作为 PK，因此定义分区函数应该没问题。

分区能给我们带来好处吗？分区索引能给我们带来好处吗？
以下是有关数据库和表的更多事实

database_name  database_size    unallocated space
My_base         57173.06 MB     79.74 MB
reserved        data            index_size      unused
29 444 808 KB   26 577 320 KB   2 845 232 KB    22 256 KB

name        rows            reserved    data        index_size      unused
Order   2 097 626       4 403 832 KB    2 756 064 KB    1 646 080 KB    1688 KB

谢谢你的建议

唐

答案1

啊 - 为什么？15 年前，100 万行数据已经算小了。而今天，1 亿行数据已经算小了。

如果您遇到 CPU 占用过大的问题，我会开始查找问题所在 - 这看起来更像是索引问题和/或不良字段设计，而不是其他任何问题。

现在，SAN 占用 - 对于任何 SQL Server 来说，这都是完全正常的。SAN 人员通常对数据库服务器的 IO 负荷大这一事实一无所知。数据库通常需要针对其优化并可充分利用的特定 SAN 设置。它不是“占用”它，而是尝试尽可能好地利用所有资源。

您的数据库很小 - 说真的。我在这里真的看不到任何问题。订单表的内存只有 4GB，有趣的是 - 这个大小应该从内存中回答。

分区对于大量删除很有用（每年删除一张表，删除一年的订单是表截断，而不是删除），但对于您的规模来说这不是问题（我有一个包含大约 15 亿个条目的价格表，而且这个数据量很小）。它不会大大加速查询 - 要么查询只能选择一个分区（不，整数 PK 没有帮助，除非您按 PK 范围选择作为过滤器） - 要么它不能。但即使它可以，索引也几乎一样快。

什么类型的查询不好？执行计划怎么样？也许你会：

  • 内存太小（8GB或更多？）

  • 索引布局不理想/不匹配，导致查询基本上变成表扫描？在这种情况下，我会从那方面开始修复。

  • 您加载了超出需要的数据吗？

如果没有查询执行计划，就无法回答这个问题。

顺便说一句，一个文件 60GB 是严重疏忽。任何大型数据库都应该具有与并行操作数量相同的文件数量（即 SQL Server 可用的服务器核心数量）；）我敢肯定您的 I/O 组织得很糟糕 - 未对齐的分区、错误的格式，减慢了您的速度（可能非常慢 - 错误的磁盘设置可能会使您的性能降低高达 40%）。

要缓解 I/O 压力：

  • 确保数据库服务器已正确安装（我很少看到 - 管理员似乎喜欢忽略这里的文档）

  • 首先，确保你拥有适当的资源。磁盘子系统上的 IOPS 预算有多高？你测量过吗？

  • 确保数据库设置正确（再次强调，大多数管理员在这种情况下都喜欢装糊涂）

  • 确保您有一个良好的表结构和良好的主键（几乎这是您唯一正确的东西）。

然后 - 进入分析器，找出应用程序并确保这些查询得到优化。

相关内容