データベーススキーマ
データベース スキーマは、データベース、テーブル、列、インデックス、およびその他のオブジェクト内のデータの構造と構成を定義します。
このドキュメントでは、データベース、テーブル、列、データ型、制約、インデックスといったデータベーススキーマの主要な概念を紹介します。また、中間データをシームレスに管理するための一時テーブル、効率的な近似最近傍検索（ANN）のためのベクターインデックス、読み取りパフォーマンスを向上させるキャッシュテーブルといった高度な機能についても紹介します。
データベース
TiDB のデータベースは、テーブルやインデックスなどのオブジェクトの集合です。
システムデータベース
システムデータベースは、システムテーブルを保存するためにTiDBによって作成されるデフォルトのデータベースです。TiDBは次のシステムデータベースを提供します。
testデータベース
TiDBにはtestというデフォルトのデータベースが付属しています。ただし、 testデータベースを使用する代わりに、独自のデータベースを作成することをお勧めします。
テーブル
テーブルは、 データベース内の関連データの集合です。
各テーブルは行と列で構成されています。行の各値は特定の列に属します。各列には単一のデータ型のみを使用できます。列をさらに限定するには、 制約を追加できます。計算を高速化するには、 生成された列追加できます。
システムテーブル
mysqlスキーマには TiDB システムテーブルが含まれています。設計は MySQL のmysqlスキーマに似ており、mysql.userなどのテーブルを直接編集できます。また、MySQL の拡張機能であるテーブルもいくつか含まれています。情報スキーマは、システムメタデータを表示するためのANSI標準の方法を提供します。TiDBは、MySQLとの互換性のために用意されているテーブルに加えて、多数のカスタム
INFORMATION_SCHEMAテーブルも提供しています。多くのINFORMATION_SCHEMAテーブルには対応するSHOWコマンドがあります。7INFORMATION_SCHEMAの利点は、テーブル間の結合が可能であることです。パフォーマンス スキーマ。TiDB は、MySQL との互換性のためにパフォーマンス スキーマ テーブルを実装します。
キャッシュされたテーブル
TiDBは、頻繁にアクセスされるものの、更新頻度の低い小さなホットスポットテーブル向けに、 キャッシュされたテーブル機能を導入しました。この機能を使用すると、テーブル全体のデータがTiDBサーバーのメモリにロードされ、TiDBはTiKVにアクセスすることなくメモリから直接テーブルデータを取得するため、読み取りパフォーマンスが向上します。
一時テーブル
一時テーブル機能は、アプリケーションの中間結果を一時的に保存するという問題を解決し、頻繁なテーブルの作成と削除から解放します。中間計算データは一時テーブルに保存できます。中間データが不要になると、TiDBは一時テーブルを自動的にクリーンアップして再利用します。これにより、ユーザーアプリケーションの複雑化を防ぎ、テーブル管理のオーバーヘッドを削減し、パフォーマンスを向上させます。
パーティションテーブル
TiDBでは、 パーティショニング使用すると、大きなテーブルをパーティションと呼ばれる1つ以上の管理しやすい部分に分割できます。各パーティションは独立しており、個別に管理できます。
列
列はテーブルに従属します。各テーブルには少なくとも1つの列が含まれます。列は、各行の値を単一のデータ型の小さなセルに分割することで、テーブルに構造を提供します。
詳細については列を定義する参照してください。
生成された列
TiDB を使用すると、JSON データ型からデータを生成された列として抽出できます。
一般的な列とは異なり、生成列の値は列定義内の式によって計算されます。生成列を挿入または更新する際には、値を割り当てることはできず、 DEFAULTのみを使用できます。
生成列には、仮想生成列と保存列の2種類があります。仮想生成列はstorageを占有せず、読み取り時に計算されます。保存列は書き込み（挿入または更新）時に計算され、storageを占有します。仮想生成列と比較すると、保存列は読み取りパフォーマンスに優れていますが、より多くのディスク容量を消費します。
データ型
TiDBは文字列型 MySQLのSPATIAL型を除くすべてのデータ型をサポートしています。これには、 数値型 日付と時刻の種類すべてが含ま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 では、 既存のテーブルにセカンダリインデックスを追加するまたは新しいテーブルを作成するときにセカンダリインデックスを作成するいずれかを選択できます。
ベクトルインデックス
注記：
ベクトルインデックス機能はベータ版です。予告なく変更される可能性があります。バグを発見した場合は、GitHubで問題報告を行ってください。
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は、テーブル内の列の値を、指定された条件を満たすように制限します。制約CHECKテーブルに追加されると、TiDBはテーブルへのデータの挿入または更新時に制約が満たされているかどうかを確認します。制約が満たされていない場合は、エラーが返されます。
主キー制約
MySQLと同様に、TiDBの主キー制約には一意制約が含まれています。つまり、主キー制約を作成することは、一意制約を持つことと同じです。さらに、TiDBの他の主キー制約もMySQLのものと似ています。
ユニークキー制約
一意制約とは、一意のインデックスと主キー列内のすべての非 NULL 値が一意であることを意味します。
FOREIGN KEY制約
FOREIGN KEYは、一方のテーブル（子テーブル）の列をもう一方のテーブル（親テーブル）の列にリンクすることで、2つのテーブル間の参照整合性を確保するデータベース制約です。これにより、子テーブルの外部キー列の値が、親テーブルの主キー列または一意キー列の値と一致することが保証されます。例えば、 ordersテーブルのレコードに、 customersテーブルの顧客にリンクする外部キーを設定することで、各注文が有効な顧客に関連付けられることが保証されます。
TiDB v6.6.0以降、外部キー制約が実験的機能としてサポートされます。この機能により、関連データのテーブル間参照が可能になり、参照整合性を強制することでデータの一貫性を維持できます。ただし、この機能は実験的であり、特に大量のデータを扱う場合のパフォーマンス問題が発生する可能性があるため、本番環境での使用は推奨されません。
詳細についてはFOREIGN KEY制約参照してください。
ビュー
ビューは仮想テーブルとして機能し、そのスキーマはビューを作成するSELECTステートメントによって定義されます。ビューを使用すると、次のような利点があります。
安全なフィールドとデータのみをユーザーに公開し、基になるテーブルに保存されている機密フィールドとデータのセキュリティを確保します。
頻繁に表示される複雑なクエリをビューとして定義し、複雑なクエリをより簡単に、より便利にします。
詳細についてはビュー参照してください。
シーケンス
シーケンスとは、指定された一連のルールに従って数値のシーケンスを生成するように設計されたデータベースオブジェクトです。この機能は、データベーステーブルの主キーの作成など、一意の識別子が必要なシナリオで特に役立ちます。
詳細については順序参照してください。