データベーススキーマ
データベーススキーマは、データベース内のデータ構造と構成、テーブル、列、インデックス、その他のオブジェクトを定義します。
このドキュメントでは、データベース、テーブル、列、データ型、制約、インデックスなど、データベーススキーマの主要概念を紹介します。また、中間データをシームレスに管理するための一時テーブル、効率的な近似最近傍（ANN）検索のためのベクトルインデックス、読み取りパフォーマンスを向上させるためのキャッシュテーブルといった高度な機能についても紹介します。
データベース
TiDBにおけるデータベースとは、テーブルやインデックスなどのオブジェクトの集合体です。
システムデータベース
システムデータベースは、システムテーブルを格納するためにTiDBによって作成されるデフォルトのデータベースです。TiDBは以下のシステムデータベースを提供します。
testデータベース
TiDBにはtestという名前のデフォルトデータベースが付属しています。ただし、 testデータベースを使用する代わりに、独自のデータベースを作成することをお勧めします。
表
テーブルは、 データベース内の関連データのコレクションです。
各テーブルは行と列で構成されます。行の各値は特定の列に属します。各列は単一のデータ型のみを許可します。列をさらに絞り込むには、いくつかの を追加できます。計算を高速化するには、制約生成された列追加できます。
システムテーブル
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つ以上の列に基づいて構築されるインデックスであり、複数のフィールドでデータをフィルタリングまたはソートするクエリに特に役立ちます。たとえば、人物テーブルの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（階層型ナビゲート可能スモールワールド）アルゴリズムは、K近傍（KNN）検索によってベクトル空間内の最も近いデータポイントを迅速に特定することを可能にします。これによりクエリのパフォーマンスが大幅に向上し、総当たり検索に比べてミリ秒単位で結果が得られます。
ベクター インデックスは、データstorageと検索機能をTiFlashレプリカに依存します。 TiDB Cloud Dedicatedクラスターを使用している場合は、ベクター インデックスを作成または使用する前に、クラスター内でTiFlashノードが利用可能であることを確認してください。詳細については、ベクトル検索インデックス参照してください。
制約
TiDBはMySQLとほぼ同じ制約をサポートしています。
NOT NULL制約
NOT NULL制約は、列にNULL値が含まれていないことを保証します。
列がNOT NULL制約で定義されている場合、TiDB はその列にNULL値を持つ行を挿入または更新しようとするとエラーが発生することを保証します。この動作は、MySQL のNOT NULL制約の実装と一致しています。
チェック制約
CHECK制約は、テーブル内の列の値が指定された条件を満たすように制限します。 CHECK制約がテーブルに追加されると、TiDBはテーブルへのデータの挿入または更新時に、その制約が満たされているかどうかを確認します。制約が満たされていない場合は、エラーが返されます。
主キー制約
TiDBの主キー制約はMySQLと同様に一意性制約を含んでおり、主キー制約を作成することは一意性制約を持つことと同等です。さらに、TiDBのその他の主キー制約もMySQLのものと類似しています。
一意キー制約
一意制約とは、一意インデックスと主キー列に含まれるすべての非NULL値が一意であることを意味します。
外部キー制約
外部キーは、2 つのテーブル間の参照整合性を強制するデータベース制約です。これは、一方のテーブル (子テーブル) の列をもう一方のテーブル (親テーブル) の列にリンクすることによって実現されます。これにより、子テーブルの外部キー列の値が、親テーブルの主キーまたは一意キー列の値と一致することが保証されます。たとえば、 ordersテーブルのレコードは、 customersテーブルの顧客にリンクする外部キーを持つことができ、各注文が有効な顧客に関連付けられていることが保証されます。
TiDBはバージョン6.6.0以降、実験的機能として外部キー制約をサポートしています。この機能により、関連データのテーブル間参照が可能になり、参照整合性を強制することでデータの一貫性を維持できます。ただし、この機能は実験的であり、特にデータ量が多い場合、パフォーマンスの問題が発生する可能性があるため、本番環境での本番は推奨されません。
詳細については、外部キー制約を参照してください。
閲覧数
ビューは仮想テーブルとして機能し、そのスキーマはビューを作成するSELECTステートメントによって定義されます。ビューを使用することには、次のような利点があります。
基となるテーブルに保存されている機密性の高いフィールドとデータのセキュリティを確保するため、安全なフィールドとデータのみをユーザーに公開する。
複雑なクエリをより簡単かつ便利にするために、ビューとして頻繁に出現する複雑なクエリを定義する。
詳細については、閲覧数を参照してください。
シーケンス
シーケンスとは、指定された一連のルールに従って数値のシーケンスを生成するように設計されたデータベースオブジェクトです。この機能は、データベーステーブルの主キーの作成など、一意の識別子が必要なシナリオで特に役立ちます。
詳細については、 順序を参照してください。