PolarDB:YYYYMM

YYYYMM を使用する場面

YYYYMM は次のような場合に適しています：

• データが月ごとに蓄積され、各月のレコードを専用のテーブルシャードに格納したい場合。

• クエリが頻繁に年と月でフィルター処理され、他のシャードをスキャンせずに単一のシャードにヒットさせる必要がある場合。

• 1 つの DDL 文で、データベースレベルとテーブルレベルの両方のパーティション分割に同じ時間列を適用したい場合。

YYYYMM は tbpartition by YYYYMM(ShardKey) 句と併用することを推奨します。

仕組み

YYYYMM はレンジ関数ではなく、循環ハッシュ関数です。この違いは、シャードの計画方法に影響します：

• サイクル内の各月は、固定のテーブルシャードにマップされます。

• サイクルが繰り返されると、異なる年の同じ暦月のデータが同じテーブルシャードに格納されます。たとえば、2 年間のサイクルの場合、2014 年 3 月のデータは 2012 年 3 月のデータと同じシャードにマップされます。

• この関数はレンジベースではなく循環型であるため、シャードを自動的に生成することはできません。意図するサイクル長に基づいて物理テーブルシャードの総数を自分で計算し、それに応じて tbpartitions を設定する必要があります。

要件

例

次の例では、8 つのデータベースシャードを持つ PolarDB-X インスタンス上に、2 年間のサイクルで月ごとにパーティション分割されたテーブルを作成します。

シャードの計算：

• サイクル長：2 年 = 24 ヶ月

• 物理テーブルシャードの総数：24

• データベースシャードあたりのテーブルシャード数：24 ÷ 8 = 3

create table test_yyyymm_tb (
    id          int,
    name        varchar(30) DEFAULT NULL,
    create_time datetime    DEFAULT NULL,
    primary key(id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
dbpartition by YYYYMM(create_time)
tbpartition by YYYYMM(create_time) tbpartitions 3;

この設定では：

• 行は (year × 12 + month) % 8 に基づいて 8 つのデータベースシャードに分散されます。

• 各データベースシャード内で、行はさらに 3 つのテーブルシャードに分割されます。

• create_time を特定の年と月でフィルター処理するクエリは、他のシャードをスキャンすることなく、一致するテーブルシャードに直接ルーティングされます。