YYYYDD は、PolarDB-X 1.0 向けの日付ベースのシャーディング関数であり、日付または時刻型のシャードキーから抽出した「年」と「年の経過日数（1–366）」に基づいて、行をデータベースシャードにルーティングします。
仕組み
YYYYDD は、以下の数式を用いて、日付または時刻の値からシャードインデックスを算出します：
(YYYY × 366 + DD) % D| 変数 | 説明 |
|---|---|
YYYY | シャードキー値の年部分 |
DD | 年の経過日数（1–366） |
D | データベースシャードの総数 |
算出された剰余が、当該行を格納するデータベースシャードを決定します。
例：2012-12-31 12:12:12 の場合、12 月 31 日は 2012 年の 366 日目です。シャードインデックスは (2012 × 366 + 366) % D となります。
制限事項
| 制約条件 | 詳細 |
|---|---|
| シャードキーのデータ型 | DATE、DATETIME、または TIMESTAMP |
| シャード数 | 関数を使用する前に、特定のサイクル（例：2 年間）に基づいてあらかじめ決定する必要があります |
| サイクルのロールオーバー | 次のサイクルで同一の日付が再出現した場合、前回のサイクルにおける同一日付の行と同じシャードに配置される可能性があります。たとえば、2012 年 3 月 1 日から始まる 2 年間のサイクルでは、2014 年 3 月 1 日の行が 2012 年 3 月 1 日の行と同じシャードにルーティングされる場合があります。実際のシャードは、物理テーブルシャードの総数によって決まります。 |
| 最小バージョン | PolarDB-X 1.0 インスタンスのバージョンが 5.1.28-1320920 以降 |
適用範囲/利用シーン
YYYYDD は、年および年の経過日数でデータをパーティション分割するワークロードに適しています。たとえば、特定の日付でフィルター処理される時系列ログやイベントレコードなどが該当します。tbpartition by YYYYDD(ShardKey) を使用すると、同一日の行が単一の物理テーブルシャード内に集約され、シャードキーを含む述語を持つクエリは、他のシャードをスキャンすることなく対象のシャードのみに直接アクセスできます。
シャード化テーブルの作成
以下の例では、create_time をシャードキーとして、2 年間のサイクルをカバーするテーブルを作成します。
物理テーブルシャード数の算出
Data Definition Language（DDL）文を作成する前に、物理テーブルシャードの総数を決定します：
サイクル長を選択します。1 年間の最大日数は 366 日であるため、2 年間のサイクルでは最大で 732 個の物理テーブルシャード（366 × 2）が必要になります。
その総数をデータベースシャード数で割り、小数点以下を切り上げて最も近い整数に丸めます。
この例では、PolarDB-X 1.0 インスタンスにはノードが 2 台あり、各ノードにデータベースシャードが 8 個ずつあるため、合計で 16 個のデータベースシャード があります：
732 ÷ 16 = 45.75 → 46 に切り上げ物理テーブルシャード数を 46 に設定します。
パフォーマンスを最適化するには、物理テーブルシャード数をデータベースシャード数の整数倍となるように選択することを推奨します。
DDL 文
CREATE TABLE test_yyyydd_tb (
id INT,
name VARCHAR(30) DEFAULT NULL,
create_time DATETIME DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE = InnoDB DEFAULT CHARSET = utf8
dbpartition BY YYYYDD(create_time)
tbpartition BY YYYYDD(create_time) TBPARTITIONS 46;create_time を WHERE 句に含むクエリは、他のシャードをスキャンすることなく、該当する物理テーブルシャードに直接ルーティングされます。