diff --git a/basic-features.md b/basic-features.md index 820c97acbd28a..933192f50c097 100644 --- a/basic-features.md +++ b/basic-features.md @@ -185,18 +185,18 @@ summary: TiDBの機能概要について学びましょう。 | パーティショニング | 8.5 | 8.1 | 7.5 | 7.1 | 6.5 | 6.1 | 5.4 | | ------------------------------------------------------------------------------------------------------------ | :-: | :-: | :-: | :-: | :-: | :-: | :-: | -| [範囲分割](/partitioned-table.md#range-partitioning) | Y | Y | Y | Y | Y | Y | Y | +| [レンジパーティショニング](/partitioned-table.md#range-partitioning) | Y | Y | Y | Y | Y | Y | Y | | [ハッシュパーティショニング](/partitioned-table.md#hash-partitioning) | Y | Y | Y | Y | Y | Y | Y | | [キーパーティショニング](/partitioned-table.md#key-partitioning) | Y | Y | Y | Y | N | N | N | -| [List パーティショニング](/partitioned-table.md#list-partitioning) | Y | Y | Y | Y | Y | Y | E | -| [List COLUMNS パーティショニング](/partitioned-table.md) | Y | Y | Y | Y | Y | Y | E | -| [リストおよびリスト列パーティションテーブルのデフォルトパーティション](/partitioned-table.md#default-list-partition) | Y | Y | Y | N | N | N | N | +| [リストパーティショニング](/partitioned-table.md#list-partitioning) | Y | Y | Y | Y | Y | Y | E | +| [リストCOLUMNSパーティショニング](/partitioned-table.md) | Y | Y | Y | Y | Y | Y | E | +| [リストおよびリストCOLUMNSパーティションテーブルのデフォルトパーティション](/partitioned-table.md#default-list-partition) | Y | Y | Y | N | N | N | N | | [`EXCHANGE PARTITION`](/partitioned-table.md) | Y | Y | Y | Y | Y | E | E | | [`REORGANIZE PARTITION`](/partitioned-table.md#reorganize-partitions) | Y | Y | Y | Y | N | N | N | | [`COALESCE PARTITION`](/partitioned-table.md#decrease-the-number-of-partitions) | Y | Y | Y | Y | N | N | N | -| [動的剪定](/partitioned-table.md#dynamic-pruning-mode) | Y | Y | Y | Y | Y | Y | E | -| [範囲列パーティショニング](/partitioned-table.md#range-columns-partitioning) | Y | Y | Y | Y | Y | N | N | -| [範囲 INTERVAL 分割](/partitioned-table.md#range-interval-partitioning) | Y | Y | Y | Y | E | N | N | +| [動的プルーニング](/partitioned-table.md#dynamic-pruning-mode) | Y | Y | Y | Y | Y | Y | E | +| [レンジCOLUMNSパーティショニング](/partitioned-table.md#range-columns-partitioning) | Y | Y | Y | Y | Y | N | N | +| [レンジ INTERVAL パーティショニング](/partitioned-table.md#range-interval-partitioning) | Y | Y | Y | Y | E | N | N | | [パーティションテーブルを非パーティションテーブルに変換する](/partitioned-table.md#convert-a-partitioned-table-to-a-non-partitioned-table) | Y | Y | Y | N | N | N | N | | [既存のテーブルをパーティション分割する](/partitioned-table.md#partition-an-existing-table) | Y | Y | Y | N | N | N | N | | [グローバルインデックス](/global-indexes.md) | Y | N | N | N | N | N | N | @@ -214,7 +214,7 @@ summary: TiDBの機能概要について学びましょう。 | [拡張統計](/extended-statistics.md) | E | E | E | E | E | E | E | | 統計フィードバック | N | N | N | N | N | 非推奨 | 非推奨 | | [統計情報を自動的に更新する](/statistics.md#automatic-update) | Y | Y | Y | Y | Y | Y | Y | -| [動的剪定](/partitioned-table.md#dynamic-pruning-mode) | Y | Y | Y | Y | Y | Y | E | +| [動的プルーニング](/partitioned-table.md#dynamic-pruning-mode) | Y | Y | Y | Y | Y | Y | E | | [`PREDICATE COLUMNS`の統計情報を収集する](/statistics.md#collect-statistics-on-some-columns) | Y | E | E | E | E | E | E | | [統計情報を収集するためのメモリ割り当て量を制御する](/statistics.md#the-memory-quota-for-collecting-statistics) | E | E | E | E | E | E | N | | [約10000行のデータをランダムにサンプリングして、統計情報を素早く構築します](/system-variables.md#tidb_enable_fast_analyze) | 非推奨 | 非推奨 | 非推奨 | E | E | E | E | diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index 5c07affe4847b..bda9c4e031abf 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/tidb-partitioned-tables-best-practices/','/ja/tidb/de TiDBのパーティションテーブルは、大規模データセットの管理、クエリ効率の向上、一括データ削除の容易化、書き込みホットスポット問題の緩和など、多用途なアプローチを提供します。データを論理セグメントに分割することで、TiDBはパーティションプルーニングを活用し、クエリ実行時に不要なデータをスキップします。これにより、リソース消費が削減され、特に大規模データセットを扱うオンライン分析処理（OLAP）ワークロードにおいてパフォーマンスが向上します。 -一般的なユースケースとしては、 [範囲分割](/partitioned-table.md#range-partitioning)とローカルインデックスを組み合わせて、 [`ALTER TABLE ... DROP PARTITION`](/sql-statements/sql-statement-alter-table.md)などの操作で履歴データを効率的にクリーンアップすることが挙げられます。この方法では、古いデータがほぼ瞬時に削除され、パーティションキーによるフィルタリング時に高いクエリ効率が維持されます。ただし、パーティション化されていないテーブルからパーティション化されたテーブルに移行した後、パーティションキーフィルターがないクエリなど、パーティションプルーニングのメリットを享受できないクエリでは、パフォーマンスが低下する可能性があります。このような場合、 [グローバルインデックス](/partitioned-table.md#global-indexes)を使用してすべてのパーティションに統一されたインデックス構造を提供することで、パフォーマンスへの影響を軽減できます。 +一般的なユースケースとしては、 [レンジパーティショニング](/partitioned-table.md#range-partitioning)とローカルインデックスを組み合わせて、 [`ALTER TABLE ... DROP PARTITION`](/sql-statements/sql-statement-alter-table.md)などの操作で履歴データを効率的にクリーンアップすることが挙げられます。この方法では、古いデータがほぼ瞬時に削除され、パーティションキーによるフィルタリング時に高いクエリ効率が維持されます。ただし、パーティション化されていないテーブルからパーティション化されたテーブルに移行した後、パーティションキーフィルターがないクエリなど、パーティションプルーニングのメリットを享受できないクエリでは、パフォーマンスが低下する可能性があります。このような場合、 [グローバルインデックス](/partitioned-table.md#global-indexes)を使用してすべてのパーティションに統一されたインデックス構造を提供することで、パフォーマンスへの影響を軽減できます。 もう1つのシナリオは、ハッシュまたはキーパーティショニングを使用して書き込みホットスポットの問題に対処することです。特に、 [`AUTO_INCREMENT`](/auto-increment.md) IDを使用するワークロードでは、シーケンシャルな挿入によって特定のTiKVリージョンに過負荷がかかる可能性があります。書き込みをパーティションに分散させることでワークロードのバランスを取ることができますが、レンジパーティショニングと同様に、パーティションプルーニング条件のないクエリではパフォーマンスが低下する可能性があります。このような状況では、グローバルインデックスが役立ちます。 @@ -59,7 +59,7 @@ TiDBでは、パーティションテーブルはデフォルトでローカル テストでは次の構成を使用します。 -- パーティションテーブルには、 `date`列で定義された 365 個の範囲パーティションが含まれています。 +- パーティションテーブルには、 `date`列で定義された 365 個のレンジパーティションが含まれています。 - ワークロードは、各インデックスキーが複数の行と一致する大量の OLTP クエリパターンをシミュレートします。 - このテストでは、さまざまなパーティション数も評価し、パーティションの粒度がクエリのレイテンシーとインデックスの効率にどのように影響するかを測定します。 @@ -112,7 +112,7 @@ WHERE `fa`.`sid` IN ( #### テスト結果 {#test-results} -次の表は、365 個の範囲パーティションを持つテーブルから 400 行を返すクエリの結果を示しています。 +次の表は、365 個のレンジパーティションを持つテーブルから 400 行を返すクエリの結果を示しています。 | コンフィグレーション | 平均クエリ時間 | COP タスク（インデックススキャン） | COP タスク（テーブル検索） | COP タスクの合計 | | ------------------------- | ------- | ------------------ | ------------- | -------- | @@ -284,7 +284,7 @@ TTL=`expire_time` + INTERVAL 0 DAY TTL_ENABLE='ON' TTL_JOB_INTERVAL='10m'; ``` -次の例は、Range INTERVAL パーティション化を使用するパーティションテーブルを示しています。 +次の例は、レンジ INTERVAL パーティショニングを使用するパーティションテーブルを示しています。 ```sql CREATE TABLE `ad_cache` ( @@ -440,7 +440,7 @@ PARTITION BY KEY (id) PARTITIONS 16; ### ホットスポットを読む {#read-hotspots} -範囲パーティション化されたテーブルでは、クエリがパーティションキーでデータをフィルター処理しない場合、新しい空のパーティションが読み取りホットスポットになる可能性があります。 +レンジパーティション化されたテーブルでは、クエリがパーティションキーでデータをフィルター処理しない場合、新しい空のパーティションが読み取りホットスポットになる可能性があります。 **根本的な原因：** @@ -491,7 +491,7 @@ TiDBでは、新しく作成されたパーティションは、最初は1つの #### ベストプラクティス {#best-practices} -新しい範囲パーティションによって発生するホットスポットの問題を軽減するには、次の手順に従います。 +新しいレンジパーティションによって発生するホットスポットの問題を軽減するには、次の手順に従います。 ##### ステップ1. `SHARD_ROW_ID_BITS`と`PRE_SPLIT_REGIONS`を使用する {#step-1-use-shard-row-id-bits-and-pre-split-regions} @@ -599,13 +599,13 @@ SHOW TABLE employees PARTITION (p4) regions; #### ベストプラクティス {#best-practices} -新しい範囲パーティションによって発生するホットスポットの問題を軽減するには、 [非クラスター化パーティションテーブルのベストプラクティス](#best-practices)手順に従います。 +新しいレンジパーティションによって発生するホットスポットの問題を軽減するには、 [非クラスター化パーティションテーブルのベストプラクティス](#best-practices)手順に従います。 ### クラスター化された非パーティションテーブルのソリューション {#solutions-for-clustered-non-partitioned-tables} #### 利点 {#advantages} -- 新しい範囲パーティションによるホットスポットのリスクはありません。 +- 新しいレンジパーティションによるホットスポットのリスクはありません。 - ポイントおよび範囲クエリの読み取りパフォーマンスが良好です。 #### デメリット {#disadvantages} diff --git a/global-indexes.md b/global-indexes.md index 8c5bf8c01b24d..6b725148a5135 100644 --- a/global-indexes.md +++ b/global-indexes.md @@ -301,20 +301,20 @@ FROM sbtest WHERE k IN (xx, xx, xx) ``` -範囲パーティション（100 パーティション）: +レンジパーティション（100 パーティション）: | テーブルタイプ | 同時実行1 | 同時実行数 32 | 同時実行数 64 | 平均RU | | ----------------------------------------------- | ----- | -------- | -------- | ------ | | クラスター化された非パーティションテーブル | 225 | 19,999 | 30,293 | 7.92 | -| PK でパーティション化されたクラスター化テーブル範囲 | 68 | 480 | 511 | 114.87 | -| PK によって範囲分割されたクラスター化テーブル、 `k` `c`グローバルインデックスあり | 207 | 17,798 | 27,707 | 11.73 | +| PK によってレンジ分割されたクラスター化テーブル | 68 | 480 | 511 | 114.87 | +| PK によってレンジ分割されたクラスター化テーブル、 `k` `c`グローバルインデックスあり | 207 | 17,798 | 27,707 | 11.73 | ハッシュパーティション（100パーティション）: | テーブルタイプ | 同時実行1 | 同時実行数 32 | 同時実行数 64 | 平均RU | | ------------------------------------------- | ----- | -------- | -------- | ------ | | クラスター化された非パーティションテーブル | 166 | 20,361 | 28,922 | 7.86 | -| PK で分割されたクラスター化テーブルハッシュ | 60 | 244 | 283 | 119.73 | +| PK によってハッシュ分割されたクラスター化テーブル | 60 | 244 | 283 | 119.73 | | PKでハッシュ分割されたクラスター化テーブル、 `k` `c`グローバルインデックスあり | 156 | 18,233 | 15,581 | 10.77 | 前述のテストでは、高同時実行環境において、グローバルインデックスによってパーティションテーブルのクエリパフォーマンスが大幅に向上し、最大50倍のパフォーマンス向上が実現できることが実証されています。さらに、グローバルインデックスはリクエストユニット（RU）の消費量を大幅に削減します。パーティション数が増えるにつれて、パフォーマンスのメリットはさらに顕著になります。 diff --git a/mysql-compatibility.md b/mysql-compatibility.md index aef24522d3fc5..001733ecef024 100644 --- a/mysql-compatibility.md +++ b/mysql-compatibility.md @@ -187,7 +187,7 @@ TiDBでは、サポートされているすべてのDDL変更をオンライン - `CLUSTERED`タイプの主キーの追加/削除はサポートされていません。 `CLUSTERED`タイプの主キーの詳細については、[クラスター化インデックス](/clustered-indexes.md)を参照してください。 - 異なるタイプのインデックス（ `HASH|BTREE|RTREE|FULLTEXT` ）はサポートされておらず、指定されても解析されて無視されます。 - TiDB は`HASH` 、 `RANGE` 、 `LIST` 、および`KEY`パーティションタイプをサポートしています。サポートされていないパーティションタイプの場合、TiDB は`Warning: Unsupported partition type %s, treat as normal table`を返します。ここで、 `%s`はサポートされていない特定のパーティションタイプです。 -- Range、Range COLUMNS、List、およびList COLUMNSパーティションテーブルは、 `ADD` 、 `DROP` 、 `TRUNCATE` 、および`REORGANIZE`操作をサポートします。その他のパーティション操作は無視されます。 +- レンジ、レンジCOLUMNS、リスト、およびリストCOLUMNSパーティションテーブルは、 `ADD` 、 `DROP` 、 `TRUNCATE` 、および`REORGANIZE`操作をサポートします。その他のパーティション操作は無視されます。 - ハッシュおよびキーパーティションテーブルは`ADD` 、 `COALESCE` 、および`TRUNCATE`操作をサポートします。その他のパーティション操作は無視されます。 - パーティションテーブルでは、以下の構文はサポートされていません。 diff --git a/partition-pruning.md b/partition-pruning.md index 4944cd922d8ab..1b22363c47742 100644 --- a/partition-pruning.md +++ b/partition-pruning.md @@ -39,7 +39,7 @@ EXPLAIN SELECT * FROM t1 WHERE id BETWEEN 80 AND 120; ## パーティションプルーニングの使用シナリオ {#usage-scenarios-of-partition-pruning} -パーティションプルーニングの使用シナリオは、範囲パーティションテーブルとハッシュパーティションテーブルという 2種類のパーティションテーブルで異なります。 +パーティションプルーニングの使用シナリオは、レンジパーティションテーブルとハッシュパーティションテーブルという 2種類のパーティションテーブルで異なります。 ### ハッシュパーティションテーブルでパーティションプルーニングを使用する {#use-partition-pruning-in-hash-partitioned-tables} @@ -133,13 +133,13 @@ explain select * from t2 where x = (select * from t1 where t2.x = t1.x and t2.x このクエリは、テーブル`t2`から行を読み取るたびに、パーティションテーブル`t1`に対してクエリを実行します。理論上は、この時点でフィルタ条件`t1.x = val`が満たされますが、実際にはパーティションプルーニングはクエリプランの生成フェーズでのみ有効であり、実行フェーズでは有効ではありません。 -### 範囲パーティション化されたテーブルでパーティションプルーニングを使用する {#use-partition-pruning-in-range-partitioned-tables} +### レンジパーティション化されたテーブルでパーティションプルーニングを使用する {#use-partition-pruning-in-range-partitioned-tables} -このセクションでは、範囲パーティション化されたテーブルでのパーティションプルーニングの適用可能な使用シナリオと適用できない使用シナリオについて説明します。 +このセクションでは、レンジパーティション化されたテーブルでのパーティションプルーニングの適用可能な使用シナリオと適用できない使用シナリオについて説明します。 -#### 範囲パーティションテーブルに適用可能なシナリオ {#applicable-scenarios-in-range-partitioned-tables} +#### レンジパーティションテーブルに適用可能なシナリオ {#applicable-scenarios-in-range-partitioned-tables} -このセクションでは、範囲パーティション化されたテーブルでのパーティションプルーニングの適用可能な 3つの使用シナリオについて説明します。 +このセクションでは、レンジパーティション化されたテーブルでのパーティションプルーニングの適用可能な 3つの使用シナリオについて説明します。 ##### シナリオ1 {#scenario-one} @@ -247,7 +247,7 @@ explain select * from t where id > '2020-04-18'; +-------------------------+----------+-----------+-----------------------+-------------------------------------------+ ``` -#### 範囲パーティションテーブルでは適用できないシナリオ {#inapplicable-scenario-in-range-partitioned-tables} +#### レンジパーティションテーブルでは適用できないシナリオ {#inapplicable-scenario-in-range-partitioned-tables} パーティションプルーニングのルール最適化はクエリプランの生成フェーズで実行されるため、フィルタ条件が実行フェーズでのみ取得できるシナリオには適していません。例えば、次のようになります。 diff --git a/partitioned-table.md b/partitioned-table.md index d4d072c226d07..49cb1dc9e14b0 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -9,12 +9,12 @@ summary: TiDBにおけるパーティショニングの使い方を学びまし ## パーティショニングの種類 {#partitioning-types} -このセクションでは、TiDB のパーティショニングの種類を紹介します。現在、TiDB は[範囲分割](#range-partitioning)、[範囲列パーティショニング](#range-columns-partitioning)ショニング、 [List パーティショニング](#list-partitioning)、 [List COLUMNS パーティショニング](#list-columns-partitioning)、[ハッシュパーティショニング](#hash-partitioning)、および[キーパーティショニング](#key-partitioning)をサポートしています。 +このセクションでは、TiDB のパーティショニングの種類を紹介します。現在、TiDB は[レンジパーティショニング](#range-partitioning)、[レンジCOLUMNSパーティショニング](#range-columns-partitioning)、[リストパーティショニング](#list-partitioning)、[リストCOLUMNSパーティショニング](#list-columns-partitioning)、[ハッシュパーティショニング](#hash-partitioning)、および[キーパーティショニング](#key-partitioning)をサポートしています。 -- 範囲パーティショニング、範囲列パーティショニング、List パーティショニング、およびList COLUMNS パーティショニングは、アプリケーション内での大量の削除によって引き起こされるパフォーマンスの問題を解決し、パーティションを迅速に削除するために使用されます。 +- レンジパーティショニング、レンジCOLUMNSパーティショニング、リストパーティショニング、およびリストCOLUMNSパーティショニングは、アプリケーション内での大量の削除によって引き起こされるパフォーマンスの問題を解決し、パーティションを迅速に削除するために使用されます。 - ハッシュパーティショニングとキーパーティショニングは、書き込み回数が多いシナリオでデータを分散するために使用されます。ハッシュパーティショニングと比較して、キーパーティショニングは複数の列のデータ分散と、非整数列によるパーティショニングをサポートします。 -### 範囲分割 {#range-partitioning} +### レンジパーティショニング {#range-partitioning} テーブルが範囲によってパーティション分割されている場合、各パーティションには、パーティション式値が指定された範囲内にある行が含まれます。範囲は連続している必要がありますが、重複してはなりません。これは`VALUES LESS THAN`を使用して定義できます。 @@ -53,7 +53,7 @@ PARTITION BY RANGE (store_id) ( ); ``` -このパーティション方式では、 `store_id`が 1 ～ 5 である従業員に対応するすべての行が`p0`パーティションに格納され、 `store_id`が 6 ～ 10 である従業員はすべて`p1`パーティションに格納されます。範囲パーティショニングでは、パーティションを最小値から最大値の順に並べる必要があります。 +このパーティション方式では、 `store_id`が 1 ～ 5 である従業員に対応するすべての行が`p0`パーティションに格納され、 `store_id`が 6 ～ 10 である従業員はすべて`p1`パーティションに格納されます。レンジパーティショニングでは、パーティションを最小値から最大値の順に並べる必要があります。 `(72, 'Tom', 'John', '2015-06-25', NULL, NULL, 15)`のデータ行を挿入すると、 `p2`パーティションに配置されます。しかし、 `store_id`が 20 より大きいレコードを挿入すると、TiDB はこのレコードをどのパーティションに挿入すべきかを判断できないため、エラーが報告されます。この場合、テーブルを作成する際に`MAXVALUE`を使用できます。 @@ -121,7 +121,7 @@ PARTITION BY RANGE ( YEAR(separated) ) ( ); ``` -範囲パーティショニングでは、 `timestamp`列の値に基づいてパーティショニングを行い、 `unix_timestamp()`関数を使用できます。例： +レンジパーティショニングでは、 `timestamp`列の値に基づいてパーティショニングを行い、 `unix_timestamp()`関数を使用できます。例： ```sql CREATE TABLE quarterly_report_status ( @@ -146,17 +146,17 @@ PARTITION BY RANGE ( UNIX_TIMESTAMP(report_updated) ) ( タイムスタンプ列を含む他のパーティショニング式を使用することは許可されていません。 -範囲分割は、以下の条件の1つ以上が満たされる場合に特に有効です。 +レンジパーティショニングは、以下の条件の1つ以上が満たされる場合に特に有効です。 - 古いデータを削除したい場合、前の例の`employees` `ALTER TABLE employees DROP PARTITION p0;` `DELETE FROM employees WHERE YEAR(separated) <= 1990;`操作を実行するよりも高速です。 - 時刻や日付の値を含む列、または他の系列から得られた値を含む列を使用したい場合。 - パーティショニングに使用される列に対して、頻繁にクエリを実行する必要があります。たとえば、 `EXPLAIN SELECT COUNT(*) FROM employees WHERE separated BETWEEN '2000-01-01' AND '2000-12-31' GROUP BY store_id;`のようなクエリを実行すると、他のパーティション`p2`の条件に一致しないため、 `WHERE`パーティション内のデータのみをスキャンする必要があることを TiDB は迅速に認識できます。 -### 範囲列パーティショニング {#range-columns-partitioning} +### レンジCOLUMNSパーティショニング {#range-columns-partitioning} -範囲列パーティショニングは、範囲パーティショニングのバリアントです。1つ以上の列をパーティショニング キーとして使用できます。パーティション列のデータ型は、整数、文字列 ( `CHAR`または`VARCHAR` )、 `DATE` 、および`DATETIME` 。列を使用しないパーティショニングなどの式はサポートされていません。 +レンジCOLUMNSパーティショニングは、レンジパーティショニングのバリアントです。1つ以上の列をパーティショニング キーとして使用できます。パーティション列には、整数、文字列（`CHAR`または`VARCHAR`）、`DATE`、および`DATETIME`のデータ型を使用できます。列を使用しない式によるパーティショニングなどはサポートされていません。 -範囲パーティショニングと同様に、範囲列パーティショニングでも、パーティション範囲は厳密に増加している必要があります。次の例のパーティション定義はサポートされていません。 +レンジパーティショニングと同様に、レンジCOLUMNSパーティショニングでも、パーティション範囲は厳密に増加している必要があります。次の例のパーティション定義はサポートされていません。 ```sql CREATE TABLE t( @@ -192,9 +192,9 @@ PARTITION BY RANGE COLUMNS(name, valid_until) 上記の SQL文は`[ ('', ''), ('G', '2023-01-01 00:00:00') )` 、 `[ ('G', '2023-01-01 00:00:00'), ('G', '2024-01-01 00:00:00') )` 、 `[ ('G', '2024-01-01 00:00:00'), ('M', '2023-01-01 00:00:00') )` 、 `[ ('M', '2023-01-01 00:00:00'), ('M', '2024-01-01 00:00:00') )` 、 `[ ('M', '2024-01-01 00:00:00'), ('S', '2023-01-01 00:00:00') )` 、および`[ ('S', '2023-01-01 00:00:00'), ('S', '2024-01-01 00:00:00') )`範囲内で、年と名前でデータをパーティション分割します。これにより、 `name`と`valid_until`の両方でパーティションプルーニングのメリットを享受しながら、無効なデータを簡単に削除できます。この例では、 `[,)`左が閉じられ、右が開いている範囲を示しています。例えば、 `[ ('G', '2023-01-01 00:00:00'), ('G', '2024-01-01 00:00:00') )` 、名前が`'G'`であるデータの範囲を示します。このデータの範囲には`2023-01-01 00:00:00`が含まれ、 `2023-01-01 00:00:00`より大きく、 `2024-01-01 00:00:00`より小さい値です。 `(G, 2024-01-01 00:00:00)`は含まれません。 -### 範囲 INTERVAL 分割 {#range-interval-partitioning} +### レンジ INTERVAL パーティショニング {#range-interval-partitioning} -範囲パーティショニング（INTERVALパーティショニング）は、範囲パーティショニングの拡張機能であり、指定した間隔のパーティションを簡単に作成できます。バージョン6.3.0以降、TIDBでは構文糖衣としてINTERVALパーティショニングが導入されています。 +レンジパーティショニング（INTERVAL パーティショニング）は、レンジパーティショニングの拡張機能であり、指定した間隔のパーティションを簡単に作成できます。バージョン6.3.0以降、TIDBでは構文糖衣としてINTERVAL パーティショニングが導入されています。 構文は以下のとおりです。 @@ -243,7 +243,7 @@ PARTITION BY RANGE (`id`) PARTITION `P_MAXVALUE` VALUES LESS THAN (MAXVALUE)) ``` -範囲間隔パーティショニングは[範囲列](#range-columns-partitioning)パーティショニングでも機能します。 +レンジ INTERVAL パーティショニングは[レンジCOLUMNS](#range-columns-partitioning)パーティショニングでも機能します。 例えば： @@ -274,13 +274,13 @@ PARTITION BY RANGE COLUMNS(`report_date`) PARTITION `P_LT_2025-01-01` VALUES LESS THAN ('2025-01-01')) ``` -オプションのパラメータ`NULL PARTITION` 、 `PARTITION P_NULL VALUES LESS THAN ()`として定義されたパーティションを作成します。パーティション式が`NULL`と評価される場合にのみ一致します。 `NULL`が他の値より小さいとみなされることを説明する [範囲分割によるNULL値の処理](#handling-of-null-with-range-partitioning)を参照してください。 +オプションのパラメータ`NULL PARTITION` 、 `PARTITION P_NULL VALUES LESS THAN ()`として定義されたパーティションを作成します。パーティション式が`NULL`と評価される場合にのみ一致します。 `NULL`が他の値より小さいとみなされることを説明する [レンジパーティショニングによるNULL値の処理](#handling-of-null-with-range-partitioning)を参照してください。 オプションパラメータ`MAXVALUE PARTITION`最後のパーティションを`PARTITION P_MAXVALUE VALUES LESS THAN (MAXVALUE)`として作成します。 #### ALTER INTERVAL パーティションテーブル {#alter-interval-partitioned-tables} -INTERVALパーティショニングでは、パーティションの追加と削除のための構文もよりシンプルになります。 +INTERVAL パーティショニングでは、パーティションの追加と削除のための構文もよりシンプルになります。 次のステートメントは、最初のパーティションを変更します。指定された式よりも小さい値を持つすべてのパーティションを削除し、一致したパーティションを新しい最初のパーティションにします。NULL パーティションには影響しません。 @@ -294,16 +294,16 @@ ALTER TABLE table_name FIRST PARTITION LESS THAN () ALTER TABLE table_name LAST PARTITION LESS THAN () ``` -#### INTERVALパーティショニングの詳細と制限事項 {#interval-partitioning-details-and-limitations} +#### INTERVAL パーティショニングの詳細と制限事項 {#interval-partitioning-details-and-limitations} -- INTERVALパーティショニング機能は、 `CREATE/ALTER TABLE`構文のみを使用します。メタデータに変更はないため、新しい構文で作成または変更されたテーブルは引き続きMySQLと互換性があります。 +- INTERVAL パーティショニング機能は、 `CREATE/ALTER TABLE`構文のみを使用します。メタデータに変更はないため、新しい構文で作成または変更されたテーブルは引き続きMySQLと互換性があります。 - MySQLとの互換性を維持するため、 `SHOW CREATE TABLE`の出力形式に変更はありません。 - 新しい`ALTER`構文は、INTERVAL に準拠する既存のテーブルに適用されます。これらのテーブルを`INTERVAL`構文で作成する必要はありません。 - `INTERVAL`パーティショニングに`RANGE COLUMNS`構文を使用する場合、パーティショニングキーとして指定できる列は`INTEGER` 、 `DATE` 、または`DATETIME`型の単一の列のみです。 -### List パーティショニング {#list-partitioning} +### リストパーティショニング {#list-partitioning} -List パーティショニングは、範囲パーティショニングと似ています。範囲パーティショニングとは異なり、List パーティショニングでは、各パーティション内のすべての行のパーティショニング式の値は、指定された値セットに含まれます。各パーティションに定義されるこの値セットには、任意の数の値を含めることができますが、重複する値を含めることはできません。値セットを定義するには、 `PARTITION ... VALUES IN (...)`句を使用できます。 +リストパーティショニングは、レンジパーティショニングと似ています。レンジパーティショニングとは異なり、リストパーティショニングでは、各パーティション内のすべての行のパーティショニング式の値は、指定された値セットに含まれます。各パーティションに定義されるこの値セットには、任意の数の値を含めることができますが、重複する値を含めることはできません。値セットを定義するには、 `PARTITION ... VALUES IN (...)`句を使用できます。 人事記録テーブルを作成したいとします。テーブルは次のように作成できます。 @@ -348,11 +348,11 @@ PARTITION BY LIST (store_id) ( #### デフォルトリストパーティション {#default-list-partition} -バージョン7.3.0以降では、リストまたはリスト列でパーティションテーブルにデフォルトパーティションを追加できます。デフォルトパーティションはフォールバックパーティションとして機能し、どのパーティションの値セットにも一致しない行を配置できます。 +バージョン7.3.0以降では、リストまたはリストCOLUMNSパーティションテーブルにデフォルトパーティションを追加できます。デフォルトパーティションはフォールバックパーティションとして機能し、どのパーティションの値セットにも一致しない行を配置できます。 > **Note:** > -> この機能は、MySQL構文に対するTiDBの拡張機能です。デフォルトのパーティションを持つListまたはList COLUMNSパーティションテーブルの場合、テーブル内のデータをMySQLに直接レプリケートすることはできません。 +> この機能は、MySQL構文に対するTiDBの拡張機能です。デフォルトのパーティションを持つリストまたはリストCOLUMNSパーティションテーブルの場合、テーブル内のデータをMySQLに直接レプリケートすることはできません。 次のリストパーティションテーブルを例として考えてみましょう。 @@ -387,7 +387,7 @@ INSERT INTO t VALUES (7, 7); Query OK, 1 row affected (0.01 sec) ``` -リストまたはリスト列パーティションテーブルを作成する際に、デフォルトのパーティションを追加することもできます。例： +リストまたはリストCOLUMNSパーティションテーブルを作成する際に、デフォルトのパーティションを追加することもできます。例： ```sql CREATE TABLE employees ( @@ -442,9 +442,9 @@ test> select * from t; 3 rows in set (0.01 sec) ``` -### List COLUMNS パーティショニング {#list-columns-partitioning} +### リストCOLUMNSパーティショニング {#list-columns-partitioning} -List COLUMNS パーティショニングは、List パーティショニングの一種です。複数の列をパーティションキーとして使用できます。整数データ型の他に、文字列、 `DATE` 、および`DATETIME`データ型の列もパーティション列として使用できます。 +リストCOLUMNSパーティショニングは、リストパーティショニングの一種です。複数の列をパーティションキーとして使用できます。整数データ型の他に、文字列、 `DATE` 、および`DATETIME`データ型の列もパーティション列として使用できます。 次の表に示すように、以下の12都市の店舗従業員を4つの地域に分けたいとします。 @@ -457,7 +457,7 @@ List COLUMNS パーティショニングは、List パーティショニング | 4 | Atlanta, Raleigh, Cincinnati | ``` -以下に示すように、List COLUMNS パーティショニングを使用してテーブルを作成し、各行を従業員の都市に対応するパーティションに格納することができます。 +以下に示すように、リストCOLUMNSパーティショニングを使用してテーブルを作成し、各行を従業員の都市に対応するパーティションに格納することができます。 ```sql CREATE TABLE employees_1 ( @@ -478,9 +478,9 @@ PARTITION BY LIST COLUMNS(city) ( ); ``` -List パーティショニングとは異なり、List COLUMNS パーティショニングでは、列の値を整数に変換するために`COLUMNS()`句の式を使用する必要はありません。 +リストパーティショニングとは異なり、リストCOLUMNSパーティショニングでは、列の値を整数に変換するために`COLUMNS()`句の式を使用する必要はありません。 -List COLUMNS パーティショニングは、次の例に示すように、 `DATE`型と`DATETIME`型の列を使用して実装することもできます。この例では、前の`employees_1`テーブルと同じ名前と列を使用していますが、 `hired`列に基づくList COLUMNS パーティショニングを使用しています。 +リストCOLUMNSパーティショニングは、次の例に示すように、 `DATE`型と`DATETIME`型の列を使用して実装することもできます。この例では、前の`employees_1`テーブルと同じ名前と列を使用していますが、 `hired`列に基づくリストCOLUMNSパーティショニングを使用しています。 ```sql CREATE TABLE employees_2 ( @@ -521,7 +521,7 @@ PARTITION BY LIST COLUMNS(id,name) ( ### ハッシュパーティショニング {#hash-partitioning} -ハッシュパーティショニングは、データが一定数のパーティションに均等に分散されるようにするために使用されます。範囲パーティショニングを使用する場合は、各パーティションの列値の範囲を指定する必要がありますが、ハッシュパーティショニングを使用する場合は、パーティションの数を指定するだけで済みます。 +ハッシュパーティショニングは、データが一定数のパーティションに均等に分散されるようにするために使用されます。レンジパーティショニングを使用する場合は、各パーティションの列値の範囲を指定する必要がありますが、ハッシュパーティショニングを使用する場合は、パーティションの数を指定するだけで済みます。 ハッシュパーティションテーブルを作成するには、 `CREATE TABLE`ステートメントに`PARTITION BY HASH (expr)`句を追加する必要があります。 `expr`は整数を返す式です。この列の型が整数型の場合は、列名にすることができます。さらに、 `PARTITIONS num`を追加する必要がある場合もあります。ここで、 `num`は、テーブルが分割されるパーティションの数を示す正の整数です。 @@ -701,11 +701,11 @@ TiDBでは`NULL`パーティショニング式の計算結果として使用す > **Note:** > -> `NULL`整数ではありません。TiDB のパーティショニング実装では`NULL`は、 `ORDER BY`と同様に、他のどの整数値よりも小さい値として扱われます。 +> `NULL`は整数ではありません。TiDB のパーティショニング実装では`NULL`は、 `ORDER BY`と同様に、他のどの整数値よりも小さい値として扱われます。 -#### 範囲分割によるNULL値の処理 {#handling-of-null-with-range-partitioning} +#### レンジパーティショニングによるNULL値の処理 {#handling-of-null-with-range-partitioning} -範囲でパーティション分けされたテーブルに行を挿入し、パーティションを決定するために使用される列の値が`NULL`の場合、この行は最も低いパーティションに挿入されます。 +レンジでパーティション分けされたテーブルに行を挿入し、パーティションを決定するために使用される列の値が`NULL`の場合、この行は最も低いパーティションに挿入されます。 ```sql CREATE TABLE t1 ( @@ -827,7 +827,7 @@ Empty set (0.00 sec) > > この場合、TiDBの実際の動作はこの文書の説明と一致しています。 -#### キー分割によるNULLの処理 {#handling-of-null-with-key-partitioning} +#### キーパーティショニングによるNULLの処理 {#handling-of-null-with-key-partitioning} キーパーティショニングの場合、 `NULL`値の処理方法はハッシュパーティショニングと同様です。パーティショニングフィールドの値が`NULL`の場合、 `0`として扱われます。 @@ -869,9 +869,9 @@ TiDBには`EXCHANGE PARTITION`に影響を与える可能性のある特定の - TiCDC: TiCDC は、パーティション化されたテーブルとパーティション化されていないテーブルの両方に主キーまたは一意キーが存在する場合に`EXCHANGE PARTITION`操作を複製します。それ以外の場合は、TiCDC は操作を複製しません。 - TiDB LightningおよびBR: TiDB Lightningを使用したインポート時、またはBRを使用したリストア時に`EXCHANGE PARTITION`操作を実行しないでください。 -### 範囲、範囲列、リスト、およびリスト列パーティションの管理 {#manage-range-range-columns-list-and-list-columns-partitions} +### レンジ、レンジCOLUMNS、リスト、およびリストCOLUMNSパーティションの管理 {#manage-range-range-columns-list-and-list-columns-partitions} -このセクションでは、以下の SQL文によって作成されたパーティションテーブルを例として、範囲パーティションとリストパーティションの管理方法を示します。 +このセクションでは、以下の SQL文によって作成されたパーティションテーブルを例として、レンジパーティションとリストパーティションの管理方法を示します。 ```sql CREATE TABLE members ( @@ -926,7 +926,7 @@ ALTER TABLE members ADD PARTITION (PARTITION `p1990to2010` VALUES LESS THAN (201 ALTER TABLE member_level ADD PARTITION (PARTITION l5_6 VALUES IN (5,6)); ``` -範囲パーティションテーブルの場合、 `ADD PARTITION`既存の最後のパーティションの後に新しいパーティションを追加します。既存のパーティションと比較して、新しいパーティションに対して`VALUES LESS THAN`で定義された値は、より大きくなければなりません。そうでない場合は、エラーが報告されます。 +レンジパーティションテーブルの場合、 `ADD PARTITION`既存の最後のパーティションの後に新しいパーティションを追加します。既存のパーティションと比較して、新しいパーティションに対して`VALUES LESS THAN`で定義された値は、より大きくなければなりません。そうでない場合は、エラーが報告されます。 ```sql ALTER TABLE members ADD PARTITION (PARTITION p1990 VALUES LESS THAN (2000)); @@ -976,9 +976,9 @@ ALTER TABLE member_level REORGANIZE PARTITION l1_2,l3,l4,l5,l6 INTO パーティションを再編成する際には、以下の重要な点に注意してください。 -- パーティションの再編成（パーティションのマージや分割を含む）を行うと、一覧表示されているパーティションが新しいパーティション定義のセットに変わりますが、パーティショニングの種類（たとえば、リスト型を範囲型に変更したり、範囲列型を範囲型に変更したり）は変更できません。 +- パーティションの再編成（パーティションのマージや分割を含む）を行うと、一覧表示されているパーティションが新しいパーティション定義のセットに変わりますが、パーティショニングの種類（たとえば、リスト型をレンジ型に変更したり、レンジCOLUMNS型をレンジ型に変更したり）は変更できません。 -- 範囲パーティションテーブルの場合、その中の隣接するパーティションのみを再編成できます。 +- レンジパーティションテーブルの場合、その中の隣接するパーティションのみを再編成できます。 ```sql ALTER TABLE members REORGANIZE PARTITION p1800,p2000 INTO (PARTITION p2000 VALUES LESS THAN (2100)); @@ -988,7 +988,7 @@ ALTER TABLE member_level REORGANIZE PARTITION l1_2,l3,l4,l5,l6 INTO ERROR 8200 (HY000): Unsupported REORGANIZE PARTITION of RANGE; not adjacent partitions ``` -- 範囲パーティションテーブルの場合、範囲の末尾を変更するには、 `VALUES LESS THAN`で定義された新しい末尾が、最後のパーティション内の既存の行をすべてカバーしている必要があります。そうでない場合、既存の行が範囲に収まらなくなり、エラーが報告されます。 +- レンジパーティションテーブルの場合、範囲の末尾を変更するには、 `VALUES LESS THAN`で定義された新しい末尾が、最後のパーティション内の既存の行をすべてカバーしている必要があります。そうでない場合、既存の行が範囲に収まらなくなり、エラーが報告されます。 ```sql INSERT INTO members VALUES (313, "John", "Doe", "2022-11-22", NULL); @@ -1053,7 +1053,7 @@ ALTER TABLE example ADD PARTITION #### パーティション数を減らす {#decrease-the-number-of-partitions} -範囲パーティショニングやList パーティショニングとは異なり、 `DROP PARTITION`はハッシュパーティショニングやキーパーティショニングではサポートされていませんが、 `COALESCE PARTITION`を使用してパーティション数を減らしたり、 `TRUNCATE PARTITION`を使用して特定のパーティションからすべてのデータを削除したりすることは可能です。 +レンジパーティショニングやリストパーティショニングとは異なり、 `DROP PARTITION`はハッシュパーティショニングやキーパーティショニングではサポートされていませんが、 `COALESCE PARTITION`を使用してパーティション数を減らしたり、 `TRUNCATE PARTITION`を使用して特定のパーティションからすべてのデータを削除したりすることは可能です。 `example`テーブルのパーティション数を 1 減らします (5 から 4 へ)。 @@ -1251,7 +1251,7 @@ SELECT fname, lname, region_code, dob 4. ハッシュおよびキーのパーティションタイプの場合、パーティションプルーニングでサポートされるクエリは、等しい条件のみです。 -5. 範囲パーティションの場合、パーティションプルーニングを有効にするには、パーティション式が`col`または`fn(col)`の形式である必要があり、クエリ条件は`>` 、 `<` 、 `=` 、 `>=`、および`<=`のいずれかである必要があります。パーティション式が`fn(col)`の形式の場合、 `fn`関数は単調である必要があります。 +5. レンジパーティションの場合、パーティションプルーニングを有効にするには、パーティション式が`col`または`fn(col)`の形式である必要があり、クエリ条件は`>` 、 `<` 、 `=` 、 `>=`、および`<=`のいずれかである必要があります。パーティション式が`fn(col)`の形式の場合、 `fn`関数は単調である必要があります。 `fn`関数が単調である場合、任意の`x`および`y`に対して、 `x > y`ならば`fn(x) > fn(y)`となります。この`fn`関数は厳密に単調であると言えます。任意の`x`および`y`に対して、 `x > y`ならば`fn(x) >= fn(y)`となります。この場合、 `fn`は「単調」とも呼ばれます。理論的には、すべての単調関数はパーティションプルーニングによってサポートされます。 @@ -1394,7 +1394,7 @@ SELECT store_id, COUNT(department_id) AS c 2 rows in set (0.00 sec) ``` -パーティション選択は、範囲パーティショニングやハッシュパーティショニングを含む、すべてのタイプのテーブルパーティショニングでサポートされています。ハッシュパーティションの場合、パーティション名が指定されていないときは、 `p0` 、 `p1` 、 `p2` 、...、または`pN-1`がパーティション名として自動的に使用されます。 +パーティション選択は、レンジパーティショニングやハッシュパーティショニングを含む、すべてのタイプのテーブルパーティショニングでサポートされています。ハッシュパーティションの場合、パーティション名が指定されていないときは、 `p0` 、 `p1` 、 `p2` 、...、または`pN-1`がパーティション名として自動的に使用されます。 `SELECT`内の`INSERT ... SELECT`もパーティション選択を使用できます。 @@ -1641,7 +1641,7 @@ YEARWEEK() ### MySQLとの互換性 {#compatibility-with-mysql} -現在、TiDBは範囲パーティショニング、範囲列パーティショニング、List パーティショニング、List COLUMNS パーティショニング、ハッシュパーティショニング、およびキーパーティショニングをサポートしています。MySQLで利用可能なその他のパーティショニングタイプは、TiDBではまだサポートされていません。 +現在、TiDBはレンジパーティショニング、レンジCOLUMNSパーティショニング、リストパーティショニング、リストCOLUMNSパーティショニング、ハッシュパーティショニング、およびキーパーティショニングをサポートしています。MySQLで利用可能なその他のパーティショニングタイプは、TiDBではまだサポートされていません。 サポートされていないパーティショニングタイプの場合、TiDBでテーブルを作成する際にパーティショニング情報は無視され、警告が報告された上で通常の形式でテーブルが作成されます。 diff --git a/releases/release-3.0-beta.md b/releases/release-3.0-beta.md index 7ce8ea8559b33..67efa87a29980 100644 --- a/releases/release-3.0-beta.md +++ b/releases/release-3.0-beta.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0 Beta Release Notes -summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安定性、SQLオプティマイザ、統計、実行エンジンに重点を置いています。新機能には、ビュー、ウィンドウ関数、範囲分割、ハッシュ分割のサポートが含まれます。SQLオプティマイザは、トランザクションにおけるインデックス結合のサポート、定数伝播の最適化、DO文におけるサブクエリのサポートなど、さまざまな最適化によって強化されました。SQLエグゼキューターも最適化され、パフォーマンスが向上しました。権限管理、サーバー、互換性、DDLがすべて改善されました。TiDB Lightningは単一テーブルのバッチインポートをサポートするようになり、PDとTiKVにもさまざまな機能強化と新機能が追加されました。 +summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安定性、SQLオプティマイザ、統計、実行エンジンに重点を置いています。新機能には、ビュー、ウィンドウ関数、レンジパーティショニング、ハッシュパーティショニングのサポートが含まれます。SQLオプティマイザは、トランザクションにおけるインデックス結合のサポート、定数伝播の最適化、DO文におけるサブクエリのサポートなど、さまざまな最適化によって強化されました。SQLエグゼキューターも最適化され、パフォーマンスが向上しました。権限管理、サーバー、互換性、DDLがすべて改善されました。TiDB Lightningは単一テーブルのバッチインポートをサポートするようになり、PDとTiKVにもさまざまな機能強化と新機能が追加されました。 --- # TiDB 3.0 ベータ版リリースノート {#tidb-3-0-beta-release-notes} @@ -12,7 +12,7 @@ summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安 - 新機能 - ビューをサポート - ウィンドウ関数をサポート - - 範囲分割をサポート + - レンジパーティショニングをサポート - ハッシュパーティショニングをサポート - SQLオプティマイザ - `AggregationElimination` の最適化ルールを再サポート [#7676](https://github.com/pingcap/tidb/pull/7676) @@ -75,7 +75,7 @@ summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安 - `ADD INDEX`の同時実行数の動的な調整をサポート[#8295](https://github.com/pingcap/tidb/pull/8295) - テーブルまたは列の文字セットの`utf8`/`utf8mb4`への変更をサポート [#8037](https://github.com/pingcap/tidb/pull/8037) - デフォルトの文字セットを`utf8`から`utf8mb4`に変更します [#7965](https://github.com/pingcap/tidb/pull/7965) - - 範囲パーティションをサポート[#8011](https://github.com/pingcap/tidb/pull/8011) + - レンジパーティションをサポート[#8011](https://github.com/pingcap/tidb/pull/8011) ## ツール {#tools} diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index a767c370b1f96..c1c429d36b30c 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -26,7 +26,7 @@ TiDB Ansible バージョン: 3.0.0 - ウィンドウ関数をサポート。`NTILE` 、 `LEAD` 、 `LAG` 、 `PERCENT_RANK` 、 `NTH_VALUE` 、 `CUME_DIST` 、 `FIRST_VALUE` 、 `LAST_VALUE` 、 `RANK` 、 `DENSE_RANK` 、 `ROW_NUMBER`を含む、MySQL 8.0のすべてのウィンドウ関数と互換性があります - ビューのサポート（**Experimental**） - テーブルパーティションの改善 - - 範囲パーティションをサポート + - レンジパーティションをサポート - ハッシュパーティションをサポート - IP ホワイトリスト (**Enterprise**) や監査ログ (**Enterprise**) などのプラグインをサポートするプラグインフレームワークを追加します。 - クエリの安定性を確保するために SQL 実行プランバインディングを作成する SQL プラン管理機能をサポートします (**Experimental**) diff --git a/releases/release-3.0.0-rc.2.md b/releases/release-3.0.0-rc.2.md index 3f9dc146a2a30..3191d7a66985f 100644 --- a/releases/release-3.0.0-rc.2.md +++ b/releases/release-3.0.0-rc.2.md @@ -55,7 +55,7 @@ TiDB Ansible バージョン: 3.0.0-rc.2 - ハッシュパーティション式と関数の制限を修正 [#10273](https://github.com/pingcap/tidb/pull/10273) - パーティションを含むテーブルにインデックスを追加すると、場合によっては TiDB panicが発生する問題を修正しました[#10475](https://github.com/pingcap/tidb/pull/10475) - 無効なテーブルスキーマを回避するために、DDLを実行する前にテーブル情報を検証します[#10464](https://github.com/pingcap/tidb/pull/10464) - - デフォルトでハッシュパーティションを有効にし、パーティション定義に列が1つしかない場合は範囲列パーティションを有効にします[#9936](https://github.com/pingcap/tidb/pull/9936) + - デフォルトでハッシュパーティショニングを有効にし、パーティション定義に列が1つしかない場合はレンジCOLUMNSパーティショニングを有効にします[#9936](https://github.com/pingcap/tidb/pull/9936) ## PD {#pd} diff --git a/releases/release-3.0.15.md b/releases/release-3.0.15.md index 61299b0e1da2c..0f0e988bd278d 100644 --- a/releases/release-3.0.15.md +++ b/releases/release-3.0.15.md @@ -15,7 +15,7 @@ TiDB バージョン: 3.0.15 - パーティションテーブル内のクエリでプランキャッシュ機能の使用を禁止する[#16759](https://github.com/pingcap/tidb/pull/16759) - パーティションテーブル の`admin recover index`と`admin check index`文をサポートします [#17390](https://github.com/pingcap/tidb/pull/17390) [#17315](https://github.com/pingcap/tidb/pull/17315) - - 範囲パーティションテーブルの条件`in`のパーティションプルーニングをサポート [#17318](https://github.com/pingcap/tidb/pull/17318) + - レンジパーティションテーブルの条件`in`のパーティションプルーニングをサポート [#17318](https://github.com/pingcap/tidb/pull/17318) - `SHOW CREATE TABLE`の出力を最適化し、パーティション名に引用符を追加します。 [#16315](https://github.com/pingcap/tidb/pull/16315) - `GROUP_CONCAT`関数の`ORDER BY`句をサポートする [#16988](https://github.com/pingcap/tidb/pull/16988) - `CMSketch`統計のメモリ割り当てメカニズムを最適化して、ガベージコレクション（GC）がパフォーマンスに与える影響を軽減する[#17543](https://github.com/pingcap/tidb/pull/17543) diff --git a/releases/release-3.0.5.md b/releases/release-3.0.5.md index 843308ee9ba34..eac8d83cf5dea 100644 --- a/releases/release-3.0.5.md +++ b/releases/release-3.0.5.md @@ -45,9 +45,9 @@ TiDB Ansible バージョン: 3.0.5 - `Create Table`操作で Set 列 Int 型のデフォルト値が正しく設定されない問題を修正しました。 [#12267](https://github.com/pingcap/tidb/pull/12267) - `Create Table`文で一意インデックスを作成するときに複数の`unique`をサポートする [#12463](https://github.com/pingcap/tidb/pull/12463) - `Alter Table` を使用してビット型の列を追加するときに、既存の行にこの列のデフォルト値を設定するとエラーが発生する可能性がある問題を修正しました。 [#12489](https://github.com/pingcap/tidb/pull/12489) - - 範囲パーティションテーブルで日付または日時型の列をパーティションキーとして使用している場合にパーティションを追加できない問題を修正[#12815](https://github.com/pingcap/tidb/pull/12815) - - 日付または日時型の列をパーティションキーとして持つ範囲パーティションテーブルの場合、テーブルの作成時またはパーティションの追加時に、パーティションタイプとパーティションキー タイプの一貫性をチェックする機能をサポート[#12792](https://github.com/pingcap/tidb/pull/12792) - - 範囲パーティションテーブルを作成するときに、一意キーの列セットがパーティション化された列セット以上である必要があるというチェックを追加します[#12718](https://github.com/pingcap/tidb/pull/12718) + - レンジパーティションテーブルで日付または日時型の列をパーティションキーとして使用している場合にパーティションを追加できない問題を修正[#12815](https://github.com/pingcap/tidb/pull/12815) + - 日付または日時型の列をパーティションキーとして持つレンジパーティションテーブルの場合、テーブルの作成時またはパーティションの追加時に、パーティションタイプとパーティションキー タイプの一貫性をチェックする機能をサポート[#12792](https://github.com/pingcap/tidb/pull/12792) + - レンジパーティションテーブルを作成するときに、一意キーの列セットがパーティション化された列セット以上である必要があるというチェックを追加します[#12718](https://github.com/pingcap/tidb/pull/12718) - モニター - コミットおよびロールバック操作の監視メトリックを`Transaction OPS`ダッシュボードに追加します。 [#12505](https://github.com/pingcap/tidb/pull/12505) - `Add Index`操作の進行状況の監視メトリックを追加します [#12390](https://github.com/pingcap/tidb/pull/12390) diff --git a/releases/release-3.0.8.md b/releases/release-3.0.8.md index 65f3001ffb5a7..e9e4b08c50f5a 100644 --- a/releases/release-3.0.8.md +++ b/releases/release-3.0.8.md @@ -25,7 +25,7 @@ TiDB Ansible バージョン: 3.0.8 - `HashAgg` Executor の同時実行値が正しく初期化されていないために集計操作の効率が低下することがある問題を修正しました[#13811](https://github.com/pingcap/tidb/pull/13811) - `group by item`節が括弧内にある場合に実行時にエラーが報告される問題を修正[#13658](https://github.com/pingcap/tidb/pull/13658) - TiDBが`group by item` を誤って計算するため、 `OUTER JOIN`の実行でエラーが報告される可能性がある問題を修正しました。 [#14014](https://github.com/pingcap/tidb/pull/14014) - - 範囲を超えるデータが範囲パーティションテーブルに書き込まれたときにエラーメッセージが不正確になる問題を修正[#14107](https://github.com/pingcap/tidb/pull/14107) + - 範囲を超えるデータがレンジパーティションテーブルに書き込まれたときにエラーメッセージが不正確になる問題を修正[#14107](https://github.com/pingcap/tidb/pull/14107) - MySQL 8では`PadCharToFullLength`すぐに破棄されることを考慮して、特殊なケースで予期しないクエリ結果を回避するために[PR #10124](https://github.com/pingcap/tidb/pull/10124)元に戻し、 `PadCharToFullLength`効果をキャンセルします[#14157](https://github.com/pingcap/tidb/pull/14157) - `ExplainExec` の保証されていない`close()`呼び出しによって発生する`EXPLAIN ANALYZE`文の実行時のゴルーチン リークの問題を修正しました。 [#14226](https://github.com/pingcap/tidb/pull/14226) - DDL diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index 774e9f3708423..00fe3ca175a85 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -39,7 +39,7 @@ TiDB バージョン: 4.0.0 - `Distinct`関数を使用するときに`collations`の値をチェックする機能をサポート [#17240](https://github.com/pingcap/tidb/pull/17240) - ハッシュパーティションプルーニング中の`is null`フィルタ条件をサポート [#17310](https://github.com/pingcap/tidb/pull/17310) - パーティションテーブルで`admin check index` 、 `admin cleanup index` 、 `admin recover index`をサポート [#17392](https://github.com/pingcap/tidb/pull/17392) [#17405](https://github.com/pingcap/tidb/pull/17405) [#17317](https://github.com/pingcap/tidb/pull/17317) - - `in`式に対する範囲パーティションプルーニングをサポート [#17320](https://github.com/pingcap/tidb/pull/17320) + - `in`式に対するレンジパーティションプルーニングをサポート [#17320](https://github.com/pingcap/tidb/pull/17320) - TiFlash - Learnerがデータを読み取る際に、 `Lock CF`の`min commit ts`から`TSO`の条件を満たすデータをフィルタリングすることをサポートします。 diff --git a/releases/release-4.0.12.md b/releases/release-4.0.12.md index c65349e4c59d8..70bb1e6fdbac1 100644 --- a/releases/release-4.0.12.md +++ b/releases/release-4.0.12.md @@ -86,7 +86,7 @@ TiDB バージョン: 4.0.12 - IndexMerge プランでテーブルフィルターが間違っている可能性がある問題を修正しました [#23165](https://github.com/pingcap/tidb/pull/23165) - `NULL`定数の戻り値の型で予期しない`NotNullFlag`が発生する問題を修正 [#23135](https://github.com/pingcap/tidb/pull/23135) - テキストタイプで照合順序が処理されない可能性があるバグを修正 [#23092](https://github.com/pingcap/tidb/pull/23092) - - 範囲パーティションが`IN`式を誤って処理する可能性がある問題を修正しました [#23074](https://github.com/pingcap/tidb/pull/23074) + - レンジパーティションが`IN`式を誤って処理する可能性がある問題を修正しました [#23074](https://github.com/pingcap/tidb/pull/23074) - TiKVストアをtombstoneとしてマークした後、同じIPアドレスとポートで異なるStoreIDを持つ新しいTiKVストアを開始すると、 `StoreNotMatch`エラーが返され続ける問題を修正しました。 [#23071](https://github.com/pingcap/tidb/pull/23071) - `INT`型は`NULL`で`YEAR` を比較すると調整しない [#22844](https://github.com/pingcap/tidb/pull/22844) - `auto_random`列列のテーブルにデータをロードする際に接続が失われる問題を修正しました [#22736](https://github.com/pingcap/tidb/pull/22736) diff --git a/releases/release-4.0.2.md b/releases/release-4.0.2.md index 6053b7d32beaa..cbbee7b5a8693 100644 --- a/releases/release-4.0.2.md +++ b/releases/release-4.0.2.md @@ -132,7 +132,7 @@ TiDB バージョン: 4.0.2 - `STR_TO_DATE`関数の`%h`の非互換な動作を修正 [#17498](https://github.com/pingcap/tidb/pull/17498) - `tidb_replica_read` `follower`に設定され、リーダーとフォロワー/ラーナー間にネットワークパーティションがある場合にフォロワー/ラーナーが再試行を続ける問題を修正しました。 [#17443](https://github.com/pingcap/tidb/pull/17443) - TiDBがPDフォロワーにpingを送信しすぎる場合がある問題を修正[#17947](https://github.com/pingcap/tidb/pull/17947) - - TiDB v4.0 で古いバージョンの範囲パーティションテーブルをロードできない問題を修正しました [#17983](https://github.com/pingcap/tidb/pull/17983) + - TiDB v4.0 で古いバージョンのレンジパーティションテーブルをロードできない問題を修正しました [#17983](https://github.com/pingcap/tidb/pull/17983) - 各リージョンに異なる`Backoffer`を割り当てることで、複数のリージョンリクエストが同時に失敗した場合の SQL文のタイムアウト問題を修正しました[#17585](https://github.com/pingcap/tidb/pull/17585) - `DateTime`区切り文字を解析する際の MySQL 非互換の動作を修正 [#17501](https://github.com/pingcap/tidb/pull/17501) - TiKVリクエストがTiFlashサーバーに時々送信される問題を修正 [#18105](https://github.com/pingcap/tidb/pull/18105) diff --git a/releases/release-4.0.5.md b/releases/release-4.0.5.md index c541472b16fb0..f89d808e291f2 100644 --- a/releases/release-4.0.5.md +++ b/releases/release-4.0.5.md @@ -111,7 +111,7 @@ TiDB バージョン: 4.0.5 - SQL文の`unknown column error` `select a from t having t.a` のように修正する [#18434](https://github.com/pingcap/tidb/pull/18434) - パーティションキーが整数型の場合、64 ビットの符号なし型をハッシュパーティションテーブルに書き込むとオーバーフローが発生し、予期しない負の数になるというpanic問題を修正しました。 [#18186](https://github.com/pingcap/tidb/pull/18186) - `char`関数の誤った動作を修正 [#18122](https://github.com/pingcap/tidb/pull/18122) - - `ADMIN REPAIR TABLE`文が範囲パーティション式内の整数を解析できない問題を修正しました [#17988](https://github.com/pingcap/tidb/pull/17988) + - `ADMIN REPAIR TABLE`文がレンジパーティション式内の整数を解析できない問題を修正しました [#17988](https://github.com/pingcap/tidb/pull/17988) - `SET CHARSET`文の誤った動作を修正する [#17289](https://github.com/pingcap/tidb/pull/17289) - 間違った照合順序設定によって関数`collation`の間違った結果が発生するバグを修正しました[#17231](https://github.com/pingcap/tidb/pull/17231) - `STR_TO_DATE`のフォーマットトークン '%r'、 '%h' の処理が MySQL と矛盾している問題を修正しました。 [#18727](https://github.com/pingcap/tidb/pull/18727) diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index 8cd09b1099f72..1c3779aca761c 100644 --- a/releases/release-5.0.0.md +++ b/releases/release-5.0.0.md @@ -84,7 +84,7 @@ TiDB バージョン: 5.0.0 ### SQL {#sql} -#### List パーティショニング（**Experimental**） {#list-partitioning-experimental} +#### リストパーティショニング（**Experimental**） {#list-partitioning-experimental} [ユーザー向けドキュメント](/partitioned-table.md#list-partitioning) @@ -94,13 +94,13 @@ TiDB バージョン: 5.0.0 リストパーティショニングを有効にするには、セッション変数[`tidb_enable_list_partition`](/system-variables.md#tidb_enable_list_partition-new-in-v50) `ON`に設定します。 -#### List COLUMNS パーティショニング（**Experimental**） {#list-columns-partitioning-experimental} +#### リストCOLUMNSパーティショニング（**Experimental**） {#list-columns-partitioning-experimental} [ユーザー向けドキュメント](/partitioned-table.md#list-columns-partitioning) -List COLUMNS パーティショニングは、リストパーティショニングの一種です。複数の列をパーティションキーとして使用できます。整数データ型の他に、文字列、 `DATE` 、および`DATETIME`データ型の列もパーティション列として使用できます。 +リストCOLUMNSパーティショニングは、リストパーティショニングの一種です。複数の列をパーティションキーとして使用できます。整数データ型の他に、文字列、 `DATE` 、および`DATETIME`データ型の列もパーティション列として使用できます。 -List COLUMNS パーティショニングを有効にするには、セッション変数[`tidb_enable_list_partition`](/system-variables.md#tidb_enable_list_partition-new-in-v50) `ON`に設定します。 +リストCOLUMNSパーティショニングを有効にするには、セッション変数[`tidb_enable_list_partition`](/system-variables.md#tidb_enable_list_partition-new-in-v50) `ON`に設定します。 #### 不可視インデックス {#invisible-indexes} diff --git a/releases/release-5.1.4.md b/releases/release-5.1.4.md index efe98658a8d06..65918b8519fd9 100644 --- a/releases/release-5.1.4.md +++ b/releases/release-5.1.4.md @@ -26,7 +26,7 @@ TiDB バージョン: 5.1.4 - TiDB - - 範囲パーティションテーブルの組み込み式`IN`のパーティションプルーニングをサポート [#26739](https://github.com/pingcap/tidb/issues/26739) + - レンジパーティションテーブルの組み込み式`IN`のパーティションプルーニングをサポート [#26739](https://github.com/pingcap/tidb/issues/26739) - `IndexJoin`実行時のメモリ使用量の追跡精度を向上[#28650](https://github.com/pingcap/tidb/issues/28650) - TiKV diff --git a/releases/release-5.1.5.md b/releases/release-5.1.5.md index 2ba782d326884..4f2ac871ed9f5 100644 --- a/releases/release-5.1.5.md +++ b/releases/release-5.1.5.md @@ -47,7 +47,7 @@ TiDBバージョン：5.1.5 - `tidb_opt_agg_push_down`と`tidb_enforce_mpp`が有効になっている場合に発生するプランナーの誤った動作を修正します [#34465](https://github.com/pingcap/tidb/issues/34465) - TiDBが`SHOW COLUMNS`ステートメントを実行する際にコプロセッサリクエストを送信する可能性があるバグを修正しました [#36496](https://github.com/pingcap/tidb/issues/36496) - `lock tables`フラグが有効になっていない場合に、 `unlock tables`と`enable-table-lock`に対する警告を追加する [#28967](https://github.com/pingcap/tidb/issues/28967) - - 範囲パーティションで複数の`MAXVALUE`パーティションが許可される問題を修正 [#36329](https://github.com/pingcap/tidb/issues/36329) + - レンジパーティションで複数の`MAXVALUE`パーティションが許可される問題を修正 [#36329](https://github.com/pingcap/tidb/issues/36329) - TiKV diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index 4ee42b5667d44..44111b4451e58 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -322,7 +322,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - `FLASHBACK`または`RECOVER`ステートメントを使用してテーブルを復元した後、テーブルの配置ルール設定を自動的にクリアします[#31668](https://github.com/pingcap/tidb/issues/31668) - パフォーマンス概要ダッシュボードを追加して、一般的なクリティカルパスのコアパフォーマンスメトリックを表示し、TiDB でのメトリック分析を容易にします[#31676](https://github.com/pingcap/tidb/issues/31676) - `LOAD DATA LOCAL INFILE`ステートメントで`REPLACE`キーワードの使用をサポート [#24515](https://github.com/pingcap/tidb/issues/24515) - - 範囲パーティションテーブルの組み込み式`IN`のパーティションプルーニングをサポート [#26739](https://github.com/pingcap/tidb/issues/26739) + - レンジパーティションテーブルの組み込み式`IN`のパーティションプルーニングをサポート [#26739](https://github.com/pingcap/tidb/issues/26739) - MPP 集計クエリで冗長な Exchange 操作を排除することでクエリ効率を向上[#31762](https://github.com/pingcap/tidb/issues/31762) - `TRUNCATE PARTITION`と`DROP PARTITION`ステートメントで重複したパーティション名を許可することでMySQLとの互換性を向上させます[#31681](https://github.com/pingcap/tidb/issues/31681) - `ADMIN SHOW DDL JOBS`文の結果に`CREATE_TIME`情報を表示することをサポートします [#23494](https://github.com/pingcap/tidb/issues/23494) diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index e7c5bd7ba75ac..5b673c18f81a8 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 6.1.0 6.1.0 の主な新機能または改善点は次のとおりです。 -- List パーティショニングとリスト COLUMNS パーティショニングが GA になり、 MySQL 5.7と互換性があります +- リストパーティショニングとリストCOLUMNSパーティショニングが GA になり、 MySQL 5.7と互換性があります - TiFlashパーティションテーブル（動的プルーニング）が GA になりました - ユーザーレベルのロック管理をサポートし、MySQLと互換性があります - 非トランザクションDML文をサポート（ `DELETE`のみサポート） @@ -27,9 +27,9 @@ TiDB バージョン: 6.1.0 ### SQL {#sql} -- List パーティショニングとリストCOLUMNSパーティショニングがGAになりました。どちらもMySQL 5.7と互換性があります。 +- リストパーティショニングとリストCOLUMNSパーティショニングがGAになりました。どちらもMySQL 5.7と互換性があります。 - ユーザー[List COLUMNS partitioning](/partitioned-table.md#list-columns-partitioning) : [List パーティショニング](/partitioned-table.md#list-partitioning) + ユーザードキュメント: [リストパーティショニング](/partitioned-table.md#list-partitioning)、[リストCOLUMNSパーティショニング](/partitioned-table.md#list-columns-partitioning) - TiFlash は、コンパクト コマンドの開始をサポートしています。(実験的) diff --git a/releases/release-6.1.6.md b/releases/release-6.1.6.md index ff8703a7e2616..79074bcd08a12 100644 --- a/releases/release-6.1.6.md +++ b/releases/release-6.1.6.md @@ -40,7 +40,7 @@ TiDB バージョン: 6.1.6 - IndexMerge プランが SET 型の列に誤った範囲を生成する可能性がある問題を修正しました [#41273](https://github.com/pingcap/tidb/issues/41273) [#41293](https://github.com/pingcap/tidb/issues/41293) @[time-and-fate](https://github.com/time-and-fate) - 符号なしの`TINYINT` / `SMALLINT` / `INT`値を`0`より小さい`DECIMAL` / `FLOAT` / `DOUBLE`値と比較するときに誤った結果になる可能性がある問題を修正しました。 [#41736](https://github.com/pingcap/tidb/issues/41736) @[LittleFall](https://github.com/LittleFall) - `INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY`テーブルへのクエリ実行時に TiDBサーバーのメモリが発生する問題を修正しました。この問題は、Grafana ダッシュボードでスロークエリを確認した場合に発生する可能性があります。 [#33893](https://github.com/pingcap/tidb/issues/33893) @[crazycs520](https://github.com/crazycs520) - - 範囲パーティションで複数の`MAXVALUE`パーティションが許可される問題を修正しました [#36329](https://github.com/pingcap/tidb/issues/36329) @[u5surf](https://github.com/u5surf) + - レンジパーティションで複数の`MAXVALUE`パーティションが許可される問題を修正しました [#36329](https://github.com/pingcap/tidb/issues/36329) @[u5surf](https://github.com/u5surf) - プランキャッシュがシャッフル演算子をキャッシュし、誤った結果を返す可能性がある問題を修正[#38335](https://github.com/pingcap/tidb/issues/38335) @[qw4990](https://github.com/qw4990) - タイムゾーンでのデータ競合によりデータインデックスの不整合が発生する可能性がある問題を修正[#40710](https://github.com/pingcap/tidb/issues/40710) @[wjhuang2016](https://github.com/wjhuang2016) - `indexMerge`で goroutine リークが発生する可能性がある問題を修正しました [#41545](https://github.com/pingcap/tidb/issues/41545) [#41605](https://github.com/pingcap/tidb/issues/41605) @[guo-shaoge](https://github.com/guo-shaoge) @[guo-shaoge](https://github.com/guo-shaoge) diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 2dee3801c6856..b7ea12523a6e0 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -23,8 +23,8 @@ TiDBバージョン: 6.3.0-DMR - JSONデータ型と関数が一般提供（GA）されます。 - TiDBは、NULL値を考慮したアンチジョインをサポートしています。 - TiDBは、より詳細な粒度で実行時間メトリクスを提供します。 -- 範囲パーティションの定義を簡素化するために、新しい構文糖衣が追加されました。 -- 範囲COLUMNSパーティショニングは、複数の列を定義することをサポートしています。 +- レンジパーティションの定義を簡素化するために、新しい構文糖衣が追加されました。 +- レンジCOLUMNSパーティショニングは、複数の列を定義することをサポートしています。 - インデックス追加時のパフォーマンスが3倍に向上しました。 - リソースを大量に消費するクエリが、軽量クエリの応答時間に与える影響を50%以上削減します。 @@ -32,13 +32,13 @@ TiDBバージョン: 6.3.0-DMR ### SQL {#sql} -- 範囲パーティション定義を簡素化するための新しい構文糖衣（範囲INTERVALパーティショニング）を追加（実験的） [#35683](https://github.com/pingcap/tidb/issues/35683) @[mjonss](https://github.com/mjonss) +- レンジパーティション定義を簡素化するための新しい構文糖衣（レンジ INTERVAL パーティショニング）を追加（実験的） [#35683](https://github.com/pingcap/tidb/issues/35683) @[mjonss](https://github.com/mjonss) - TiDBは、範囲パーティションを定義する新しい方法として、 [区間分割](/partitioned-table.md#range-interval-partitioning)を提供します。すべてのパーティションを列挙する必要がないため、範囲パーティショニングのDDL文の長さが大幅に短縮されます。構文は、従来の範囲パーティショニングと同じです。 + TiDBは、レンジパーティションを定義する新しい方法として、 [区間分割](/partitioned-table.md#range-interval-partitioning)を提供します。すべてのパーティションを列挙する必要がないため、レンジパーティショニングのDDL文の長さが大幅に短縮されます。構文は、従来のレンジパーティショニングと同じです。 -- 範囲COLUMNSパーティショニングは、複数の列の定義をサポートします [#36636](https://github.com/pingcap/tidb/issues/36636) @[mjonss](https://github.com/mjonss) +- レンジCOLUMNSパーティショニングは、複数の列の定義をサポートします [#36636](https://github.com/pingcap/tidb/issues/36636) @[mjonss](https://github.com/mjonss) - TiDB は[範囲列によるパーティション分割（列リスト）](/partitioned-table.md#range-columns-partitioning)をサポートしています。 `column_list`は単一列に制限されなくなりました。基本的な機能はMySQLと同じです。 + TiDB は[レンジCOLUMNSによるパーティション分割（列リスト）](/partitioned-table.md#range-columns-partitioning)をサポートしています。 `column_list`は単一列に制限されなくなりました。基本的な機能はMySQLと同じです。 - [パーティション交換](/partitioned-table.md#partition-management)が GA になりました [#35996](https://github.com/pingcap/tidb/issues/35996) @[ymkzpx](https://github.com/ymkzpx) @@ -232,7 +232,7 @@ TiDBバージョン: 6.3.0-DMR | [tidb_max_paging_size](/system-variables.md#tidb_max_paging_size-new-in-v630) | 新しく追加された | この変数は、コプロセッサのページングリクエスト処理中に最小行数を設定するために使用されます。 | | [`tidb_opt_force_inline_cte`](/system-variables.md#tidb_opt_force_inline_cte-new-in-v630) | 新しく追加された | セッション全体の共通テーブル式 (CTE) をインライン化するかどうかを制御します。デフォルト値は`OFF`で、これはデフォルトでは CTE のインライン化が強制されないことを意味します。 | | [`tidb_opt_three_stage_distinct_agg`](/system-variables.md#tidb_opt_three_stage_distinct_agg-new-in-v630) | 新しく追加された | `COUNT(DISTINCT)`集計を MPP モードで 3 段階集計に書き換えるかどうかを指定します。デフォルト値は`ON`です。 | -| [`tidb_partition_prune_mode`](/system-variables.md#tidb_partition_prune_mode-new-in-v51) | 変更 | 動的剪定を有効にするかどうかを指定します。v6.3.0 以降、デフォルト値は`dynamic`に変更されます。 | +| [`tidb_partition_prune_mode`](/system-variables.md#tidb_partition_prune_mode-new-in-v51) | 変更 | 動的プルーニングを有効にするかどうかを指定します。v6.3.0 以降、デフォルト値は`dynamic`に変更されます。 | | [`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600) | 変更 | タイムスタンプの取得を最適化するために使用され、read-committed分離レベルのシナリオ（読み取りと書き込みの競合がまれなシナリオ）に適しています。この機能は特定のサービスワークロード向けに設計されており、他のシナリオではパフォーマンスが低下する可能性があります。そのため、v6.3.0以降、この変数の適用範囲が`GLOBAL \| SESSION`から`INSTANCE`に変更されました。つまり、特定のTiDBインスタンスに対してこの機能を有効にできます。 | | [`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630) | 新しく追加された | タイムスタンプの取得を最適化するために使用され、悲観的トランザクションのRC分離レベルにおいてポイント書き込み競合が少ないシナリオに適しています。この変数を有効にすると、ポイント書き込みステートメントの実行中にグローバルタイムスタンプを取得する際に発生するレイテンシーとオーバーヘッドを回避できます。 | | [`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630) | 新しく追加された | FastScanを有効にするかどうかを制御します。FastScan[ファストスキャン](/tiflash/use-fastscan.md)が有効になっている場合（ `ON`に設定）、 TiFlashはより効率的なクエリパフォーマンスを提供しますが、クエリ結果の正確性やデータの一貫性は保証されません。 | diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 269b85ab161cf..029f4c4186e05 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -169,7 +169,7 @@ TiDBバージョン: 6.4.0-DMR - 線形ハッシュパーティショニング構文との互換性を確保する [#38450](https://github.com/pingcap/tidb/issues/38450) @[mjonss](https://github.com/mjonss) - 以前のバージョンでは、TiDB はハッシュ、レンジ、List パーティショニングをサポートしていました。 v6.4.0 以降、TiDB は[MySQL 線形ハッシュパーティショニング](https://dev.mysql.com/doc/refman/5.7/en/partitioning-linear-hash.html)の構文とも互換性があります。 + 以前のバージョンでは、TiDB はハッシュ、レンジ、リストパーティショニングをサポートしていました。 v6.4.0 以降、TiDB は[MySQL 線形ハッシュパーティショニング](https://dev.mysql.com/doc/refman/5.7/en/partitioning-linear-hash.html)の構文とも互換性があります。 TiDBでは、MySQLのリニアハッシュパーティションの既存のDDL文を直接実行でき、TiDBは対応するハッシュパーティションテーブルを作成します（TiDB内部にはリニアハッシュパーティションは存在しません）。また、MySQLのリニアハッシュパーティションの既存のDML文を直接実行することもでき、TiDBは対応するTiDBハッシュパーティションのクエリ結果を正常に返します。この機能により、TiDBの構文とMySQLのリニアハッシュパーティションとの互換性が確保され、MySQLベースのアプリケーションからTiDBへのスムーズな移行が可能になります。 diff --git a/releases/release-6.5.2.md b/releases/release-6.5.2.md index 636f2e15ff1ef..ce59c3d391436 100644 --- a/releases/release-6.5.2.md +++ b/releases/release-6.5.2.md @@ -26,7 +26,7 @@ TiDB バージョン: 6.5.2 - プリペアドプランキャッシュで`BatchPointGet`実行計画のキャッシュをサポート [#42125](https://github.com/pingcap/tidb/issues/42125) @[qw4990](https://github.com/qw4990) - インデックス結合より多くの SQL 形式をサポート [#40505](https://github.com/pingcap/tidb/issues/40505) @[Yisaer](https://github.com/Yisaer) - 一部のインデックスマージリーダーのログレベルを`"info"`から`"debug"` に変更します [#41949](https://github.com/pingcap/tidb/issues/41949) @[yibin87](https://github.com/yibin87) - - 範囲パーティションテーブルに Limit を設定した`distsql_concurrency`設定を最適化して、クエリのレイテンシーを削減します。 [#41480](https://github.com/pingcap/tidb/issues/41480) @[you06](https://github.com/you06) + - レンジパーティションテーブルに Limit を設定した`distsql_concurrency`設定を最適化して、クエリのレイテンシーを削減します。 [#41480](https://github.com/pingcap/tidb/issues/41480) @[you06](https://github.com/you06) - TiFlash diff --git a/releases/release-6.5.8.md b/releases/release-6.5.8.md index c2b48f6adbe3d..d500c65ebc4dd 100644 --- a/releases/release-6.5.8.md +++ b/releases/release-6.5.8.md @@ -39,7 +39,7 @@ TiDB バージョン: 6.5.8 - ヒストグラムの境界に`NULL` が含まれている場合、ヒストグラム統計が読み取り可能な文字列に解析されない可能性がある問題を修正しました。 [#49823](https://github.com/pingcap/tidb/issues/49823) @[AilinKid](https://github.com/AilinKid) - `REPLACE INTO`文でヒントが使用できない問題を修正 [#34325](https://github.com/pingcap/tidb/issues/34325) @[YangKeao](https://github.com/YangKeao) - `STREAM_AGG()` CI を誤って処理したためにクエリ結果が正しくない問題を修正しました [#49902](https://github.com/pingcap/tidb/issues/49902) @[wshwsh12](https://github.com/wshwsh12) - - 誤ったパーティションプルーニングが原因で、範囲パーティションテーブルのクエリ結果が間違っている場合がある問題を修正しました。 [#50082](https://github.com/pingcap/tidb/issues/50082) @[Defined2014](https://github.com/Defined2014) + - 誤ったパーティションプルーニングが原因で、レンジパーティションテーブルのクエリ結果が間違っている場合がある問題を修正しました。 [#50082](https://github.com/pingcap/tidb/issues/50082) @[Defined2014](https://github.com/Defined2014) - `AUTO_ID_CACHE=1` のAUTO_INCREMENT列を使用すると同時競合によりAUTO_INCREMENT ID 割り当てでエラーが報告される問題を修正しました。 [#50519](https://github.com/pingcap/tidb/issues/50519) @[tiancaiamao](https://github.com/tiancaiamao) - 多数のテーブルまたはパーティションを処理するときに TiDB ノードが OOM エラーに遭遇する可能性がある問題を軽減します。 [#50077](https://github.com/pingcap/tidb/issues/50077) @[zimulala](https://github.com/zimulala) - DDL所有者がネットワークから分離されている後に`ADD INDEX`を実行すると、TiDB分散実行フレームワーク（DXF）でデータが不整合になる問題を修正しました [#49773](https://github.com/pingcap/tidb/issues/49773) @[tangenta](https://github.com/tangenta) diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index e5e70c2da63d5..1f804d2417415 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -174,7 +174,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone 詳細については、[ドキュメント](/partitioned-table.md#reorganize-partitions)を参照してください。 -- キー分割をサポート [#41364](https://github.com/pingcap/tidb/issues/41364) @[TonsnakeLin](https://github.com/TonsnakeLin) +- キーパーティショニングをサポート [#41364](https://github.com/pingcap/tidb/issues/41364) @[TonsnakeLin](https://github.com/TonsnakeLin) TiDBはキーパーティショニングをサポートするようになりました。キーパーティショニングとハッシュパーティショニングはどちらも、データを一定数のパーティションに均等に分散できます。違いは、ハッシュパーティショニングは指定された整数式または整数列に基づいてのみデータを分散できるのに対し、キーパーティショニングは列リストに基づいてデータを分散できる点です。また、キーパーティショニングのパーティション列は整数型に限定されません。 diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index b6554eb5b3322..56f7c4dff4c71 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -160,9 +160,9 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 詳細については[ドキュメント](/partitioned-table.md#manage-hash-and-key-partitions)を参照してください。 -- 範囲INTERVALパーティションの構文が一般公開（GA） になります [#35683](https://github.com/pingcap/tidb/issues/35683) @[mjonss](https://github.com/mjonss) +- レンジ INTERVAL パーティショニングの構文が一般公開（GA） になります [#35683](https://github.com/pingcap/tidb/issues/35683) @[mjonss](https://github.com/mjonss) - バージョン6.3.0で導入されたRange INTERVALパーティショニングの構文がGAになりました。この構文を使用すると、すべてのパーティションを列挙することなく、任意の間隔でRangeパーティショニングを定義できるため、RangeパーティショニングのDDL文の長さが大幅に短縮されます。この構文は、従来のRangeパーティショニングの構文と同等です。 + バージョン6.3.0で導入されたレンジ INTERVAL パーティショニングの構文がGAになりました。この構文を使用すると、すべてのパーティションを列挙することなく、任意の間隔でレンジパーティショニングを定義できるため、レンジパーティショニングのDDL文の長さが大幅に短縮されます。この構文は、従来のレンジパーティショニングの構文と同等です。 詳細については[ドキュメント](/partitioned-table.md#range-interval-partitioning)を参照してください。 diff --git a/releases/release-7.1.1.md b/releases/release-7.1.1.md index 5e1d5a132853a..4b835c17ce354 100644 --- a/releases/release-7.1.1.md +++ b/releases/release-7.1.1.md @@ -70,7 +70,7 @@ TiDB バージョン: 7.1.1 - MySQLカーソルフェッチプロトコル使用時に、結果セットのメモリ消費量が`tidb_mem_quota_query`上限を超え、TiDBのメモリオーバーフローが発生する問題を修正しました。修正後、TiDBは結果セットを自動的にディスクに書き込み、メモリを解放します[#43233](https://github.com/pingcap/tidb/issues/43233) @[YangKeao](https://github.com/YangKeao) - 権限がなくてもユーザーが`INFORMATION_SCHEMA.TIFLASH_REPLICA`テーブルの情報を表示できる問題を修正 [#45320](https://github.com/pingcap/tidb/issues/45320) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - `ADMIN SHOW DDL JOBS`文によって返される`ROW_COUNT`不正確である問題を修正[#44044](https://github.com/pingcap/tidb/issues/44044) @[tangenta](https://github.com/tangenta) - - 範囲列パーティションテーブルをクエリするとエラーが発生する可能性がある問題を修正しました [#43459](https://github.com/pingcap/tidb/issues/43459) @[mjonss](https://github.com/mjonss) + - レンジCOLUMNSパーティションテーブルをクエリするとエラーが発生する可能性がある問題を修正しました [#43459](https://github.com/pingcap/tidb/issues/43459) @[mjonss](https://github.com/mjonss) - 一時停止中の DDL タスクの再開が失敗する問題を修正[#44217](https://github.com/pingcap/tidb/issues/44217) @[dhysum](https://github.com/dhysum) - メモリ内の悲観的ロックが`FLASHBACK`障害と[#44292](https://github.com/pingcap/tidb/issues/44292) [Jmポテト](https://github.com/JmPotato)の不整合を引き起こす問題を修正しました。 - 削除されたテーブルが`INFORMATION_SCHEMA` から引き続き読み取ることができる問題を修正しました [#43714](https://github.com/pingcap/tidb/issues/43714) @[tangenta](https://github.com/tangenta) diff --git a/releases/release-7.1.4.md b/releases/release-7.1.4.md index b654a99f72308..552f7becf6170 100644 --- a/releases/release-7.1.4.md +++ b/releases/release-7.1.4.md @@ -101,7 +101,7 @@ TiDBバージョン: 7.1.4 - ネットワークが不安定な場合にインデックスを追加するとインデックスデータの不整合が発生する可能性がある問題を修正[#49773](https://github.com/pingcap/tidb/issues/49773) @[tangenta](https://github.com/tangenta) - DDLジョブの実行順序を修正して、TiCDCが順序どおりに動作しないDDL を受信しないようにします。 [#49498](https://github.com/pingcap/tidb/issues/49498) @[tangenta](https://github.com/tangenta) - `tidb_server_memory_limit`変数が変更された後、 `tidb_gogc_tuner_threshold`システム変数がそれに応じて調整されない問題を修正しました [#48180](https://github.com/pingcap/tidb/issues/48180) @[hawkingrei](https://github.com/hawkingrei) - - 誤ったパーティションプルーニングが原因で、範囲パーティションテーブルのクエリ結果が間違っている場合がある問題を修正しました。 [#50082](https://github.com/pingcap/tidb/issues/50082) @[Defined2014](https://github.com/Defined2014) + - 誤ったパーティションプルーニングが原因で、レンジパーティションテーブルのクエリ結果が間違っている場合がある問題を修正しました。 [#50082](https://github.com/pingcap/tidb/issues/50082) @[Defined2014](https://github.com/Defined2014) - `CREATE TABLE`文に特定のパーティションまたは制約が含まれている場合に、テーブル名の変更などの DDL 操作が停止する問題を修正しました[#50972](https://github.com/pingcap/tidb/issues/50972) @[lcwangchao](https://github.com/lcwangchao) - 列のデフォルト値が削除されている場合に列のデフォルト値を取得するとエラーが返される問題を修正[#50043](https://github.com/pingcap/tidb/issues/50043) [#51324](https://github.com/pingcap/tidb/issues/51324) @[crazycs520](https://github.com/crazycs520) - Grafana の監視メトリック`tidb_statistics_auto_analyze_total`が整数として表示されない問題を修正しました [#51051](https://github.com/pingcap/tidb/issues/51051) @[hawkingrei](https://github.com/hawkingrei) diff --git a/releases/release-7.3.0.md b/releases/release-7.3.0.md index 57c05ed348957..edf055b98546b 100644 --- a/releases/release-7.3.0.md +++ b/releases/release-7.3.0.md @@ -67,11 +67,11 @@ TiDB バージョン: 7.3.0 ### SQL {#sql} -- リストとリスト列のパーティションテーブルはデフォルトのパーティションをサポートします [#20679](https://github.com/pingcap/tidb/issues/20679) @[mjonss](https://github.com/mjonss)@[bb7133](https://github.com/bb7133) +- リストとリストCOLUMNSのパーティションテーブルはデフォルトのパーティションをサポートします [#20679](https://github.com/pingcap/tidb/issues/20679) @[mjonss](https://github.com/mjonss)@[bb7133](https://github.com/bb7133) - バージョン 7.3.0 より前では、 `INSERT`文を使用してリストまたはリスト COLUMNSパーティションテーブルにデータを挿入する場合、データはテーブルの指定されたパーティション条件を満たす必要があります。挿入するデータがこれらの条件のいずれにも満たない場合、ステートメントの実行が失敗するか、条件を満たさないデータは無視されます。 + バージョン 7.3.0 より前では、 `INSERT`文を使用してリストまたはリストCOLUMNSパーティションテーブルにデータを挿入する場合、データはテーブルの指定されたパーティション条件を満たす必要があります。挿入するデータがこれらの条件のいずれにも満たない場合、ステートメントの実行が失敗するか、条件を満たさないデータは無視されます。 - バージョン7.3.0以降、ListおよびList COLUMNSパーティションテーブルはデフォルトパーティションをサポートします。デフォルトパーティションが作成された後、挿入するデータがパーティション条件を満たさない場合、そのデータはデフォルトパーティションに書き込まれます。この機能により、ListおよびList COLUMNS パーティショニングの使いやすさが向上し、 `INSERT`文の実行失敗や、パーティション条件を満たさないデータによるデータの無視を防ぐことができます。 + バージョン7.3.0以降、リストおよびリストCOLUMNSパーティションテーブルはデフォルトパーティションをサポートします。デフォルトパーティションが作成された後、挿入するデータがパーティション条件を満たさない場合、そのデータはデフォルトパーティションに書き込まれます。この機能により、リストおよびリストCOLUMNSパーティショニングの使いやすさが向上し、 `INSERT`文の実行失敗や、パーティション条件を満たさないデータによるデータの無視を防ぐことができます。 この機能は、MySQL構文に対するTiDBの拡張機能であることに注意してください。デフォルトのパーティションを持つパーティションテーブルの場合、テーブル内のデータをMySQLに直接レプリケートすることはできません。 diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index b83e605b3b21c..682ce88627669 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -216,7 +216,7 @@ TiDB バージョン: 8.4.0 | `log_bin` | 削除済み | バージョン8.4.0では、 [TiDB Binlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)が削除されました。この変数はTiDB Binlogが使用されているかどうかを示し、バージョン8.4.0以降は削除されます。 | | `sql_log_bin` | 削除済み | バージョン8.4.0では、 [TiDB Binlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)が削除されました。この変数は、変更内容をTiDB Binlogに書き込むかどうかを示すもので、バージョン8.4.0以降は削除されます。 | | [`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760) | 非推奨 | v8.4.0 では、この変数は非推奨です。その値はデフォルト値`ON`に固定されます。つまり、[グローバルインデックス](/global-indexes.md)はデフォルトで有効になっています。 `CREATE TABLE`または`ALTER TABLE`を実行してグローバルインデックスを作成する際に、対応する列にキーワード`GLOBAL`を追加するだけで済みます。 | -| [`tidb_enable_list_partition`](/system-variables.md#tidb_enable_list_partition-new-in-v50) | 非推奨 | バージョン8.4.0では、この変数は非推奨となります。その値はデフォルト値`ON`に固定され、[リスト分割](/partitioned-table.md#list-partitioning)がデフォルトで有効になります。 | +| [`tidb_enable_list_partition`](/system-variables.md#tidb_enable_list_partition-new-in-v50) | 非推奨 | バージョン8.4.0では、この変数は非推奨となります。その値はデフォルト値`ON`に固定され、[リストパーティショニング](/partitioned-table.md#list-partitioning)がデフォルトで有効になります。 | | [`tidb_enable_table_partition`](/system-variables.md#tidb_enable_table_partition) | 非推奨 | v8.4.0 では、この変数は非推奨になりました。その値はデフォルト値`ON`に固定されます。つまり、[テーブルパーティショニング](/partitioned-table.md)はデフォルトで有効になります。 | | [`tidb_analyze_partition_concurrency`](/system-variables.md#tidb_analyze_partition_concurrency) | 変更 | 値の範囲を`[1, 18446744073709551615]`から`[1, 128]`に変更します。 | | [`tidb_enable_inl_join_inner_multi_pattern`](/system-variables.md#tidb_enable_inl_join_inner_multi_pattern-new-in-v700) | 変更 | デフォルト値を`OFF`から`ON`に変更します。v8.4.0 以降、内部テーブルに`Selection` 、 `Aggregation` 、または`Projection`オペレーターがある場合、Index Join がデフォルトでサポートされます。 | @@ -295,7 +295,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - 今後のリリースでは [実行プランバインディングの自動進化](/sql-plan-management.md#baseline-evolution)が再設計される予定であり、関連する変数と動作が変更されます。 - バージョン8.0.0では、TiDBが並列ハッシュアグリゲーションアルゴリズムのディスクスピルをサポートするかどうかを制御するシステム変数[`tidb_enable_parallel_hashagg_spill`](/system-variables.md#tidb_enable_parallel_hashagg_spill-new-in-v800)が導入されました。今後のバージョンでは、 [`tidb_enable_parallel_hashagg_spill`](/system-variables.md#tidb_enable_parallel_hashagg_spill-new-in-v800)システム変数は非推奨となります。 - TiDB Lightning のパラメータ[`conflict.max-record-rows`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) 、今後のリリースで非推奨となり、その後削除されます。このパラメータは[`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)に置き換えられます。これは、競合するレコードの最大数が、単一のインポートタスクで許容できる競合レコードの最大数と一致することを意味します。 -- バージョン6.3.0以降、パーティションテーブルはデフォルトで [動的剪定モード](/partitioned-table.md#dynamic-pruning-mode)を使用します。静的剪定モードと比較して、動的剪定モードはIndexJoinやプランキャッシュなどの機能をサポートし、パフォーマンスが向上しています。そのため、静的剪定モードは非推奨となります。 +- バージョン6.3.0以降、パーティションテーブルはデフォルトで [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を使用します。静的プルーニングモードと比較して、動的プルーニングモードはIndexJoinやプランキャッシュなどの機能をサポートし、パフォーマンスが向上しています。そのため、静的プルーニングモードは非推奨となります。 ## 改善点 {#improvements} diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index 79f0a7ccf65cf..3d63c6faf75cc 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -167,7 +167,7 @@ TiDB をアップグレードする前に、オペレーティングシステム - バージョン8.0.0では、TiDBが並列ハッシュ集計アルゴリズムのディスクスピルをサポートするかどうかを制御するシステム変数[`tidb_enable_parallel_hashagg_spill`](/system-variables.md#tidb_enable_parallel_hashagg_spill-new-in-v800)が導入されました。このシステム変数は、今後のバージョンで非推奨となります。 - バージョン5.1では、TiDBはパーティションテーブルの動的プルーニングモードを有効にするかどうかを制御するシステム変数[`tidb_partition_prune_mode`](/system-variables.md#tidb_partition_prune_mode-new-in-v51)を導入しました。バージョン8.5.0以降では、この変数を`static`または`static-only`に設定すると警告が表示されます。今後のバージョンでは、このシステム変数は非推奨となります。 - TiDB Lightning のパラメータ[`conflict.max-record-rows`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) 、今後のリリースで非推奨となり、その後削除されます。このパラメータは[`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)に置き換えられます。これは、競合するレコードの最大数が、単一のインポートタスクで許容できる競合レコードの最大数と一致することを意味します。 -- バージョン6.3.0以降、パーティションテーブルはデフォルトで [動的剪定モード](/partitioned-table.md#dynamic-pruning-mode)を使用します。静的剪定モードと比較して、動的剪定モードはIndexJoinやプランキャッシュなどの機能をサポートし、パフォーマンスが向上しています。そのため、静的剪定モードは非推奨となります。 +- バージョン6.3.0以降、パーティションテーブルはデフォルトで [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を使用します。静的プルーニングモードと比較して、動的プルーニングモードはIndexJoinやプランキャッシュなどの機能をサポートし、パフォーマンスが向上しています。そのため、静的プルーニングモードは非推奨となります。 ## 改善点 {#improvements} diff --git a/releases/release-8.5.1.md b/releases/release-8.5.1.md index 8b27e9578b168..a0271c047cc7f 100644 --- a/releases/release-8.5.1.md +++ b/releases/release-8.5.1.md @@ -65,7 +65,7 @@ CentOS Linux 7はサポート終了（EOL）を迎えたため、今後のTiDB - `IndexMerge`を構築する際に一部の述語が失われる可能性がある問題を修正しました [#58476](https://github.com/pingcap/tidb/issues/58476) @[hawkingrei](https://github.com/hawkingrei) - 3000次元を超える列にベクトル検索インデックスを作成すると`KeyTooLong`エラーが発生する問題を修正 [#58836](https://github.com/pingcap/tidb/issues/58836) @[breezewish](https://github.com/breezewish) - `REORGANIZE PARTITION`操作が置換されたグローバルインデックスを正しくクリーンアップせず、非クラスター化テーブルの一意インデックスを処理する問題を修正しました [#56822](https://github.com/pingcap/tidb/issues/56822) @[mjonss](https://github.com/mjonss) - - パーティションテーブルの Range INTERVAL 構文糖衣が`MINUTE`間隔として使用できない問題を修正 [#57698](https://github.com/pingcap/tidb/issues/57698) @[mjonss](https://github.com/mjonss) + - パーティションテーブルのレンジ INTERVAL 構文糖衣が`MINUTE`間隔として使用できない問題を修正 [#57698](https://github.com/pingcap/tidb/issues/57698) @[mjonss](https://github.com/mjonss) - タイムゾーンを変更すると、スローログのクエリ時にクエリ結果が正しくなくなる問題を修正しました [#58452](https://github.com/pingcap/tidb/issues/58452) @[lcwangchao](https://github.com/lcwangchao) - スキャンタスクのTTLワーカーを縮小する際に、タスクキャンセルの失敗によってタスクがリークする可能性がある問題を修正しました [#57708](https://github.com/pingcap/tidb/issues/57708) @[YangKeao](https://github.com/YangKeao) - ハートビートが失われ、TTLテーブルが削除または無効化された後もTTLジョブが実行され続ける問題を修正 [#57702](https://github.com/pingcap/tidb/issues/57702) @[YangKeao](https://github.com/YangKeao) diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md index a9f978ccc4927..4ffa34c4da23b 100644 --- a/sql-statements/sql-statement-split-region.md +++ b/sql-statements/sql-statement-split-region.md @@ -307,7 +307,7 @@ region4 [("c", "") , maxIndexValue ) 分割するパーティションを指定できます。 -1. パーティションテーブルを作成します。たとえば、3つのパーティションに分割された範囲パーティションテーブルを作成するとします。例となるステートメントは次のとおりです。 +1. パーティションテーブルを作成します。たとえば、3つのパーティションに分割されたレンジパーティションテーブルを作成するとします。例となるステートメントは次のとおりです。 ```sql CREATE TABLE t ( a INT, b INT, INDEX idx(b)) PARTITION BY RANGE( a ) ( diff --git a/statistics.md b/statistics.md index 7226d4d8f5aab..0956742007fe9 100644 --- a/statistics.md +++ b/statistics.md @@ -204,7 +204,7 @@ TiDB が SQL文を実行する際、オプティマイザはほとんどの場 #### 動的プルーニングモードでパーティションテーブルの統計情報を収集する {#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode} -TiDB は、パーティション分割されたテーブルに、パーティション [動的剪定モード](/partitioned-table.md#dynamic-pruning-mode)(v6.3.0 以降はデフォルト) でアクセスする場合、テーブルレベルの統計情報、つまりパーティション分割されたテーブルのグローバル統計情報を収集します。現在、グローバル統計情報は、すべてのパーティションの統計情報を集計したものです。動的プルーニングモードでは、テーブルのいずれかのパーティションの統計情報が更新されると、そのテーブルのグローバル統計情報も更新される可能性があります。 +TiDB は、パーティション分割されたテーブルに、[動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)(v6.3.0 以降はデフォルト) でアクセスする場合、テーブルレベルの統計情報、つまりパーティション分割されたテーブルのグローバル統計情報を収集します。現在、グローバル統計情報は、すべてのパーティションの統計情報を集計したものです。動的プルーニングモードでは、テーブルのいずれかのパーティションの統計情報が更新されると、そのテーブルのグローバル統計情報も更新される可能性があります。 一部のパーティションの統計情報が空の場合、または一部のパーティションで一部の列の統計情報が欠落している場合、収集動作は[`tidb_skip_missing_partition_stats`](/system-variables.md#tidb_skip_missing_partition_stats-new-in-v730)変数によって制御されます。 diff --git a/system-variables.md b/system-variables.md index 18da1fd08ed6b..5195a94663106 100644 --- a/system-variables.md +++ b/system-variables.md @@ -2434,7 +2434,7 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1; - 型: Boolean - デフォルト値: `ON` - この変数は`LIST (COLUMNS) TABLE PARTITION`機能を有効にするかどうかを設定するために使用されます。 -- この変数はv8.4.0以降非推奨です。その値はデフォルト値`ON`に固定されます。つまり、 [List パーティショニング](/partitioned-table.md#list-partitioning)はデフォルトで有効になります。 +- この変数はv8.4.0以降非推奨です。その値はデフォルト値`ON`に固定されます。つまり、 [リストパーティショニング](/partitioned-table.md#list-partitioning)はデフォルトで有効になります。 ### tidb_enable_local_txn @@ -5966,7 +5966,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: Boolean - デフォルト値: `ON` -- パーティション [動的剪定モード](/partitioned-table.md#dynamic-pruning-mode)でパーティションテーブルにアクセスする場合、TiDB は各パーティションの統計情報を集約してグローバル統計情報を生成します。この変数は、パーティション統計情報が欠落している場合にグローバル統計情報を生成するかどうかを制御します。 +- [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)でパーティションテーブルにアクセスする場合、TiDB は各パーティションの統計情報を集約してグローバル統計情報を生成します。この変数は、パーティション統計情報が欠落している場合にグローバル統計情報を生成するかどうかを制御します。 - この変数が`ON`の場合、TiDB はグローバル統計を生成する際に不足しているパーティション統計をスキップするため、グローバル統計の生成には影響しません。 - この変数が`OFF`の場合、TiDB は欠落しているパーティション統計を検出すると、グローバル統計の生成を停止します。 diff --git a/tiflash-upgrade-guide.md b/tiflash-upgrade-guide.md index 47392e320a9de..10eff29e05b7b 100644 --- a/tiflash-upgrade-guide.md +++ b/tiflash-upgrade-guide.md @@ -69,7 +69,7 @@ TiFlash Proxyはv6.1.0（TiKV v6.0.0と連動）にアップグレードされ 対象のTiFlashノードを強制的にスケールインし、TiKVからデータを再度複製することができます。詳細な手順については、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 -### 動的剪定 {#dynamic-pruning} +### 動的プルーニング {#dynamic-pruning} [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を有効にせず、今後も使用しない場合は、このセクションをスキップできます。 @@ -81,7 +81,7 @@ TiFlash Proxyはv6.1.0（TiKV v6.0.0と連動）にアップグレードされ ## v5.x または v6.0 から v6.2 へ {#from-v5-x-or-v6-0-to-v6-2} -TiDB v6.2では、 TiFlashのデータストレージフォーマットがV3にアップグレードされ、ライトアンプリフィケーションの低減とTiFlashの安定性向上が図られています。v5.x、v6.0、またはv6.1からv6.2以降のバージョンにアップグレードする場合は、 [TiFlashプロキシ](#tiflash-proxy)と[動的剪定](#dynamic-pruning)の機能変更に加えて、PageStorageの機能変更にも注意する必要があります。 +TiDB v6.2では、 TiFlashのデータストレージフォーマットがV3にアップグレードされ、ライトアンプリフィケーションの低減とTiFlashの安定性向上が図られています。v5.x、v6.0、またはv6.1からv6.2以降のバージョンにアップグレードする場合は、 [TiFlashプロキシ](#tiflash-proxy)と[動的プルーニング](#dynamic-pruning)の機能変更に加えて、PageStorageの機能変更にも注意する必要があります。 ### ページストレージ {#pagestorage} diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index a4c926c797b46..02fe34485caab 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -115,7 +115,7 @@ TiFlash は、ブロードキャスト ハッシュ結合を使用するかど ## MPP モードでパーティションテーブルにアクセスする {#access-partitioned-tables-in-the-mpp-mode} -MPP モードでパーティションテーブルにアクセスするには、まず[動的剪定モード](https://docs.pingcap.com/tidb/stable/partitioned-table#dynamic-pruning-mode)を有効にする必要があります。 +MPP モードでパーティションテーブルにアクセスするには、まず[動的プルーニングモード](https://docs.pingcap.com/tidb/stable/partitioned-table#dynamic-pruning-mode)を有効にする必要があります。 例：