پارتیشن‌بندی داده Data Partitioning

نکته‌ای که شاید باورتان نشود: در SQL Server، پارتیشن‌بندی در درجه‌ی اول یک ابزار مدیریت و نگهداری است، نه ابزاری برای تندتر کردنِ کوئری‌ها. این جمله‌ی کلیدیِ فصل ۱۶ کتابِ Pro SQL Server Internals است — و اگر آن را جدی نگیرید، تمام تصمیم‌گیری‌هایتان درباره‌ی پارتیشن‌بندی، از همان ابتدا اشتباه خواهد بود. Here's something you might not believe: in SQL Server, partitioning is primarily a management and maintenance tool — not a query-speed hack. This is the key takeaway from Chapter 16 of Pro SQL Server Internals — and if you ignore it, every partitioning decision you make will be wrong from the start.

کلمهٔ «پارتیشن» دو معنا دارد که اغلب قاطی می‌شوند. قبل از هر چیزی، این دو را یک‌بار برای همیشه از هم جدا کنید: The word "partition" has two meanings that often get mixed up. Before anything else, let's separate them once and for all:

چهار روش پارتیشن‌بندی در دنیای دیتابیس‌ها وجود دارد: RANGE، LIST، HASH و KEY. اما هر موتوری همهٔ آنها را پشتیبانی نمی‌کند. در SQL Server فقط RANGE در دسترس است؛ MySQL هر چهار روش را دارد که KEY مختص خودش است. There are four partitioning methods in the database world: RANGE, LIST, HASH, and KEY. But not every engine supports all of them. In SQL Server, only RANGE is available; MySQL has all four, with KEY being its own.

SQL Server دو مکانیزم مجزا برای پارتیشن‌بندی دارد و درک تفاوت‌شان برای هر توسعه‌دهنده‌ای ضروری است: Partitioned Tables (روش جدیدتر و قدرتمندتر) و Partitioned Views (روش قدیمی‌تر، اما هنوز هم کاربردی). بیایید اول این دو را کنار هم ببینیم، بعد سراغ جزئیات هرکدام برویم. SQL Server has two separate mechanisms for partitioning, and understanding the difference is essential for every developer: Partitioned Tables (the newer, more powerful approach) and Partitioned Views (the older method, but still very much alive). Let's first look at them side by side, then dive into the details of each.

۱. Partitioned Tables — آجر به آجر 1. Partitioned Tables — brick by brick

برای ساختن یک جدول پارتیشن‌شده در SQL Server، سه مؤلفهٔ کلیدی داریم: Building a partitioned table in SQL Server requires three key components:

-- 1) Partition function: the rule + boundaries
      CREATE PARTITION FUNCTION pf_OrdersByYear (date)
      AS RANGE RIGHT FOR VALUES
      ('2023-01-01', '2024-01-01', '2025-01-01');
      -- → 4 partitions: <2023, 2023–2024, 2024–2025, 2025+
      
      -- 2) Partition scheme: map partitions to filegroups
      CREATE PARTITION SCHEME ps_Orders
      AS PARTITION pf_OrdersByYear TO
      ([FG_Archive], [FG_2023], [FG_2024], [FG_Current]);
      
      -- 3) Create the table ON the scheme — OrderDate is the key
      CREATE TABLE dbo.Orders (
          Id         bigint IDENTITY NOT NULL,
          OrderDate  date NOT NULL,
          CustomerId int NOT NULL,
          Total      decimal(12,2) NOT NULL,
          CONSTRAINT PK_Orders PRIMARY KEY (Id, OrderDate)  -- key must include OrderDate!
      ) ON ps_Orders(OrderDate);

۲. Partitioned Views — روشِ قدیمی‌تر 2. Partitioned Views — the older technique

پیش از ورود Partitioned Tables به SQL Server، این روش تنها راهِ ممکن بود. اما هنوز هم کاربرد خودش را دارد؛ به‌ویژه وقتی که نیاز دارید جدول‌های عضو، ساختارِ کمی متفاوت داشته باشند یا روی سرورهای جداگانه (از طریق Linked Servers) قرار گیرند. Before Partitioned Tables arrived in SQL Server, this was the only option. It's still useful, especially when member tables need slightly different structures or need to reside on different servers (via Linked Servers).

