SQL Server 分区表与性能优化
遇到不少工作了许多年的人，这部门人不懂数据库的优化，更不懂分区表，但是他们总是把性能瓶颈寄希望于分区表，以为分区表是一个万能的解药，但凡是有点性能问题，第一个就想到分区，把分区表当做终极大招，什么性能问题都能办理。难道是在网上看一个分区demo之类的口水文章，今后就对分区笃信不疑，你有没有考虑过自己的实际环境是否与分区的demo一样简单？
分区也不是简单地随意行事，用什么列分做分区键，如何规划分区的逻辑文件（文件组）和物理文件（数据文件），索引如何分区，是否必要对齐，查询怎么写，是否必要经常跨分区查询等等一系列问题都要考虑到。
遇到国外一篇关于分区于性能相关的非常好的文章，他的观点我非常承认，以下是链接和译文。
https://www.timradney.com/sql-server-partitioning-for-performance/
我经常遇到关于分区（partitioning）的问题，人们试图通过它来缓解超大表的性能问题。一个常见的误解是：由于表很大，当查询必要SQL Server读取整个表时，假如对表举行分区，SQL Server就会读取更少的数据。但究竟是，全表扫描就是全表扫描，无论表是否分区都一样。当然也有例外——假如你通过分区将每个文件放在不同的磁盘上，利用更快的存储I/O，那确实可能有所帮助。
当DBA们试图提升超大表的团体查询性能时，他们手头其实有多种工具可用。
最常见的做法是：针对最常执行的查询（特别是那些导致表扫描或全索引扫描的查询），为表创建合适的索引。许多时候，问题可能就出在查询本身的操持上——比如那些使用select *的查询或报表。
关键在于编写只获取必要数据的查询语句。通过合理创建索引来淘汰必要读取的行数，可以显著提升团体性能。
另一个值得考虑的方案是数据压缩。压缩技术能有用淘汰表在缓冲池中占用的空间，而且读取压缩数据通常也会更快。
归档旧数据，听起来很简单但很有用的方法。假如某些数据大多数用户并不必要访问，将其归档到专门的表中供特定用户查询，就能制止不必要的读取。许多客户习惯查询"从当前日期到最早历史"的数据，但假如实际只需保留12个月的数据，就应该限定查询范围或创建归档流程将旧数据移出主表。假如数据保留政策确实是12个月，直接删除超期数据也未尝不可。
企业真该设立数据治理团队来订定合理的数据留存政策。惋惜对数据从业者来说，多数企业都希望永世生存全部数据——这对存储厂商倒是个天大的好消息！
这就引出了一个问题——什么时候应该举行分区？
我考虑分区的首要原因是为了实现分阶段恢复（piecemeal restores）。对于存储多年稳定的历史归档数据的大型数据库，我可以按年或季度将数据分区到只读文件组（ReadOnly filegroups）。当必要快速恢复时，我可以先恢复读写文件组让用户功能恢复正常，稍后再恢复只读文件组。
将旧数据分区到只读文件组还能简化团体维护工作：文件组级别的备份可以淘汰只读数据的备份频率；对于不再变化的数据，索引和统计信息维护也不必要定期举行；DBCC CHECKDB扫描同样如此。
把旧数据放在独立文件组还提供了快速"删除"大量数据的轻便方法——直接删除整个文件组即可。
我常听到这样一句话："分区是为了维护方便，而非提升性能"。过去15-20年间，我在不同客户现场一次次验证了这个观点。
以上是译文，以下是用AI的明白话总结一下：
这篇文章的焦点观点可以总结为以下几点：
[*]分区的重要价值在于数据维护，而非性能提升
[*]分区不会自动优化全表扫描性能（除非明白查询特定分区）
[*]真正的优势体现在：分阶段恢复、简化维护流程、灵活管理历史数据
[*]大表性能优化的正确姿势
[*]首要方案应该是优化索引（针对高频查询）
[*]重写低效查询（制止SELECT *，只获取必要数据）
[*]考虑数据压缩淘汰I/O压力
[*]创建合理的数据归档机制
[*]分区的典型适用场景
[*]实现分阶段恢复（先恢复活泼数据，再恢复历史数据）
[*]将静态历史数据设为只读，淘汰维护开销（备份/索引/统计维护）
[*]快速清算大量数据（直接删除整个文件组）
[*]数据治理的重要性
[*]企业必要明白数据保留政策
[*]制止"永世生存全部数据"的常见误区
[*]发起设立专门的数据治理团队
一句话总结：分区是DBA工具箱里的一把专业螺丝刀，它最得当处置惩罚数据维护和恢复的特定问题，而不是用来办理全部性能问题的万能扳手。优化大表性能应该优先考虑索引、查询优化和数据生命周期管理。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]