重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

データベーススキーマ

データベーススキーマは、データベース、テーブル、列、インデックス、およびその他のオブジェクト内のデータの構造と構成を定義します。

このドキュメントでは、データベース、テーブル、列、データ型、制約、インデックスなどのデータベーススキーマの主要な概念について説明します。また、中間データをシームレスに管理するための一時テーブル、効率的な近似最近傍 (ANN) 検索のためのベクターインデックス、読み取りパフォーマンスを向上させるキャッシュテーブルなどの高度な機能についても説明します。

データベース

TiDB のデータベースは、テーブルやインデックスなどのオブジェクトのコレクションです。

システムデータベース

システムデータベースは、システムテーブルを格納するために TiDB によって作成されるデフォルトのデータベースです。TiDB は次のシステムデータベースを提供します。

`test`データベース

TiDB にはtestという名前のデフォルトのデータベースが付属しています。ただし、 testデータベースを使用するのではなく、独自のデータベースを作成することをお勧めします。

テーブル

テーブルは、データベース内の関連するデータの集合です。

各テーブルは行と列で構成されています。行内の各値は特定の列に属します。各列では 1 つのデータ型のみが許可されます。列をさらに限定するには、制約追加できます。計算を高速化するには、生成された列追加できます。

システムテーブル

mysqlスキーマには、TiDB システムテーブルが含まれています。設計は MySQL のmysqlスキーマに似ており、 mysql.userなどのテーブルを直接編集できます。また、MySQL の拡張機能であるテーブルもいくつか含まれています。
情報スキーマは、システムメタデータを表示するための ANSI 標準の方法を提供します。TiDB は、MySQL 互換性のために含まれているテーブルに加えて、多数のカスタムINFORMATION_SCHEMAテーブルも提供します。多くのINFORMATION_SCHEMAテーブルには、対応するSHOWコマンドがありますINFORMATION_SCHEMAクエリする利点は、テーブル間の結合が可能であることです。
パフォーマンススキーマ。TiDB は、MySQL との互換性のためにパフォーマンススキーマテーブルを実装します。

キャッシュされたテーブル

TiDB は、頻繁にアクセスされるが、めったに更新されない小さなホットスポットテーブル向けにキャッシュされたテーブル機能を導入しています。この機能を使用すると、テーブル全体のデータが TiDBサーバーのメモリにロードされ、TiDB は TiKV にアクセスせずにメモリからテーブルデータを直接取得するため、読み取りパフォーマンスが向上します。

一時テーブル

一時テーブル機能は、アプリケーションの中間結果を一時的に保存するという問題を解決し、テーブルを頻繁に作成したり削除したりする手間を省きます。中間計算データは一時テーブルに保存できます。中間データが不要になると、TiDB は一時テーブルを自動的にクリーンアップしてリサイクルします。これにより、ユーザーアプリケーションが複雑になりすぎることがなくなり、テーブル管理のオーバーヘッドが削減され、パフォーマンスが向上します。

パーティションテーブル

TiDB では、パーティション分割使用すると、大きなテーブルをパーティションと呼ばれる 1 つ以上の管理しやすい部分に分割できます。各パーティションは独立しており、個別に管理できます。

コラム

列はテーブルに従属します。各テーブルには少なくとも 1 つの列があります。列は、各行の値を単一のデータ型の小さなセルに分割することで、テーブルに構造を提供します。

詳細については列を定義する参照してください。

生成された列

TiDB を使用すると、JSON データ型からデータを生成された列として抽出できます。

一般的な列とは異なり、生成された列の値は列定義内の式によって計算されます。生成された列を挿入または更新する場合、値を割り当てることはできず、 DEFAULTのみを使用できます。

生成列には、仮想生成列と保存列の 2 種類があります。仮想生成列はstorageを占有せず、読み取られるときに計算されます。保存列は、書き込まれる (挿入または更新される) ときに計算され、storageを占有します。仮想生成列と比較すると、保存列は読み取りパフォーマンスが優れていますが、より多くのディスク領域を占有します。

データ型

TiDB は、 SPATIAL型を除く MySQL のすべてのデータ型をサポートしています。これには、数値型、文字列型、日付と時刻の種類、およびJSON型のすべてが含まれます。

インデックス

インデックスは、テーブル内の選択された列のコピーです。テーブルの 1 つ以上の列を使用してインデックスを作成できます。インデックスを使用すると、TiDB はテーブル内のすべての行を毎回検索しなくてもデータをすばやく見つけることができるため、クエリのパフォーマンスが大幅に向上します。

一般的なインデックスには次の 2 つの種類があります。

主キー: 主キー列のインデックス。
セカンダリインデックス: 主キー以外の列のインデックス

ユニークなインデックス

TiDB の一意のインデックスは、1 つ以上の列に一意性を強制し、テーブル内の 2 つの行がインデックス列に同じ値を持たないようにします。この制約により、重複する値を防ぐことでデータの整合性を維持する方法が提供され、一意のインデックスは、電子メールアドレス、ユーザー名、製品コードなど、自然に一意である必要があるフィールドに最適です。

主キーインデックス

主キーインデックスは、テーブル内の 1 つ以上の列に対する一意のインデックスであり、各行の主識別子として機能します。TiDB では、すべてのテーブルに主キーが必要です。主キーは、ユーザーが明示的に定義することも、主キーが指定されていない場合は TiDB によって暗黙的に定義することもできます。

複合指数