-- each member table has its own CHECK constraint to enforce the partition range
  CREATE TABLE dbo.Orders_2023 (
      Id int NOT NULL PRIMARY KEY,
      OrderDate date NOT NULL,
      CONSTRAINT CK_Orders_2023 CHECK
          (OrderDate >= '2023-01-01' AND OrderDate < '2024-01-01')
  );
  
  CREATE TABLE dbo.Orders_2024 (
      Id int NOT NULL PRIMARY KEY,
      OrderDate date NOT NULL,
      CONSTRAINT CK_Orders_2024 CHECK
          (OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01')
  );
  
  CREATE TABLE dbo.Orders_2025 (
      Id int NOT NULL PRIMARY KEY,
      OrderDate date NOT NULL,
      CONSTRAINT CK_Orders_2025 CHECK
          (OrderDate >= '2025-01-01' AND OrderDate < '2026-01-01')
  );
  GO
  
  -- the view unions all member tables
  CREATE VIEW dbo.AllOrders AS
  SELECT * FROM dbo.Orders_2023
  UNION ALL
  SELECT * FROM dbo.Orders_2024
  UNION ALL
  SELECT * FROM dbo.Orders_2025;
  
  -- query through the view: optimizer uses CHECK constraints to eliminate irrelevant tables
  SELECT * FROM dbo.AllOrders
  WHERE OrderDate >= '2024-06-01' AND OrderDate < '2024-07-01';
  -- execution plan: only Orders_2024 is touched — the other tables are pruned ✓

۳. مقایسه و استفادهٔ ترکیبی 3. Comparison and using them together

حالا که با هر دو مکانیزم آشنا شدید، این جدول کمک می‌کند در یک نگاه تفاوت‌های کلیدی را ببینید و تصمیم بگیرید کدام یک برای سناریوی شما مناسب‌تر است. Now that you're familiar with both mechanisms, this table helps you see the key differences at a glance and decide which one fits your scenario better.

استفادهٔ ترکیبی: در عمل، می‌توانید از هر دو روش با هم بهره ببرید. مثلاً داده‌های «داغ» را در یک جدول پارتیشن‌شده نگه دارید و یک ویوی پارتیشن‌شده بسازید که این جدول را با یک جدول قدیمیِ جداگانه (روی یک Filegroup آرشیو) ترکیب کند. این رویکرد، انعطاف‌پذیری هر دو روش را در اختیار شما قرار می‌دهد. Using them together: in practice, you can combine both approaches. For example, keep "hot" data in a partitioned table and create a partitioned view that combines it with a separate older table (on an archive filegroup). This approach gives you the flexibility of both methods.

۴. Tiered Storage — داغ روی SSD، کهنه روی HDD 4. Tiered Storage — hot on SSD, cold on HDD

یادتان هست که Partition Scheme هر پارتیشن را به یک Filegroup متصل می‌کند؟ این یعنی می‌توانید Filegroup‌های مختلف را روی دیسک‌های متفاوت قرار دهید — یکی روی SSDِ گران‌قیمت و سریع، دیگری روی HDDِ ارزان‌تر و کندتر. داده‌ی امسال روی SSD می‌نشیند و کوئری‌های داغ را سریع پاسخ می‌دهد؛ داده‌ی ۵ سال پیش روی HDD می‌رود و هزینه‌ی ذخیره‌سازی را پایین می‌آورد. همین. Remember that the partition scheme maps each partition to a filegroup? This means you can place different filegroups on different disks — one on expensive, fast SSD, another on cheaper, slower HDD. This year's data lives on SSD and serves hot queries quickly; 5-year-old data goes to HDD and keeps storage costs down. That's it.

۵. Sliding Window — آرشیوِ آنی، بدون DELETE 5. Sliding Window — instant archive, no DELETE

این یکی از کاربردی‌ترین الگوهای پارتیشن‌بندی است — و همان دلیلی که بسیاری از تیم‌ها اصلاً سراغ پارتیشن‌بندی می‌روند. فرض کنید تصمیم دارید همیشه ۱۲ ماهِ اخیر را در جدول اصلی نگه دارید. هر ماه، یک پارتیشنِ جدید برای داده‌های تازه اضافه می‌کنید و قدیمی‌ترین پارتیشن را با ALTER TABLE ... SWITCH آنی به یک جدول آرشیو منتقل می‌کنید. این عملیات فقط متادیتا را تغییر می‌دهد و حتی اگر پارتیشن صدها میلیون سطر داشته باشد، فقط چند میلی‌ثانیه طول می‌کشد. خبری از DELETE های سنگین نیست، لاگ تراکنش باد نمی‌کند، و قفلِ طولانی‌مدتی روی جدول نمی‌آید. This is one of the most practical partitioning patterns — and the very reason many teams adopt partitioning in the first place. Suppose you decide to keep only the last 12 months in the main table. Each month, you add a fresh partition for new data and ALTER TABLE ... SWITCH the oldest partition instantly to an archive table. This operation changes only metadata and takes milliseconds, even if the partition holds hundreds of millions of rows. No heavy DELETEs, no transaction log bloat, and no long‑lasting table locks.

-- archive table must have EXACTLY the same structure as the main table
CREATE TABLE dbo.OrdersArchive (/* identical schema */);

-- instant move: metadata-only, milliseconds even for huge partitions
ALTER TABLE dbo.Orders
SWITCH PARTITION 1 TO dbo.OrdersArchive;

-- remove the now‑empty partition boundary (merge it with the previous one)
ALTER PARTITION FUNCTION pf_OrdersByYear()
MERGE RANGE ('2023-01-01');

-- add a fresh partition for the upcoming month/year
ALTER PARTITION FUNCTION pf_OrdersByYear()
SPLIT RANGE ('2026-01-01');

۶. Potential Issues — تله‌هایی که باید بدانید 6. Potential Issues — traps to know about

در MySQL، چهار روش پارتیشن‌بندی یعنی RANGE، LIST، HASH و KEY را داریم، اما نحوهٔ تعریف آنها با SQL Server تفاوت دارد. MySQL همه‌چیز را داخل خودِ دستور CREATE TABLE تعریف می‌کند — خبری از اشیای جداگانه‌ای مثل Partition Function و Scheme نیست. یک تفاوت مهم دیگر: از MySQL 8.0 به بعد، فقط InnoDB و NDB از پارتیشن‌بندی پشتیبانی می‌کنند ولی MyISAM نه. In MySQL, we have the four partitioning methods RANGE, LIST, HASH, and KEY, but the way they're defined differs from SQL Server. MySQL defines everything inside the CREATE TABLE statement itself — no separate objects like partition functions and schemes. Another important difference: from MySQL 8.0 onward, only InnoDB and NDB support partitioning — not MyISAM.

CREATE TABLE orders (
  id          BIGINT NOT NULL AUTO_INCREMENT,
  order_date  DATE NOT NULL,
  customer_id INT NOT NULL,
  total       DECIMAL(12,2),
  PRIMARY KEY (id, order_date)
)
PARTITION BY RANGE (YEAR(order_date)) (
  PARTITION p2023 VALUES LESS THAN (2024),
  PARTITION p2024 VALUES LESS THAN (2025),
  PARTITION p2025 VALUES LESS THAN (2026),
  PARTITION pmax  VALUES LESS THAN (MAXVALUE)
);

CREATE TABLE events (
  id         BIGINT NOT NULL AUTO_INCREMENT,
  event_date DATE NOT NULL,
  payload    JSON,
  PRIMARY KEY (id, event_date)
)
PARTITION BY RANGE COLUMNS(event_date) (
  PARTITION p2024 VALUES LESS THAN ('2025-01-01'),
  PARTITION p2025 VALUES LESS THAN ('2026-01-01'),
  PARTITION pmax  VALUES LESS THAN (MAXVALUE)
);
-- COLUMNS variant: use the date directly, no TO_DAYS()

CREATE TABLE user_sessions (
  id         INT NOT NULL,
  user_id    INT NOT NULL,
  payload    TEXT,
  PRIMARY KEY (id, user_id)
)
PARTITION BY HASH(user_id)
PARTITIONS 8;
-- user_id % 8 picks the bucket

CREATE TABLE api_logs (
  trace_id   VARCHAR(36) NOT NULL,
  ts         DATETIME NOT NULL,
  body       TEXT,
  PRIMARY KEY (trace_id, ts)
)
PARTITION BY KEY(trace_id)
PARTITIONS 16;
-- works on non-integer columns; MySQL hashes internally

CREATE TABLE sales (
  id          BIGINT NOT NULL AUTO_INCREMENT,
  region      VARCHAR(10) NOT NULL,
  sale_date   DATE NOT NULL,
  amount      DECIMAL(12,2),
  PRIMARY KEY (id, region, sale_date)
)
PARTITION BY LIST COLUMNS(region)
SUBPARTITION BY HASH (YEAR(sale_date))
SUBPARTITIONS 4 (
  PARTITION pAMER VALUES IN ('US', 'CA', 'BR'),
  PARTITION pEMEA VALUES IN ('DE', 'FR', 'UK'),
  PARTITION pAPAC VALUES IN ('JP', 'IN', 'AU')
);
-- first layer: LIST by region
-- second layer: HASH on year within each region

هر دو یعنی «تقسیم داده» و به همین دلیل اغلب به جای هم استفاده می‌شوند. اما تفاوتشان یک سوال ساده است: تقسیم روی یک سرور، یا روی چند سرور؟ پاسخ به این سوال، معماری شما را تعیین می‌کند. Both mean "splitting data" and are often used interchangeably. But their difference comes down to one simple question: splitting on one server, or across many? The answer defines your architecture.

به کوئری سوم دقت کنید: WHERE CustomerId = 1042. این کوئری کاملاً درست است و جواب درست می‌دهد — اما چون ستون پارتیشن (OrderDate) در WHERE نیست، موتور هیچ راهی برای حذف پارتیشن ندارد و هر شش پارتیشن را می‌خواند. این پرهزینه‌ترین نتیجهٔ یک انتخابِ بدِ کلید است. Look closely at query three: WHERE CustomerId = 1042. This query is perfectly valid and returns correct results — but because the partition key (OrderDate) isn't in the WHERE clause, the engine has no way to eliminate anything and reads all six partitions. That's the most expensive outcome of a poor key choice.

صفحه را ببندید و با کلمات خودتان جواب بدهید، سپس کلیک کنید و پاسخ را با توضیحات مقایسه کنید. اگر سوالی شما را گیر انداخت، به همان ایستگاه برگردید و دوباره بخوانید. Close the page, answer in your own words, then click to compare your response with the explanation. If a question stumps you, jump back to that stop and review it.