複合インデックスは、テーブルの 2 つ以上の列に基づいて構築されるインデックスで、複数のフィールドでデータをフィルタリングまたは並べ替えるクエリに特に役立ちます。たとえば、person テーブルのlast_nameとfirst_nameに複合インデックスを作成すると、TiDB は両方の名前に基づいてレコードをすばやく見つけることができます。

目に見えないインデックス

非表示のインデックスは、データベース内に存在するものの、クエリオプティマイザーからは隠されており、クエリプランでは無視されます。TiDB では、非表示のインデックスはテストやデバッグに役立ち、インデックスを完全に削除せずにパフォーマンスへの影響を評価できます。

TiDB v8.0.0 以降では、 tidb_opt_use_invisible_indexesシステム変数を変更することで、オプティマイザーが非表示のインデックスを選択するようにすることができます。

クラスター化インデックス

クラスター化インデックスでは、クラスター化という用語は、連携して動作するデータベースサーバーのグループではなく、データの格納方法の構成を指します。一部のデータベース管理システムでは、クラスター化インデックスをインデックス構成テーブル (IOT) と呼びます。

この機能は、主キーを含むテーブルにデータを格納する方法を制御します。この機能により、TiDB は特定のクエリのパフォーマンスを向上できる方法でテーブルを整理できるようになります。

詳細についてはクラスター化インデックス参照してください。

セカンダリインデックス

セカンダリインデックスは、TiDB クラスター内の論理オブジェクトです。これは、クエリパフォーマンスを向上させるために TiDB が使用するデータの並べ替えタイプと見なすことができます。TiDB では、セカンダリインデックスの作成はオンライン操作であり、テーブルでのデータの読み取りおよび書き込み操作をブロックしません。各インデックスについて、TiDB はテーブル内の各行の参照を作成し、データではなく選択した列で参照を並べ替えます。

セカンダリインデックスの詳細については、セカンダリインデックス参照してください。

TiDB では、既存のテーブルにセカンダリインデックスを追加するまたは新しいテーブルを作成するときにセカンダリインデックスを作成するいずれかを選択できます。

ベクトルインデックス

次の TiDB デプロイメントオプションでは、TiDB はベクターデータ型とベクター検索インデックスをサポートします。

TiDB Cloudサーバーレス
TiDB Self-Managed v8.4.0 以降のバージョン

TiDB では、ベクターインデックスは、ベクターデータを含む列に対する効率的な近似最近傍 (ANN) 検索用に設計された特殊なインデックスです。ベクターインデックス、特に HNSW (Hierarchical Navigable Small World) アルゴリズムを使用すると、K 近傍 (KNN) 検索によって、ベクター空間内の最も近いデータポイントをすばやく識別できます。これにより、クエリのパフォーマンスが大幅に向上し、総当たり方式と比較して数ミリ秒で結果を得ることができます。

ベクターインデックスは、データのstorageと検索機能のためにTiFlashレプリカに依存します。ベクターインデックスを作成して使用する前に、クラスターでTiFlashノードが使用可能であることを確認してください。

制約

TiDB は MySQL とほぼ同じ制約をサポートします。

NOT NULL制約

NOT NULL制約により、列にNULL値を含めることはできません。

列がNOT NULL制約で定義されている場合、TiDB では、その列にNULL値を持つ行を挿入または更新しようとするとエラーが発生します。この動作は、MySQL のNOT NULL制約の実装と一致しています。

CHECK制約

CHECK制約は、テーブル内の列の値を、指定した条件を満たすように制限します。3 制約がテーブルに追加されるCHECK 、TiDB はテーブルへのデータの挿入または更新中に制約が満たされているかどうかを確認します。制約が満たされていない場合は、エラーが返されます。

主キー制約

MySQL と同様に、TiDB の主キー制約には一意制約が含まれています。つまり、主キー制約を作成することは、一意制約を持つことと同じです。また、TiDB のその他の主キー制約も MySQL のものと似ています。

ユニークキー制約

一意制約とは、一意のインデックスと主キー列内のすべての NULL 以外の値が一意であることを意味します。

FOREIGN KEY制約

FOREIGN KEY は、1 つのテーブル (子テーブル) の列を別のテーブル (親テーブル) の列にリンクすることで、2 つのテーブル間の参照整合性を強制するデータベース制約です。これにより、子テーブルの外部キー列の値が、親テーブルの主キー列または一意のキー列の値と一致することが保証されます。たとえば、 ordersテーブルのレコードには、 customersテーブルの顧客にリンクする外部キーがあり、各注文が有効な顧客に関連付けられていることが保証されます。

v6.6.0 以降、TiDB は外部キー制約を実験的機能としてサポートしています。この機能により、関連データのテーブル間参照が可能になり、参照整合性を強制することでデータの一貫性を維持できます。ただし、この機能は実験的であり、特に大量のデータがある場合にパフォーマンスの問題が発生する可能性があるため、本番環境では推奨されないことに注意してください。

詳細についてはFOREIGN KEY制約参照してください。

ビュー

ビューは仮想テーブルとして機能し、そのスキーマはビューを作成するSELECTのステートメントによって定義されます。ビューを使用すると、次の利点があります。

安全なフィールドとデータのみをユーザーに公開し、基になるテーブルに保存されている機密フィールドとデータのセキュリティを確保します。
頻繁に表示される複雑なクエリをビューとして定義し、複雑なクエリをより簡単に、より便利にします。

詳細についてはビュー参照してください。

シーケンス

シーケンスは、指定された一連のルールに従って数値のシーケンスを生成するように設計されたデータベースオブジェクトです。この機能は、データベーステーブルの主キーの作成など、一意の識別子が必要なシナリオで特に役立ちます。

詳細については順序参照してください。