MySQL 用語集

ARCHIVE テーブルのメタデータ。 .ARZ ファイルと対比してください。 この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されるバックアップに含められます。

.ARZ ファイル, MySQL Enterprise Backup, mysqlbackup コマンドも参照

ARCHIVE テーブルのデータ。 .ARM ファイルと対比してください。 この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されるバックアップに含められます。

.ARM ファイル, MySQL Enterprise Backup, mysqlbackup コマンドも参照

InnoDB トランスポータブルテーブルスペース機能で使用するメタデータファイル。 これは、コマンド FLUSH TABLES ... FOR EXPORT で生成され、1 つまたは複数のテーブルを、別のサーバーにコピーできる一貫した状態にします。 .cfg ファイルは、対応する .ibd ファイルとともにコピーされ、ALTER TABLE ... IMPORT TABLESPACE ステップ中に space ID などの .ibd ファイルの内部値を調整するために使用されます。

.ibd ファイル, スペース ID, トランスポータブルテーブルスペースも参照

MySQL テーブルのメタデータ (テーブル定義など) を含むファイル。.frm ファイルは MySQL 8.0 で削除されましたが、以前の MySQL リリースでは引き続き使用されています。 MySQL 8.0 では、以前に .frm ファイルに格納されたデータはデータディクショナリテーブルに格納されます。

データディクショナリ, MySQL Enterprise Backup, システムテーブルスペースも参照

file-per-table テーブルスペースおよび一般テーブルスペースのデータファイル。 File-per-table テーブルスペースの .ibd ファイルには、単一のテーブルおよび関連するインデックスデータが含まれます。 一般テーブルスペース .ibd ファイルには、複数のテーブルのテーブルおよびインデックスデータを含めることができます。

.ibd ファイル拡張子は、1 つ以上のibdata ファイルで構成されるシステムテーブルスペースには適用されません。

file-per-table テーブルスペースまたは一般テーブルスペースが DATA DIRECTORY = 句を使用して作成された場合、.ibd ファイルは通常のデータディレクトリ外の指定されたパスにあります。

MySQL Enterprise Backup 製品によって .ibd ファイルが圧縮バックアップに含まれるとき、圧縮版は .ibz ファイルです。

データベース, file-per-table, 一般テーブルスペース, ibdata ファイル, .ibz ファイル, innodb_file_per_table, MySQL Enterprise Backup, システムテーブルスペースも参照

MySQL Enterprise Backup 製品が圧縮バックアップを実行するときに、これは、file-per-table 設定を使用して作成される各テーブルスペースファイルを、.ibd 拡張子から .ibz 拡張子に変換します。

バックアップ中に適用される圧縮は、通常操作中にテーブルデータを圧縮されたままにする圧縮行フォーマットとは異なります。 圧縮バックアップ操作では、すでに圧縮行フォーマットであるテーブルスペースについては圧縮ステップをスキップします。2 回目の圧縮では、バックアップ速度を低下させるだけで、ほとんどまたはまったく領域を節約しないためです。

圧縮バックアップ, 圧縮行フォーマット, file-per-table, .ibd ファイル, MySQL Enterprise Backup, テーブルスペースも参照

MERGE ストレージエンジンで使用される、ほかのテーブルへの参照を含むファイル。 この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されるバックアップに含められます。

MySQL Enterprise Backup, mysqlbackup コマンドも参照

MySQL が MyISAM テーブルのデータを格納するために使用するファイル。

.MYI ファイル, MySQL Enterprise Backup, mysqlbackup コマンドも参照

MySQL が MyISAM テーブルのインデックスを格納するために使用するファイル。

.MYD ファイル, MySQL Enterprise Backup, mysqlbackup コマンドも参照

ADO.NET, ASP.net, Connector/NET, モノ, Visual Studioも参照

データベース構成情報を含むファイル。 この拡張子のファイルは、MySQL Enterprise Backup 製品の mysqlbackup コマンドによって生成されたバックアップに含まれます。

MySQL Enterprise Backup, mysqlbackup コマンドも参照

パーティション定義を含むファイル。 この拡張子のファイルは、MySQL Enterprise Backup 製品の mysqlbackup コマンドによって生成されたバックアップに含まれます。

MySQL 5.7.6 での InnoDB テーブルのネイティブパーティション化サポートの導入により、パーティション化された InnoDB テーブルの .par ファイルは作成されなくなりました。 パーティション化された MyISAM テーブルでは、MySQL 5.7 の .par ファイルが引き続き使用されます。 MySQL 8.0 では、パーティション分割のサポートは InnoDB ストレージエンジンによってのみ提供されます。 そのため、.par ファイルは MySQL 8.0 の時点では使用されなくなりました。

MySQL Enterprise Backup, mysqlbackup コマンドも参照

XA 仕様に基づく分散型トランザクションの一部である操作。 (2PC と略記されることがあります。) 複数のデータベースがトランザクションに参加する場合、すべてのデータベースが変更をコミットするか、すべてのデータベースが変更をロールバックします。

コミット, ロールバック, トランザクション, XAも参照

原子性 (atomicity)、一貫性 (consistency)、分離性 (isolation)、持続性 (durability) を表す頭字語。 これらの特性はすべてデータベースシステムで望ましく、すべてトランザクションの概念に密接に結び付けられています。 InnoDB のトランザクション機能は ACID の原則に準拠しています。

トランザクションは、コミットまたはロールバックできる原子的な作業単位です。 トランザクションによってデータベースに複数の変更が行われた場合、トランザクションがコミットされるとすべての変更が完了し、トランザクションがロールバックされるとすべての変更が元に戻されます。

データベースは常に一貫性のある状態のままです - 各コミットまたはロールバックの後、およびトランザクションの進行中。 関連データが複数のテーブルにわたって更新されている場合、クエリーは、古い値と新しい値の混合ではなく、すべて古い値か、すべて新しい値のどちらかを見ます。

トランザクションは進行中、互いから保護 (分離) されます。それらは互いに干渉できず、互いのコミットされていないデータを見ることはできません。 この分離性は、ロックメカニズムを通じて実現します。 経験豊富なユーザーは、実際にトランザクションが互いに干渉しないと確信できれば、パフォーマンスと並列性の向上の代わりに保護の低下をトレードオフするように分離レベルを調整できます。

トランザクションの結果は持続的です。コミット操作が成功すると、そのトランザクションによって行われた変更は、データベース以外の多くのアプリケーションが脆弱である停電、システムのクラッシュ、競合状況、またはほかの潜在的な危険から保護されます。 持続性には通常、ディスクストレージへの書き込みがかかわっており、書き込み操作中の停電またはソフトウェアクラッシュに対して保護するために一定の冗長性を備えています。 (InnoDB では、二重書込みバッファは永続性を支援します。)

原子的, コミット, 並列性, 二重書き込みバッファー, 分離レベル, ロック, ロールバック, トランザクションも参照

ASP.NET などの .NET テクノロジを使用して構築されたアプリケーション用のオブジェクトリレーショナルマッピング (ORM) フレームワーク。 このようなアプリケーションは、Connector/NET コンポーネントを介して MySQL とインタフェースできます。

.NET, ASP.net, Connector/NET, モノ, Visual Studioも参照

非同期 I/O (Asynchronous I/O) の頭字語。 この頭字語は、InnoDB メッセージまたはキーワードに表示される場合があります。

非同期 I/Oも参照

ODBC では、文字セットおよびその他の国際化の側面をサポートする代替方法。 Unicode と対比してください。 Connector/ODBC 3.51 は ANSI ドライバですが、Connector/ODBC 5.1 は Unicode ドライバです。

Connector/ODBC, ODBC, Unicodeも参照

API は、client プログラムから MySQL プロトコルおよび MySQL リソースへの低レベルのアクセスを提供します。 Connector によって提供される上位レベルのアクセスと対比してください。

C API, クライアント, コネクタ, ネイティブ C API, Perl API, PHP API, Python API, Ruby APIも参照

.NET テクノロジおよび言語を使用して web ベースのアプリケーションを開発するためのフレームワーク。 このようなアプリケーションは、Connector/NET コンポーネントを介して MySQL とインタフェースできます。

MySQL を使用してサーバー側の web ページを作成する別のテクノロジは、PHP です。

.NET, ADO.NET, Connector/NET, モノ, PHP, Visual Studioも参照

データベースインデックスに一般的に使用されるツリーデータ構造。 この構造は、常にソートされ続け、正確な一致 (等号演算子) および範囲 (大なり、小なり、BETWEEN 演算子など) の高速ルックアップを可能にします。 このタイプのインデックスは、InnoDB や MyISAM などのほとんどのストレージエンジンで使用できます。

B ツリーノードには多くの子を含むことができるので、B ツリーは、ノードごとに 2 つの子に限られているバイナリツリーと同じではありません。

MEMORY ストレージエンジンでのみ使用可能なハッシュインデックスと対比してください。 MEMORY ストレージエンジンでは B ツリーインデックスも使用でき、一部のクエリーで範囲演算子が使用されている場合は、MEMORY テーブルに B ツリーインデックスを選択する必要があります。

B ツリーという用語の使用は、インデックス設計の一般クラスへの参照として意図されています。 MySQL ストレージエンジンで使用される B ツリー構造は、従来の B ツリー設計には存在しないため、バリアントとみなされることがあります。 関連情報は、MySQL Internals Manual の InnoDB Page Structure 「ファイルヘッダー」のセクションを参照してください。

ハッシュインデックスも参照

バイナリログファイルの非公式名。 たとえば、電子メールメッセージやフォーラムディスカッションでこの略語を見ることがあります。

バイナリログも参照

任意のサイズの任意の種類のバイナリデータを含むオブジェクトの SQL データ型 (TINYBLOB, BLOB, MEDIUMBLOB および LONGBLOB)。 MySQL テーブル内の行およびカラムに簡単に分解できないドキュメント、イメージ、サウンドファイルおよびその他の種類の情報を格納するために使用されます。 MySQL アプリケーション内で BLOB を処理する手法は、Connector および API ごとに異なります。 MySQL Connector/ODBC では、BLOB 値を LONGVARBINARY として定義します。 文字データの大規模で自由形式のコレクションの場合、業界用語は MySQL TEXT データ型で表される CLOB です。

API, CLOB, コネクタ, Connector/ODBCも参照

移植性とパフォーマンスを組み合わせ、低レベルのハードウェア機能にアクセスし、オペレーティングシステム、ドライバ、およびその他の種類のシステムソフトウェアを記述するための一般的な選択を可能にするプログラミング言語。 C で記述された複雑なアプリケーション、言語および再利用可能なモジュールの多くは、他の言語で記述された高レベルのコンポーネントと結び付けられています。 そのコア構文は、C++、Java および C#の開発者によく知られています。

C API, C++, C#, Javaも参照

C API コードは、MySQL とともに配布されます。 これは libmysqlclient ライブラリに含まれ、C プログラムがデータベースにアクセスできるようにします。

API, C, libmysqlclientも参照

強力な型付け機能とオブジェクト指向機能を組み合せたプログラミング言語で、Microsoft .NET フレームワークまたはそれに対応するオープンソースのモノ内で実行されます。 多くの場合、ASP.net フレームワークを使用したアプリケーションの作成に使用されます。 この構文は、C、C++ および Java 開発者によく知られています。

.NET, ASP.net, C, Connector/NET, C++, Java, モノも参照

C 開発者に精通したコア構文を持つプログラミング言語。 高レベルのデータ型、オブジェクト指向機能およびガベージコレクションと組み合せて、パフォーマンスのための低レベルの操作へのアクセスを提供します。 MySQL 用の C++ アプリケーションを作成するには、Connector/C++ コンポーネントを使用します。

C, Connector/C++も参照

任意のサイズの任意の種類の文字データを含むオブジェクトの SQL データ型 (TINYTEXT, TEXT, MEDIUMTEXT または LONGTEXT)。 関連付けられた文字セットおよび照合順序とともにテキストベースのドキュメントを格納するために使用されます。 MySQL アプリケーション内で CLOB を処理する手法は、Connector および API ごとに異なります。 MySQL Connector/ODBC では、TEXT 値を LONGVARCHAR として定義します。 バイナリデータを格納する場合、BLOB 型に相当します。

API, BLOB, コネクタ, Connector/ODBCも参照

Connector/C++ 8.0 を使用すると、document store を実装する MySQL サーバーにアクセスしたり、SQL クエリーを使用して従来の方法でアクセスできます。 これにより、X DevAPI を使用した C++ アプリケーションの開発、または X DevAPI for C を使用したプレーン C アプリケーションの開発が可能になります。 また、Connector/C++ 1.1 から従来の JDBC ベース API を使用する C++ アプリケーションの開発も可能です。 詳細は、MySQL Connector/C++ 8.0 Developer Guideを参照してください。

クライアント, コネクタ, JDBCも参照

Java プログラミング言語で開発された client アプリケーションの接続を提供する JDBC ドライバ。 MySQL Connector/J は JDBC タイプ 4 ドライバです: MySQL クライアントライブラリに依存しない MySQL プロトコルのピュア Java 実装。 詳細は、MySQL Connector/J 8.0 Developer Guideを参照してください。

クライアント, クライアントライブラリ, コネクタ, Java, JDBCも参照

C#、.NET、モノ、Visual Studio、ASP.net、および ADO.net などのアプリケーションを記述する開発者向けの MySQL コネクタ。

ADO.NET, ASP.net, コネクタ, C#, モノ, Visual Studioも参照

業界標準の Open Database Connectivity (ODBC) API を使用して MySQL データベースへのアクセスを提供する MySQL ODBC ドライバのファミリ。 以前の名前は MyODBC ドライバです。 詳細は、MySQL Connector/ODBC Developer Guideを参照してください。

コネクタ, ODBCも参照

Windows オペレーティングシステム用に最適化された mysql および mysqli APIs for PHP のバージョン。

コネクタ, PHP, PHP APIも参照

ワークロードの種類の 1つ。主なボトルネックがメモリー内の CPU 操作であるもの。 通常、バッファープール内にすべての結果をキャッシュできる、読み取り中心の操作を含みます。

ボトルネック, バッファープール, ワークロードも参照

「「作成、読取り、更新、削除」」の頭字語。データベースアプリケーションでの一般的な一連の操作です。 多くの場合、どの言語でもすばやく実装でき、比較的単純にデータベースを使用するタイプのアプリケーション (基本的な DDL、DML、および SQL のクエリーステートメント) を示します。

DDL, DML, クエリー, SQLも参照

データ制御言語 (Data Control Language)。権限を管理するための SQL ステートメントのセット。 MySQL では、GRANT および REVOKE ステートメントから構成されます。 DDL および DML と対比してください。

DDL, DML, SQLも参照

Visual Studio 内のデータ設計ツールを使用して、MySQL データベース内のスキーマおよびオブジェクトを操作できる機能。 Connector/NET を使用する MySQL アプリケーションの場合、MySQL Visual Studio プラグインは MySQL 5.0 以降で DDEX プロバイダとして機能します。

Visual Studioも参照

データ定義言語 (Data Definition Language)。個々のテーブル行ではなくデータベース自体を操作するための SQL ステートメントのセット。 CREATE、ALTER、および DROP ステートメントのすべての形式を含みます。 TRUNCATE ステートメントも含まれます。DELETE FROM table_name ステートメントと動作が異なるためです (最終的な効果は似ていますが) 。

DDL ステートメントは自動的に現在のトランザクションをコミットします。それらをロールバックすることはできません。

InnoDB online DDL 機能により、CREATE INDEX、DROP INDEX、および多くのタイプの ALTER TABLE 操作のパフォーマンスが向上します。 詳細は、セクション15.12「InnoDB とオンライン DDL」を参照してください。 また、InnoDB file-per-table 設定は、DROP TABLE および TRUNCATE TABLE 操作の動作に影響を与える可能性があります。

DML および DCL と対比してください。

コミット, DCL, DML, file-per-table, ロールバック, SQL, トランザクションも参照

データ操作言語。INSERT、UPDATE および DELETE 操作を実行するための一連の SQL ステートメント。 SELECT ステートメントが DML ステートメントと見なされる場合があります。SELECT ... FOR UPDATE 形式が、INSERT、UPDATE、および DELETE と同じ、ロックに関する考慮事項に従うためです。

InnoDB テーブルの DML ステートメントはトランザクションのコンテキストで動作するため、committed またはロールバック済を単一ユニットとして使用できます。

DDL および DCL と対比してください。

コミット, DCL, DDL, ロック, ロールバック, SQL, トランザクションも参照

「「データベースソース名」」の頭字語。 これは、Connector/ODBC 内の connection 情報のエンコーディングです。 詳細は、Configuring a Connector/ODBC DSN on Windowsを参照してください。 これは、Connector/NET で使用される接続文字列と同等です。

接続, 接続文字列, Connector/NET, Connector/ODBCも参照

多くのオブジェクト指向機能を含むプログラミング言語。 その概念の一部は、Java および C#の開発者によく知られています。 オープンソース Eiffel API for MySQL については、セクション29.13「MySQL Eiffel ラッパー」 を参照してください。

API, C#, Javaも参照

障害発生時にスタンバイサーバーに自動的に切り替える機能。 MySQL コンテキストでは、フェイルオーバーにはスタンバイデータベースサーバーが含まれます。 多くの場合、アプリケーションサーバーまたはフレームワークによって J2EE 環境内でサポートされます。

Connector/J, J2EEも参照

innodb_file_per_table オプションによって制御される設定の一般名。これは、InnoDB ファイルの記憶域、機能の可用性および I/O 特性の側面に影響を与える重要な構成オプションです。 MySQL 5.6.7 では、innodb_file_per_table はデフォルトで有効になっています。

innodb_file_per_table オプションを有効にすると、システムテーブルスペースの共有ibdata ファイルではなく、独自の.ibd ファイルにテーブルを作成できます。 テーブルデータが個々の.ibd ファイルに格納されている場合、データ compression などの機能に必要な行フォーマットを柔軟に選択できます。 TRUNCATE TABLE 操作も高速であり、InnoDB 用に予約されている残りの領域ではなく、オペレーティングシステムで再利用された領域を使用できます。

MySQL Enterprise Backup 製品は、テーブルがその独自のファイルに格納されるので柔軟性が高くなります。 たとえば、テーブルをバックアップから排除できますが、これは個別のファイルに格納されている場合に限られます。 したがって、この設定は、あまり頻繁にはバックアップされない、または異なるスケジュールでバックアップされるテーブルに適しています。

圧縮行フォーマット, 圧縮, ファイル形式, .ibd ファイル, ibdata ファイル, innodb_file_per_table, MySQL Enterprise Backup, 行フォーマット, システムテーブルスペースも参照

外部キー関係を通じてデータベース一貫性を維持するタイプの制約。 ほかの種類の制約と同様に、データが一貫性を失った場合にデータが挿入または更新されるのを防止できます。ここでは、複数のテーブル内のデータ間の一貫性が失われることが防止されます。 または、DML 操作が実行されるときに FOREIGN KEY 制約によって、外部キー作成時に指定された ON CASCADE オプションに基づいて、子行内のデータが削除されたり、別の値に変更されたり、NULL に設定されたりします。

子テーブル, 制約, DML, 外部キー, NULLも参照

ほとんどのコンテキストで、全文検索 (Full-Text Search) の頭字語。 パフォーマンスディスカッションでは、フルテーブルスキャン (Full Table Scan) の頭字語の場合があります。

テーブルの完全スキャン, 全文検索も参照

MySQL 全文検索メカニズムでの検索インデックスを保持する、特殊なインデックス。 ストップワードとして指定されたものを飛ばして、カラムの値からの単語を表します。 もともとは、利用できるのは MyISAM テーブルだけでした。 MySQL 5.6.4 以降では、InnoDB テーブルでも利用できます。

全文検索, インデックス, InnoDB, 検索インデックス, ストップワードも参照

「「一般に使用可能」」は、ソフトウェア製品がベータから退出し、販売、公式サポートおよび本番で使用できる段階です。

ベータも参照

「「グローバルアセンブリキャッシュ」」の頭字語。 .NET システムにライブラリ (アセンブリ) を格納するための中心的な領域。 物理的にはネストされたフォルダで構成され、.NET CLR によって単一の仮想フォルダとして扱われます。

.NET, アセンブリも参照

J2EEも参照

「「グローバル一意識別子」」の頭字語。異なるデータベース、言語、オペレーティングシステムなど間でデータを関連付けるために使用できる ID 値。 (同じ値が異なるテーブルやデータベースなどで異なるデータを参照する場合がある、順次整数を使用するかわりに使用します。) 古い MySQL バージョンでは、BINARY(16) として表されていました。 現在、CHAR(36) として表されています。 MySQL には、GUID 値を文字形式で返す UUID() 関数と、GUID 値を整数形式で返す UUID_SHORT() 関数があります。 連続する GUID 値は必ずしも昇順ではないため、大きな InnoDB テーブルの主キーとして使用すると効率的な値ではありません。

「「ハードディスクドライブ」」の頭字語。 SSD と対比されることが多く、スピニングプラッターを使用するストレージメディアを指します。 そのパフォーマンス特性はディスクベースワークロードのスループットに影響を与えることがあります。

ディスクベース, SSDも参照

MySQL データベース内で InnoDB によって管理される一連のファイル: システムテーブルスペース、file-per-table テーブルスペースファイルおよびredo ログファイル。 MySQL のバージョンおよび InnoDB の構成によっては、一般テーブルスペース、一時テーブルスペースおよびundo テーブルスペースファイルも含まれる場合があります。 この用語は、MySQL データベース内の InnoDB によって管理される一連のファイルを指すために、InnoDB のファイル構造および形式の詳細な説明で使用されることがあります。

データベース, file-per-table, 一般テーブルスペース, Redo ログ, システムテーブルスペース, 一時テーブルスペース, Undo テーブルスペースも参照

ホットバックアップ操作中に MySQL Enterprise Backup 製品により作成される補助的なバックアップファイル。 ここには、バックアップの実行中に行われたデータ変更に関する情報が含まれます。 ibbackup_logfile などの初期バックアップファイルは、バックアップ操作中に行われた変更がまだ組み込まれていないので、raw バックアップと呼ばれます。 raw バックアップファイルへの適用ステップを実行したあと、結果として得られるファイルは、最終データ変更を含んでおり、準備されたバックアップと呼ばれます。 この段階で、ibbackup_logfile ファイルは必要なくなります。

適用, ホットバックアップ, MySQL Enterprise Backup, 準備されたバックアップ, raw バックアップも参照

InnoDB システムテーブルスペースを構成する、ibdata1、ibdata2 などの名前を持つファイルのセット。 システムテーブルスペースの ibdata ファイルに存在する構造およびデータの詳細は、セクション15.6.3.1「システムテーブルスペース」 を参照してください。

ibdata ファイルの増加は、innodb_autoextend_increment 構成オプションの影響を受けます。

変更バッファー, データディクショナリ, 二重書き込みバッファー, file-per-table, .ibd ファイル, innodb_file_per_table, システムテーブルスペース, Undo ログも参照

圧縮されていない InnoDB 一時テーブルおよび関連オブジェクトの InnoDB 一時テーブルスペース データファイル。 構成ファイルオプション innodb_temp_data_file_path を使用すると、ユーザーは一時テーブルスペースデータファイルの相対パスを定義できます。 innodb_temp_data_file_path が指定されない場合のデフォルト動作は、データディレクトリ内に ibdata1 と一緒に、ibtmp1 という名前の単一自動拡張 12M バイトデータファイルを作成することです。

データファイル, 一時テーブル, 一時テーブルスペースも参照

通常は ib_logfile0 および ib_logfile1 という名前が付けられ、Redo ログを形成するファイルのセット。 ロググループと呼ばれることもあります。 これらのファイルには、InnoDB テーブルのデータを変更しようとするステートメントが記録されます。 これらのステートメントは、クラッシュ後の起動時に、未完了のトランザクションで書き込まれたデータを修正するために自動的に再現されます。

このデータは手動リカバリには使用できません。このタイプの操作には、バイナリログを使用してください。

バイナリログ, ロググループ, Redo ログも参照

InnoDB FULLTEXT インデックス内では、トークン (特定の単語) のドキュメント ID と位置情報で構成されるデータ構造。

FULLTEXT インデックスも参照

MySQL データディクショナリへのクエリーインタフェースを提供するデータベースの名前。 (この名前は ANSI SQL 標準で定義されています。) データベースに関する情報 (メタデータ) を調べるには、構造化されていない出力を返す SHOW コマンドを使用する代わりに、INFORMATION_SCHEMA.TABLES や INFORMATION_SCHEMA.COLUMNS などのテーブルを照会できます。

INFORMATION_SCHEMA データベースには、InnoDB データディクショナリへのクエリーインタフェースを提供する InnoDB 固有のテーブルも含まれています。 これらのテーブルは、データベースの構造を確認するのではなく、パフォーマンスの監視、チューニングおよびトラブルシューティングに役立つように、InnoDB テーブルの動作に関するリアルタイム情報を取得するために使用します。

データディクショナリ, データベース, InnoDBも参照

高いパフォーマンスと、信頼性、堅牢性、および同時アクセスのためのトランザクション機能とを結合する MySQL コンポーネント。 これは ACID 設計概念を具体化したものです。 ストレージエンジンとして表現され、ENGINE=INNODB 句で作成または変更されたテーブルを処理します。 アーキテクチャーの詳細および管理手順については第15章「InnoDB ストレージエンジン」、パフォーマンスのアドバイスについてはセクション8.5「InnoDB テーブルの最適化」を参照してください。

MySQL 5.5 以上では、InnoDB が新しいテーブルのデフォルトのストレージエンジンであり、ENGINE=INNODB 句は必要ありません。

InnoDB テーブルは、ホットバックアップに最適です。 通常の処理を妨げることなく MySQL Server をバックアップできる MySQL Enterprise Backup 製品の詳細は、セクション30.2「MySQL Enterprise Backup の概要」を参照してください。

ACID, ホットバックアップ, MySQL Enterprise Backup, ストレージエンジン, トランザクションも参照

innodb_autoinc_lock_mode オプションは、自動インクリメントロックに使用されるアルゴリズムを制御します。 自動インクリメントする主キーがある場合は、innodb_autoinc_lock_mode=1 設定でのみステートメントベースレプリケーションを使用できます。 この設定は、トランザクション内の複数行挿入が連続自動インクリメント値を受け取るため、連続ロックモードと呼ばれます。 挿入操作でより高い並列性を許可する innodb_autoinc_lock_mode=2 を使用する場合は、ステートメントベースレプリケーションではなく行ベースレプリケーションを使用してください。 この設定はインターリーブロックモードと呼ばれます。これは、同時に実行される複数行の挿入ステートメントがインターリーブされる auto-increment 値を受信できるためです。 互換性の目的以外は、innodb_autoinc_lock_mode=0 の設定を使用しないでください。

連続ロックモード (innodb_autoinc_lock_mode=1) は、MySQL 8.0.3 より前のデフォルト設定です。 MySQL 8.0.3 の時点では、インターリーブロックモード (innodb_autoinc_lock_mode=2) がデフォルトであり、デフォルトのレプリケーションタイプとしてステートメントベースから行ベースのレプリケーションへの変更が反映されます。

自動インクリメント, 自動インクリメントロック, 混在モード挿入, 主キーも参照

InnoDB ファイルストレージの様々な側面、機能の可用性および I/O 特性に影響する重要な構成オプション。 MySQL 5.6.7 以降ではデフォルトで有効になっています。 innodb_file_per_table オプションは、file-per-table モードをオンにします。 このモードを有効にすると、新しく作成された InnoDB テーブルおよび関連するインデックスをシステムテーブルスペースの外部の file-per-table .ibd ファイルに格納できます。

このオプションは、DROP TABLE や TRUNCATE TABLE など、いくつかの SQL ステートメントのパフォーマンスおよびストレージに関する考慮事項に影響します。

innodb_file_per_table オプションを有効にすると、MySQL Enterprise Backup のテーブル compression や名前付きテーブルバックアップなどの機能を利用できます。

詳細は、innodb_file_per_table および セクション15.6.3.2「File-Per-Table テーブルスペース」 を参照してください。

圧縮, file-per-table, .ibd ファイル, MySQL Enterprise Backup, システムテーブルスペースも参照

innodb_lock_wait_timeout オプションは、共有リソースが利用できるようになるまで待機するか、または放棄してエラーを処理したり、再試行したり、アプリケーションで代替処理を行ったりするかのバランスを設定します。 指定した時間を超えて lock を取得するのを待機している InnoDB トランザクションをロールバックします。 特に、異なるストレージエンジンで制御される複数のテーブルへの更新によってデッドロックが発生した場合に役立ちます。このようなデッドロックは自動的には検出されません。

デッドロック, デッドロック検出, ロック, 待機も参照

innodb_strict_mode オプションは、InnoDB がstrict モードで動作するかどうかを制御します。通常は警告として処理される条件では、かわりにエラーが発生します (基礎となるステートメントは失敗します)。

厳密モードも参照

アプリケーションの一部の側面を計測またはデバッグするためのコード。アプリケーション自体のソースを再コンパイルまたは変更せずに有効にできます。

コマンドインタセプタ, Connector/J, Connector/NET, 例外インターセプタも参照

1 秒あたりの I/O 操作 (I/O Operations Per Second) の頭字語。 ビジーシステム、特に OLTP アプリケーションの一般的な測定基準。 ストレージデバイスが処理できる最大値にこの値が近い場合、アプリケーションはディスクバウンドになり、スケーラビリティーを制限する場合があります。

ディスクバウンド, OLTP, スケーラビリティーも参照

Java プラットフォーム、Enterprise Edition: Oracle エンタープライズ Java プラットフォーム。 これは、エンタープライズクラスの Java アプリケーションの API およびランタイム環境で構成されます。 詳細は、http://www.oracle.com/technetwork/java/javaee/overview/index.htmlを参照してください。 MySQL アプリケーションでは、通常、Connector/J をデータベースアクセスに使用し、Tomcat や JBoss などのアプリケーションサーバーを使用して中間層の作業を処理し、オプションで Spring などのフレームワークを処理します。 多くの場合、J2EE スタック内で提供されるデータベース関連の機能には、接続プールおよび failover のサポートが含まれます。

接続プール, Connector/J, failover, Java, JBoss, Spring, Tomcatも参照

高性能で豊富な組込み機能とデータ型、オブジェクト指向メカニズム、広範な標準ライブラリ、および幅広い再利用可能なサードパーティモジュールを組み合せたプログラミング言語。 エンタープライズ開発は、多くのフレームワーク、アプリケーションサーバーおよびその他のテクノロジでサポートされています。 その構文の多くは、C および C++ の開発者によく知られています。 MySQL を使用して Java アプリケーションを作成するには、Connector/J と呼ばれる JDBC ドライバを使用します。

C, Connector/J, C++, JDBCも参照

J2EEも参照

Java アプリケーションからのデータベースアクセス用の API である「「Java データベース接続」」の略称。 MySQL アプリケーションを作成する Java 開発者は、Connector/J コンポーネントを JDBC ドライバとして使用します。

API, Connector/J, J2EE, Javaも参照

Javaも参照

SSLも参照

圧縮行形式を使用する InnoDB テーブル内のデータページのサイズを指定するオプション。 デフォルトは 8K バイトです。 値を小さくすると、行サイズと圧縮比率の組み合わせによって内部制限に達する恐れがあります。

MyISAM テーブルの場合、KEY_BLOCK_SIZE はオプションで、インデックスキーブロックに使用するサイズをバイト単位で指定します。 この値はヒントとして扱われます。必要に応じて、異なるサイズが使用される可能性があります。 個々のインデックス定義に指定された KEY_BLOCK_SIZE 値は、テーブルレベルの KEY_BLOCK_SIZE 値をオーバーライドします。

圧縮行フォーマットも参照

libmysqlclient ライブラリの非公式名。

libmysqlclientも参照

libmysqlclient.a または libmysqlclient.so という名前のライブラリファイル。通常、C で記述された client プログラムにリンクされています。 非公式には libmysql または mysqlclient ライブラリと呼ばれることもあります。

クライアント, libmysql, mysqlclientも参照

この埋込み MySQL サーバーライブラリを使用すると、client アプリケーション内でフル機能の MySQL サーバーを実行できます。 この主なメリットは組み込みアプリケーションの速度の向上と管理の単純化です。 libmysqlclient ではなく libmysqld ライブラリとリンクします。 API は、これらの 3 つのライブラリすべてで同一です。

クライアント, 埋込み, libmysql, libmysqlclientも参照

接続も参照

共有 lock を使用すると、トランザクションで行を読み取ることができます。 複数のトランザクションが同時にその同じ行で S ロックを獲得できます。

排他 (X) ロックでは、トランザクションは行を更新または削除できます。 ほかのトランザクションは、同時にその同じ行でどのようなロックも獲得できません。

インテンションロックはテーブルに適用され、トランザクションがテーブルの行で取得するロックの種類を示すために使用されます。 トランザクションごとに異なる種類のインテンションロックを同じテーブルで獲得できますが、最初のトランザクションがあるテーブルでインテンション排他 (IX) ロックを獲得すると、ほかのトランザクションはそのテーブルで S または X ロックを獲得できません。 反対に、最初のトランザクションがあるテーブルでインテンション共有 (IS) ロックを獲得すると、ほかのトランザクションはそのテーブルで X ロックを獲得できません。 2 フェーズプロセスは、ロックおよび互換性のある対応操作をブロックせずに、ロックリクエストを順番に解決できます。

インテンションロック, ロック, ロック, トランザクションも参照

サーバー startup の後に InnoDB 構成オプションに追加された接頭辞。そのため、現在のレベルの MySQL で認識されない新しい構成オプションは起動に失敗しません。 MySQL は、このプリフィクスで始まる構成オプションを処理しますが、プリフィクスに続く部分が認識されるオプションでない場合、エラーではなく警告を返します。

起動も参照

「「最低使用頻度」」の頭字語。記憶域を管理するための一般的な方法です。 より新しい項目をキャッシュするための領域が必要なときは、最近使用されていない項目は削除されます。 InnoDB では、バッファプール内で pages を管理するために LRU メカニズムがデフォルトで使用されますが、全テーブルスキャン中など、ページが一度のみ読み取られる可能性がある場合は例外が発生します。 LRU アルゴリズムのこのバリエーションはミッドポイント挿入戦略と呼ばれます。 詳細は、セクション15.5.1「バッファプール」を参照してください。

バッファープール, エビクション, テーブルの完全スキャン, ミッドポイント挿入戦略, ページも参照

「ログシーケンス番号」の頭字語。 この任意の増加し続ける値は、Redo ログに記録される操作に対応する時点を表します。 (この時点は、トランザクション境界を意識しません。1 つ以上のトランザクションの中間になることがあります。) これは、クラッシュリカバリの実行中およびバッファプールの管理のために InnoDB によって内部的に使用されます。

MySQL 5.6.3 より前では、LSN は 4 バイト符号なし整数でした。 LSN は、MySQL 5.6.3 で 8 バイト符号なし整数になりました。追加サイズ情報を格納するために追加バイトが必要だったので、Redo ログファイルサイズ限度が 4G バイトから 512G バイトに増加したためです。 MySQL 5.6.3 以降でビルドされたアプリケーションのうち LSN 値を使用するものは、32 ビット変数ではなく 64 ビット変数を使用して LSN 値を格納および比較することをお勧めします。

MySQL Enterprise Backup 製品では、増分バックアップを取得する時点を表す LSN を指定できます。 該当する LSN は、mysqlbackup コマンドの出力で表示されます。 完全バックアップの時点に対応する LSN がわかれば、後続の増分バックアップを取得するためにその値を指定でき、その出力には次の増分バックアップのもう 1 つの LSN が含まれます。

バッファープール, クラッシュリカバリ, 増分バックアップ, MySQL Enterprise Backup, Redo ログ, トランザクションも参照

「「メタデータロック」」の頭字語。

メタデータロックも参照

多くの MySQL および NoSQL ソフトウェアスタックで広く使用されているコンポーネント。単一値を高速で読み書きでき、結果全体をメモリーにキャッシュします。 アプリケーションは従来、永続的ストレージに同じデータを MySQL データベースに書き込むため、またはまだメモリーにキャッシュされていない場合は MySQL データベースからデータを読み取るために、特別なロジックを必要としていました。 アプリケーションでは、多くの言語のクライアントライブラリでサポートされている単純な memcached プロトコルを使用して、InnoDB または NDB テーブルを使用して MySQL サーバーと直接通信できるようになりました。 MySQL テーブルへのこれらの NoSQL インタフェースを使用すると、アプリケーションは SQL ステートメントを直接発行するよりも高い読取りおよび書込みパフォーマンスを実現でき、インメモリーキャッシュ用に memcached がすでに組み込まれているシステムのアプリケーションロジックおよびデプロイメント構成を簡略化できます。

InnoDB テーブルへの memcached インタフェースは、MySQL 5.6 以上で使用できます。詳細は、セクション15.20「InnoDB memcached プラグイン」 を参照してください。 NDB テーブルへの memcached インタフェースは NDB Cluster 7.2 以降で使用できます。詳細は http://dev.mysql.com/doc/ndbapi/en/ndbmemcache.html を参照してください。

InnoDB, NoSQLも参照

MySQL 製品と統合されたときに Connector/J に進化した MySQL 用の古い JDBC ドライバ。

Connector/Jも参照

「「マルチバージョン同時実行性制御」」の頭字語。 この手法により、特定の分離レベルを使用した InnoDB transactions は読取り一貫性操作を実行できます。つまり、他のトランザクションによって更新されている行をクエリーして、それらの更新が発生する前の値を確認できます。 これは、ほかのトランザクションが保持しているロックのために待機することなく、クエリーが進行できるようにすることによって、並列性を高める強力な方法です。

この方法は、データベース世界で共通のものではありません。 ほかのデータベース製品やほかの MySQL ストレージエンジンの中には、これをサポートしないものがあります。

ACID, 並列性, 一貫性読み取り, 分離レベル, ロック, トランザクションも参照

MySQL オプションファイルの名前 (Unix または Linux システムの場合)。

my.ini, オプションファイルも参照

MySQL オプションファイルの名前 (Windows システムの場合)。

my.cnf, オプションファイルも参照

Connector/ODBC の廃止された名前。

Connector/ODBCも参照

mysql プログラムは MySQL データベース用のコマンド行インタープリターです。 SQL ステートメントを処理し、mysqld デーモンにリクエストを渡すことによって SHOW TABLES などの MySQL 固有コマンドも処理します。

mysqld, SQLも参照

MySQL データベースのホットバックアップを実行するライセンス製品。 InnoDB テーブルをバックアップする場合、最も効率的で柔軟性がありますが、MyISAM およびその他の種類のテーブルをバックアップすることもできます。

ホットバックアップ, InnoDBも参照

MySQL Enterprise Backup 製品のコマンド行ツール。 InnoDB テーブルに対してホットバックアップ操作を実行し、MyISAM およびその他の種類のテーブルに対して warm backup を実行します。 このコマンドの詳細は、セクション30.2「MySQL Enterprise Backup の概要」を参照してください。

ホットバックアップ, MySQL Enterprise Backup, ウォームバックアップも参照

ファイル libmysqlclient によって実装されるライブラリの非公式名で、拡張子は .a または .so です。

libmysqlclientも参照

mysqld (MySQL Server とも呼ばれる) は、MySQL インストールでほとんどの作業を実行する単一のマルチスレッドプログラムです。 追加プロセスは生成されません。 MySQL Server は、データベース、テーブル、およびログファイルやステータスファイルなどのその他の情報を含む MySQL データディレクトリへのアクセスを管理します。

mysqld は、Unix デーモンまたは Windows サービスとして実行され、リクエストを常に待機し、バックグラウンドでメンテナンス作業を実行します。

インスタンス, mysqlも参照

MySQL Python API の基礎を形成するオープンソース Python モジュールの名前。

Python, Python APIも参照

データベース、テーブル、およびテーブルデータの組み合わせの論理バックアップを実行するコマンド。 結果は、元のスキーマオブジェクトまたはデータ、あるいはその両方を再現する SQL ステートメントです。 相当な量のデータの場合、MySQL Enterprise Backup などの物理バックアップソリューションが高速です (特にリストア操作で)。

論理バックアップ, MySQL Enterprise Backup, 物理バックアップ, リストアも参照

データ読み書きの主要なメカニズムとして SQL 言語を使用しない、一連のデータアクセステクノロジの一般的な用語。 NoSQL テクノロジの中には、単一値の読み取りと買い込みだけを受け入れるキー値ストアとして機能するものがあります。ACID 原理の制限を緩和するものや、事前に計画されたスキーマが不要なものもあります。 MySQL ユーザーは、memcached API を使用して何らかの MySQL テーブルに直接アクセスすることにより、速度と簡略化のための NoSQL スタイル処理と、柔軟性と利便性のための SQL 操作を組み合わせることができます。 InnoDB テーブルへの memcached インタフェースは、MySQL 5.6 以上で使用できます。詳細は、セクション15.20「InnoDB memcached プラグイン」 を参照してください。 NDB テーブルへの memcached インタフェースは NDB Cluster 7.2 以降で使用できます。ndbmemcache—Memcache API for NDB Cluster (NO LONGER SUPPORTED) を参照してください。

ACID, InnoDB, memcached, スキーマ, SQLも参照

カラムが NULL 値を含むことができないと規定するタイプの制約。 これは、データベースサーバーが誤って値が失われているデータを識別できるので、参照整合性の維持に役立ちます。 また、オプティマイザはそのカラムのインデックス内のエントリ数を予測できるので、クエリー最適化に関係する演算でも役立ちます。

カラム, 制約, NULL, 主キー, 参照整合性も参照

データが存在しないことを示す、SQL での特殊な値。 算術演算や等価性テストに NULL 値が含まれる場合は、それらは NULL 結果を返します。 (したがって、NaN、「「数値ではない」」の IEEE 浮動小数点概念に似ています。) AVG() などの集計計算は、除算の分母となる行数を決定するときに、NULL 値を含む行を無視します。 NULL 値を扱う唯一のテストは、SQL イディオム IS NULL または IS NOT NULL を使用します。

パフォーマンスのために、データベースでは欠落したデータ値を追跡するオーバーヘッドを最小限に抑える必要があるため、NULL の値は index 操作に関与します。 NULL 値は通常、インデックスに格納されません。標準比較演算子を使用してインデックスカラムをテストするクエリーは、そのカラムの行を NULL 値に照合することはできないためです。 同じ理由で、一意のインデックスは NULL 値を防止しません。これらの値は単純にインデックスに表示されません。 カラムで NOT NULL 制約を宣言することで、インデックスから外れる行がないことが再保証され、クエリー最適化が向上します (行数カウントおよびインデックスを使用するかどうかの評価の精度)。

主キーはテーブル内のすべての行を一意に識別できる必要があるので、単一カラム主キーには NULL 値を含めることはできず、複数カラム主キーにはすべてのカラムで NULL 値を持つ行を含めることはできません。

Oracle データベースでは NULL 値を文字列と連結できますが、InnoDB ではこのような操作の結果を NULL として扱います。

インデックス, 主キー, SQLも参照

業界標準の API である Open Database Connectivity の頭字語。 通常、MySQL との通信に ODBC を必要とする Windows ベースのサーバーまたはアプリケーションで使用されます。 MySQL ODBC ドライバは Connector/ODBC と呼ばれます。

Connector/ODBCも参照

「「オンライントランザクション処理」」の頭字語。 データベースシステムまたはデータベースアプリケーションの 1 つ。多数のトランザクション、頻繁な書き込みと読み取りのワークロードを実行し、通常は一度に少量のデータに影響します。 たとえば、航空便予約システムや銀行預金を処理するアプリケーションがあります。 DML (挿入/更新/削除) 効率性とクエリー効率性とのバランスを取るために、データは正規化形式で編成される場合があります。 データウェアハウスと対比してください。

InnoDB は、行レベルロックとトランザクション機能を備え、OLT アプリケーションで使用される MySQL テーブルに理想的なストレージエンジンです。

データウェアハウス, DML, InnoDB, クエリー, 行ロック, トランザクションも参照

MySQL 5.5 までのリリースでは、各 InnoDB page のサイズは 16 キロバイトに固定されています。 この値は、ほとんどの行のデータを保持できる大きさと、不要なデータをメモリーに転送するパフォーマンスオーバーヘッドを最小化できる小ささとを、調和させたものです。 ほかの値は未テストで、サポートされません。

MySQL 5.6 以降、InnoDB instance のページサイズは、innodb_page_size 構成オプションによって制御される 4KB、8KB または 16KB のいずれかになります。 MySQL 5.7.6 では、InnoDB は 32KB および 64KB のページサイズもサポートしています。 32KB および 64KB のページサイズの場合、ROW_FORMAT=COMPRESSED はサポートされず、最大レコードサイズは 16KB です。

ページサイズは、MySQL インスタンスの作成時に設定され、その後は一定のままです。 システムテーブルスペース、file-per-table テーブルスペースおよび一般テーブルスペースを含むすべての InnoDB テーブルスペースに同じページサイズが適用されます。

ページサイズが小さいほど、小さなブロックサイズを使用するストレージデバイス (特に、OLTP アプリケーションなどのディスクバウンドワークロードでの SSD デバイス) のパフォーマンスに役立ちます。 個々の行が更新されるときに、メモリーにコピーされたり、ディスクに書き込まれたり、再編成されたり、ロックされたりするときのデータ量が少なくなります。

ディスクバウンド, file-per-table, 一般テーブルスペース, インスタンス, OLTP, ページ, SSD, システムテーブルスペース, テーブルスペースも参照

Unix スクリプトおよびレポート生成のルートを持つプログラミング言語。 高パフォーマンスの正規表現およびファイル I/O を組み込みます。 CPAN などのリポジトリを介して使用可能な再利用可能なモジュールの大規模なコレクション。

Perl APIも参照

Perl 言語で記述された MySQL アプリケーション用のオープンソース API。 DBI および DBD::mysql モジュールを介して実装されます。 詳細は、セクション29.9「MySQL Perl API」を参照してください。

API, Perlも参照

web アプリケーションからのプログラミング言語。 通常、コードは web ページのソース内にブロックとして埋め込まれ、出力は Web サーバーによって送信されるときにページに置換されます。 これは、web ページ全体の形式で出力を印刷する CGI スクリプトなどのアプリケーションとは対照的です。 PHP 形式のコーディングは、高度に対話型で動的な web ページに使用されます。 最新の PHP プログラムは、コマンドラインまたは GUI アプリケーションとして実行することもできます。

MySQL アプリケーションは、PHP APIs のいずれかを使用して記述されます。 再利用可能なモジュールは、C で記述し、PHP から呼び出すことができます。

MySQL を使用してサーバー側の web ページを作成する別のテクノロジは、ASP.net です。

ASP.net, C, PHP APIも参照

PHP 言語での MySQL アプリケーションの記述には、いくつかの APIs を使用できます: 元の MySQL API (Mysql) である MySQL 拡張機能 (Mysqli) である MySQL ネイティブドライバ (Mysqlnd) によって、MySQL 関数 (PDO_MYSQL) およびコネクタ/PHP が改善されました。 詳細は、MySQL and PHPを参照してください。

API, PHPも参照

ポイントインタイムリカバリ (Point-In-Time Recovery) の頭字語。

ポイントインタイムリカバリも参照

データベースサーバーがリスニングする TCP/IP ソケットの番号で、connection の確立に使用されます。 多くの場合、host と組み合せて指定されます。 ネットワーク暗号化の使用方法によっては、暗号化されていないトラフィック用のポートと SSL 接続用のポートが異なる場合があります。

接続, ホスト, SSLも参照

POSIX スレッド標準。Unix および Linux システムでのスレッド操作およびロック操作用の API を定義します。 Unix および Linux システムでは、InnoDB は mutexes に対してこの実装を使用します。

相互排他ロックも参照

Unix スクリプトから大規模アプリケーションまで、幅広いフィールドで使用されるプログラミング言語。 実行時の型指定、組込みの高レベルデータ型、オブジェクト指向機能、および広範な標準ライブラリが含まれます。 多くの場合、他の言語で記述されたコンポーネント間の 「glue」 言語として使用されます。 MySQL Python API は、オープンソースの MySQLdb モジュールです。

MySQLdb, Python APIも参照

API, Pythonも参照

地理座標、矩形、ポリゴンなどの多次元データの空間インデックス付けに使用されるツリーデータ構造。

B ツリーも参照

「「低コストのドライブの冗長アレイ」」の頭字語。 複数のドライブに I/O 操作を分散することにより、ハードウェアレベルで並列性が向上し、低レベル書き込み操作の効率性が改善します (そうしない場合は順番に実行されます)。

並列性も参照

バイナリログと増分バックアップに反映される変更が適用される前の、MySQL Enterprise Backup 製品によって生成されるバックアップファイルの初期セット。 この段階では、ファイルはリストアする準備ができていません。 これらの変更が適用されたあと、ファイルは準備されたバックアップと呼ばれます。

バイナリログ, ホットバックアップ, ibbackup_logfile, 増分バックアップ, MySQL Enterprise Backup, 準備されたバックアップ, リストアも参照

分離レベルの 1 つ。パフォーマンスを向上させるために、トランザクション間の保護を一部緩和するロック戦略を使用します。 トランザクションは、ほかのトランザクションからのコミットされていないデータを見ることはできませんが、現在のトランザクションが開始したあとに別のトランザクションによってコミットされるデータを見ることはできます。 したがって、トランザクションは不良データを見ることはありませんが、見るデータはある程度ほかのトランザクションのタイミングに依存する場合があります。

この分離レベルのトランザクションが UPDATE ... WHERE または DELETE ... WHERE 操作を実行するときに、ほかのトランザクションは待機が必要な場合があります。 このトランザクションは、ほかのトランザクションを待機させずに SELECT ... FOR UPDATE および LOCK IN SHARE MODE 操作を実行できます。

MySQL 8.0.1 の SELECT ... LOCK IN SHARE MODE は SELECT ... FOR SHARE に置き換わりますが、LOCK IN SHARE MODE は下位互換性のために引き続き使用できます。

ACID, 分離レベル, ロック, REPEATABLE READ, SERIALIZABLE, トランザクションも参照

トランザクション間にもっとも少ない量の保護を提供する分離レベル。 クエリーは、通常は別のトランザクションを待機する状況で進行することを許可されるロック戦略を採用します。 ただし、この追加パフォーマンスには、ほかのトランザクションによって変更されたけれどもまだコミットされていないデータ (ダーティー読み取りと呼ばれます) など、結果の信頼性の低いという犠牲が伴います。 この分離レベルは慎重に使用してください。また、他のトランザクションが同時に実行している内容によっては、結果が一貫していないか再現できない可能性があることに注意してください。 通常、この分離レベルのトランザクションはクエリーのみを実行し、挿入、更新または削除操作は実行しません。

ACID, ダーティー読み取り, 分離レベル, ロック, トランザクションも参照

DML ステートメントによって InnoDB テーブルが変更されたときにredo ログに記録されるレコード単位のデータ。 クラッシュリカバリ中に、不完全なトランザクションによって書き込まれるデータを訂正するために使用されます。 増加し続ける LSN 値は、Redo ログを通過した Redo データの累積量を表します。

クラッシュリカバリ, DML, LSN, Redo ログ, トランザクションも参照

クラッシュリカバリ中に、不完全なトランザクションによって書き込まれるデータを訂正するために使用されるディスクベースデータ構造。 通常の操作では、InnoDB テーブルデータを変更するリクエストがエンコードされます。これは、NoSQL インタフェースを介した SQL ステートメントまたは低レベルの API コールの結果です。 予期しないシャットダウン前にデータファイルの更新を終了していない変更は、自動的に再現されます。

Redo ログはファイルセットとして物理的に表され、通常は ib_logfile0 および ib_logfile1 という名前が付けられます。 Redo ログ内のデータは、該当するレコードの単位でエンコードされます。このデータはまとめて Redo と呼ばれます。 Redo ログをデータが通貨したことは、増加し続ける LSN 値で表されます。 Redo ログの最大サイズは、最初は 4G バイトに制限されていましたが、MySQL 5.6.3 で 512G バイトに上げられています。

Redo ログのディスクレイアウトは、構成オプション innodb_log_file_size、innodb_log_group_home_dir、および (まれに) innodb_log_files_in_group に影響されます。 Redo ログ操作のパフォーマンスは、ログバッファーにも影響されます。これは innodb_log_buffer_size 構成オプションによって制御されます。

クラッシュリカバリ, データファイル, ib_logfile, ログバッファー, LSN, Redo, シャットダウン, トランザクションも参照

バックアップ操作の進行中にバックアップユーティリティが redo ログの生成に失敗した場合に発生する可能性のあるデータ損失を回避するために、redo ログレコードをアーカイブファイルに順次書き込む InnoDB 機能。 詳細は、redo ログのアーカイブを参照してください。

Redo ログも参照

InnoDB のデフォルトの分離レベル。 クエリー対象の行が他の transactions によって変更されないようにするため、反復不可能な読み取りはブロックされますが、phantom の読取りはブロックされません。 トランザクション内のすべてのクエリーが同じスナップショットからのデータを見る、つまりトランザクションが開始した時点のデータを見るように、適度に厳密なロック戦略を使用します。

この分離レベルのトランザクションが UPDATE ... WHERE、DELETE ... WHERE、SELECT ... FOR UPDATE、および LOCK IN SHARE MODE 操作を実行するときに、ほかのトランザクションは待機しなければいけない場合があります。

MySQL 8.0.1 の SELECT ... LOCK IN SHARE MODE は SELECT ... FOR SHARE に置き換わりますが、LOCK IN SHARE MODE は下位互換性のために引き続き使用できます。

ACID, 一貫性読み取り, 分離レベル, ロック, ファントム, トランザクションも参照

動的型付けおよびオブジェクト指向プログラミングを強調するプログラミング言語。 一部の構文は、Perl 開発者によく知られています。 MySQL アプリケーションの開発には、一般的な Ruby APIs が 2 つあります。 (このマニュアルでは、上位レベルの Ruby フレームワークについては説明しません。)

API, Perl, Ruby APIも参照

MySQL アプリケーションを開発する Ruby プログラマは、2 つの API を使用できます。 MySQL/Ruby API は libmysqlclient API ライブラリに基づいています。 Ruby/MySQL API はネイティブ MySQL ネットワークプロトコル (ネイティブドライバ) を使用するために書かれています。 詳細は、セクション29.11「MySQL Ruby API」を参照してください。

libmysql, Rubyも参照

特定のルールに従って、InnoDB が内部インメモリーデータ構造への共有アクセスロックを表現および強制するために使用する低レベルオブジェクト。 InnoDB が内部インメモリーデータ構造への排他的アクセスを表すために使用する mutexes と対比してください。 相互排他ロックと読み書きロックはまとめて、ラッチと呼ばれます。

rw ロックタイプには、s ロック (共有ロック)、x ロック (排他ロック)、および sx ロック (共有排他ロック) などがあります。

次の表に rw ロックタイプ互換性をまとめます。

ラッチ, ロック, 相互排他ロック, パフォーマンススキーマも参照

「「シリアライズされたディクショナリ情報」」の頭字語。

シリアライズディクショナリ情報 (SDI)も参照

最も保守的なロック戦略を使用して、このトランザクションによって読み取られたデータが他の transactions によって挿入または変更されないようにする分離レベル。 この方法では、トランザクション内で同じクエリーを何度も実行でき、そのたびに同じ結果セットを取得することを保証できます。 現在のトランザクションが開始してから別のトランザクションによってコミットされたデータを変更しようとすると、現在のトランザクションは待機します。

これは、SQL 標準で指定されるデフォルト分離レベルです。 実際には、この強度が必要になることはほとんどないため、InnoDB のデフォルトの分離レベルは次に厳しい REPEATABLE READ です。

ACID, 一貫性読み取り, 分離レベル, ロック, REPEATABLE READ, トランザクションも参照

Connector/Jも参照

レプリケーションシナリオでのデータベースサーバーマシンで、データの初期挿入、更新、および削除リクエストを処理します。 これらの変更は、レプリカと呼ばれる他のサーバーに伝播され、繰り返されます。

レプリカ, レプリケーションも参照

コンポーネントを構成する方法を提供することで、アプリケーション設計を支援するために設計された Java ベースのアプリケーションフレームワーク。

J2EEも参照

データベース操作を実行するための標準である構造化クエリー言語。 多くの場合、カテゴリ DDL、DML、およびクエリーに分けられます。 MySQL には、レプリケーションなどのいくつかの追加ステートメントカテゴリが含まれます。 SQL 構文の構成ブロックについては第9章「言語構造」、MySQL テーブルカラムに使用するデータ型については第11章「データ型」、SQL ステートメントとそれらに関連付けられるカテゴリの詳細は第13章「SQL ステートメント」、クエリーで使用する標準および MySQL 固有の関数については第12章「関数と演算子」を参照してください。

DDL, DML, クエリー, レプリケーションも参照

Connector/J を使用するアプリケーションによる例外処理のために、JDBC 標準で定義されているエラーコード。

Connector/J, JDBCも参照

「「ソリッドステートドライブ」」の頭字語。 従来のハードディスクドライブ (HDD) とパフォーマンス特性が異なるタイプのストレージデバイス。ストレージ容量が小さく、ランダム読み取りが高速で、可動部分がなく、書き込みパフォーマンスに影響する考慮事項がいくつかあります。 そのパフォーマンス特性は、ディスクバウンドワークロードのスループットに影響を与えることがあります。

ディスクバウンド, HDDも参照

「「セキュアソケットレイヤー」」の頭字語。 アプリケーションと MySQL データベースサーバー間のネットワーク通信用の暗号化レイヤーを提供します。

keystore, トラストストアも参照

Unix スクリプトワールドからのプログラミング言語。 C、C++ または Java で記述されたコードによって拡張される場合があります。 オープンソース Tcl API for MySQL については、セクション29.12「MySQL Tcl API」 を参照してください。

APIも参照

オープンソースの J2EE アプリケーションサーバー。Java サーブレットおよび JavaServer Pages プログラミングテクノロジを実装します。 web サーバーと Java サーブレットコンテナで構成されます。 MySQL では、通常、Connector/J とともに使用されます。

J2EEも参照

「「transactions/秒」」の頭字語。ベンチマークで使用されることがある測定単位です。 その値は、特定のベンチマークテストで表されるワークロードと、ハードウェア能力やデータベース構成などの制御要因との組み合わせに応じて異なります。

トランザクション, ワークロードも参照

トランザクションの生存期間保持されるデータ。ロールバック操作の場合に元に戻せるようにすべての変更を記録します。 これは、システムテーブルスペース (MySQL 5.7 以前) 内または別のundo テーブルスペース内のundo ログに格納されます。 MySQL 8.0 では、undo ログはデフォルトで undo テーブルスペースに存在します。

ロールバック, ロールバックセグメント, システムテーブルスペース, トランザクション, Undo ログ, Undo テーブルスペースも参照

undo テーブルスペースには、undo ログが含まれます。 undo ログは、ロールバックセグメント内に含まれるundo ログセグメント内に存在します。 ロールバックセグメントは、従来はシステムテーブルスペースに存在していました。 MySQL 5.6 では、ロールバックセグメントは undo テーブルスペースに存在できます。 MySQL 5.6 および MySQL 5.7 では、undo テーブルスペースの数は innodb_undo_tablespaces 構成オプションによって制御されます。 MySQL 8.0 では、MySQL インスタンスの初期化時に 2 つのデフォルト undo テーブルスペースが作成され、CREATE UNDO TABLESPACE 構文を使用して追加の undo テーブルスペースを作成できます。

詳細は、セクション15.6.3.4「undo テーブルスペース」を参照してください。

ロールバックセグメント, システムテーブルスペース, Undo ログ, undo ログセグメントも参照

アクティブトランザクションによって変更されたデータのコピーを保持するストレージ領域。 別のトランザクションが (一貫性読み取り操作の一部として) 元のデータを見る必要がある場合に、未変更データがこのストレージ領域から取得されます。

MySQL 5.6 および MySQL 5.7 では、innodb_undo_tablespaces 変数を使用して、undo テーブルスペースに undo ログを配置できます。これは SSD などの別のストレージデバイスに配置できます。 MySQL 8.0 では、undo ログは MySQL の初期化時に作成されるデフォルトの undo テーブルスペースに存在し、CREATE UNDO TABLESPACE 構文を使用して追加の undo テーブルスペースを作成できます。

Undo ログは、別個の部分、挿入 Undo バッファーと更新 Undo バッファーに分割されます。

一貫性読み取り, ロールバックセグメント, SSD, システムテーブルスペース, トランザクション, Undo テーブルスペースも参照

undo ログのコレクション。 undo ログセグメントはロールバックセグメント内に存在します。 undo ログセグメントには、複数のトランザクションからの undo ログが含まれる場合があります。 undo ログセグメントは、一度に 1 つのトランザクションでのみ使用できますが、トランザクション commit または rollback で解放された後で再利用できます。 「「undo セグメント」」とも呼ばれます。

コミット, ロールバック, ロールバックセグメント, Undo ログも参照

各国語文字、文字セット、コードページおよびその他の国際化の側面を柔軟かつ標準化された方法でサポートするためのシステム。

Unicode サポートは、ODBC 標準の重要な側面です。 Connector/ODBC 5.1 は Unicode ドライバであり、ANSI ドライバである Connector/ODBC 3.51 とは対照的です。

ANSI, Connector/ODBC, ODBCも参照

呼び出されたときに結果セットを生成するストアドクエリー。 ビューは仮想テーブルとして機能します。

サポートされている Visual Studio のバージョンについては、次のリファレンスを参照してください:

Connector/C++, Connector/NETも参照

分散型トランザクションを調整するための標準インタフェース。ACID コンプライアンスを維持しながら、複数のデータベースがトランザクションに参加できます。 詳細は、セクション13.3.8「XA トランザクション」を参照してください。

XA 分散トランザクションのサポートはデフォルトで有効になっています。

ACID, バイナリログ, コミット, トランザクション, 2 フェーズコミットも参照

Connector/NET を介してアクセスされる、.NET システム内のコンパイル済コードのライブラリ。 GAC に格納され、名前の競合なしでバージョニングできるようにします。

.NET, GACも参照

アトミック DDL ステートメントは、DDL 操作に関連付けられたデータディクショナリ更新、ストレージエンジン操作およびバイナリログ書込みを単一のアトミックトランザクションに結合するステートメントです。 操作中にサーバーが停止した場合でも、トランザクションは完全にコミットまたはロールバックされます。 アトミック DDL サポートが MySQL 8.0 で追加されました。 詳細は、セクション13.1.1「アトミックデータ定義ステートメントのサポート」を参照してください。

バイナリログ, データディクショナリ, DDL, ストレージエンジンも参照

重要な低レベル操作を中断できないようにするために、CPU によって提供される特殊な命令。

関数またはプロシージャーのセット。 API は、関数、プロシージャー、パラメータ、および戻り値の名前と型の安定的なセットです。

ソフトウェア製品のパフォーマンス、機能および互換性が non-mission-critical 設定で通常評価される、ベータと同様のステージ。

ベータも参照

使用するディスク領域の縮小、実行する I/O の減少、および使用するキャッシュ用のメモリーの軽減による幅広いメリットを伴う機能。

InnoDB では、テーブルレベルとページレベルの両方の圧縮がサポートされます。 InnoDB のページ圧縮は、透過的ページ圧縮とも呼ばれます。 InnoDB 圧縮の詳細は、セクション15.9「InnoDB のテーブルおよびページの圧縮」 を参照してください。

別の種類の圧縮は、MySQL Enterprise Backup 製品の圧縮バックアップ機能です。

バッファープール, 圧縮バックアップ, 圧縮行フォーマット, DML, 透過的ページ圧縮も参照

データが圧縮形式で格納されたテーブル。 InnoDB の場合、これは ROW_FORMAT=COMPRESSED で作成されたテーブルです。 詳細は、セクション15.9「InnoDB のテーブルおよびページの圧縮」を参照してください。

圧縮行フォーマット, 圧縮も参照

MySQL Enterprise Backup 製品の圧縮機能は、各テーブルスペースの圧縮コピーを作成し、.ibd から .ibz に拡張子を変更します。 バックアップデータを圧縮すると、より多くのバックアップを手元に保持し、バックアップを別のサーバーに転送する時間を短縮できます。 データはリストア操作中に圧縮解除されます。 圧縮バックアップ操作は、すでに圧縮されているテーブルを処理するときに、ふたたび圧縮してもほとんどまたはまったく領域の節約にならないので、そのテーブルの圧縮ステップをスキップします。

MySQL Enterprise Backup 製品が生成するファイルセット。ここでは、各テーブルスペースが圧縮されます。 圧縮ファイルは、.ibz ファイル拡張子を使用して名前が変更されます。

バックアッププロセスの開始時に compression を適用すると、圧縮プロセス中の記憶域のオーバーヘッドを回避し、バックアップファイルを別のサーバーに転送する際のネットワークオーバーヘッドを回避できます。 バイナリログを適用するプロセスはさらに時間がかかるようになり、バックアップファイルの圧縮解除が必要になります。

適用, バイナリログ, 圧縮, ホットバックアップ, MySQL Enterprise Backup, テーブルスペースも参照

実際にはエラーではなくむしろ、圧縮を DML 操作と組み合わせて使用するときに起きる可能性のある負荷のかかる操作です。 これは、圧縮ページへの更新が変更記録に予約されたページ上の領域からオーバーフローするとき、すべての変更がテーブルデータに適用してページが再度圧縮されたとき、再圧縮されたデータが元のページ上で適合せず、MySQL がデータを 2 つの新しいページに分割しそれぞれを個別に圧縮するように要求するときに起こります。 この条件の頻度を確認するには、INFORMATION_SCHEMA.INNODB_CMP テーブルをクエリーして、COMPRESS_OPS カラムの値が COMPRESS_OPS_OK カラムの値を超えているかどうかを確認します。 理想的には、圧縮の失敗は頻繁には発生しません。その場合は、innodb_compression_level、innodb_compression_failure_threshold_pct および innodb_compression_pad_pct_max の構成オプションを調整できます。

圧縮, DML, ページも参照

InnoDB テーブルのデータおよびインデックス圧縮を有効にする行フォーマット。 ラージフィールドは、動的行フォーマットと同様に、残りの行データを保持するページとは別に格納されます。 インデックスページとラージフィールドの両方が圧縮され、メモリーとディスクの節約をもたらします。 データの構造に応じて、メモリーおよびディスク使用量の減少は、使用時にデータを圧縮解除するときのパフォーマンスオーバーヘッドを上回る場合も、上回らない場合もあります。 使用法の詳細は、セクション15.9「InnoDB のテーブルおよびページの圧縮」を参照してください。

InnoDB COMPRESSED 行フォーマットの追加情報については、DYNAMIC 行フォーマットを参照してください。

圧縮, 動的行フォーマット, 行フォーマットも参照

InnoDB バッファプールの page の特性は、最近アクセスされたことを意味し、LRU アルゴリズムによって flushed がすぐに使用されないようにバッファープールのデータ構造内で移動されます。 この用語は、バッファープールに関連するテーブルの一部の INFORMATION_SCHEMA カラム名で使用されます。

バッファープール, フラッシュ, INFORMATION_SCHEMA, LRU, ページも参照

一貫性を確保するために InnoDB が取得する行ロック (特にリクエストしない場合)。

行ロックも参照

単一の mysqld デーモン。テーブルのセットで 1 つ以上のデータベースを表すデータディレクトリを管理します。 同じサーバーマシン上に複数のインスタンスを持ち、それぞれが専用のデータディレクトリを管理し、独自のポートまたはソケットで待機することは、開発、テスト、および一部のレプリケーションシナリオにおいて一般的です。 あるインスタンスがディスクバウンドワークロードを実行している状態でも、サーバーは追加インスタンスを実行するために余分な CPU およびメモリー容量を持つことができます。

データディレクトリ, データベース, ディスクバウンド, mysqld, レプリケーション, サーバー, テーブルも参照

ソースコードレベルでの、チューニングおよびデバッグのパフォーマンスデータを収集するための変更。 MySQL では、インスツルメンテーションによって収集されたデータは、INFORMATION_SCHEMA および PERFORMANCE_SCHEMA データベースを使用して SQL インタフェースを介して公開されます。

INFORMATION_SCHEMA, パフォーマンススキーマも参照

テーブルに適用される lock の一種で、トランザクションがテーブル内の行に対して取得するロックの種類を示すために使用されます。 トランザクションごとに異なる種類のインテンションロックを取得できますが、最初のトランザクションがあるテーブルで インテンション排他 (IX) ロックを獲得すると、ほかのトランザクションはそのテーブルで S または X ロックを獲得できません。 反対に、最初のトランザクションがあるテーブルでインテンション共有 (IS) ロックを獲得すると、ほかのトランザクションはそのテーブルで X ロックを獲得できません。 2 フェーズプロセスは、ロックおよび互換性のある対応操作をブロックせずに、ロックリクエストを順番に解決できます。 このロックメカニズムの詳細は、セクション15.7.1「InnoDB ロック」 を参照してください。

ロック, lock mode, ロック, トランザクションも参照

行の挿入前に INSERT 操作によって設定されるギャップロックのタイプ。 このタイプの lock は、同じインデックスギャップに挿入される複数のトランザクションがギャップ内の同じ位置に挿入されない場合に相互に待機する必要がないような方法で、挿入の意図を示します。 詳細は、セクション15.7.1「InnoDB ロック」を参照してください。

ギャップロック, ロック, ネクストキーロックも参照

テーブルの行を高速ルックアップする機能を提供するデータ構造。通常はこのために、特定のカラムまたはカラムセットのすべての値を表すツリー構造 (B ツリー) を形成します。

InnoDB テーブルには、常に主キーを表すクラスタインデックスがあります。 1 つ以上のカラムに 1 つ以上のセカンダリインデックスを定義することもできます。 セカンダリインデックスは、その構造に応じて、部分、カラム、または複合インデックスとして分類できます。

インデックスは、クエリーパフォーマンスの重要な側面です。 データベースアーキテクトは、アプリケーションが必要とするデータを高速なルックアップできるように、テーブル、クエリー、およびインデックスを設計します。 理想的なデータベース設計では、有用なときはカバリングインデックスを使用します。クエリー結果は、実際のテーブルデータを読み取らずに完全にインデックスから計算されます。 親テーブルと子テーブルの両方に値が存在するかどうかを効率的に確認するために、各外部キー制約にもインデックスが必要です。

B ツリーインデックスは最も一般的ですが、MEMORY ストレージエンジンや InnoDB 適応型ハッシュインデックスのように、ハッシュインデックスには異なる種類のデータ構造が使用されます。 R-tree インデックスは、多次元情報の空間インデックス付けに使用されます。

適応型ハッシュインデックス, B ツリー, 子テーブル, クラスタ化されたインデックス, カラムインデックス, 複合インデックス, カバリングインデックス, 外部キー, ハッシュインデックス, 親テーブル, 部分インデックス, 主キー, クエリー, R-tree, 行, セカンダリインデックス, テーブルも参照

InnoDB 全文検索のトークンデータを保持するメモリー領域。 FULLTEXT インデックスの一部であるカラムでデータが挿入または更新されるときのディスク I/O を最小限に抑えるために、データをバッファリングします。 インデックスキャッシュがいっぱいになると、トークンデータがディスクに書き込まれます。 各 InnoDB FULLTEXT インデックスには独自のインデックスキャッシュがあり、そのサイズは構成オプション innodb_ft_cache_size によって制御されます。

全文検索, FULLTEXT インデックスも参照

オプティマイザが推奨するインデックスをオーバーライドするための拡張 SQL 構文。 たとえば、FORCE INDEX、USE INDEX、および IGNORE INDEX 句。 通常は、インデックス付きカラムに値が不均等に分散されていて、カーディナリティーを正確に見積もれないときに使用されます。

カーディナリティー, インデックスも参照

複数のカラムに適用されるインデックス (複合インデックスと呼ばれます) で、インデックスの先頭または末尾カラム。 複合インデックスの最初の 1、2、3 などのカラムを参照するクエリーはインデックスを使用できます (クエリーがインデックス内のすべてのカラムを参照するわけではない場合でも)。

複合インデックス, インデックスも参照

インデックス条件プッシュダウン (ICP) は、index のフィールドを使用して条件の一部を評価できる場合に、WHERE 条件の一部をストレージエンジンにプッシュダウンする最適化です。 ICP は、ストレージエンジンが実テーブルにアクセスする必要がある回数と、MySQL サーバーがストレージエンジンにアクセスする必要がある回数を減らすことができます。 詳細は、セクション8.2.1.6「インデックスコンディションプッシュダウンの最適化」を参照してください。

インデックス, ストレージエンジンも参照

ディスクブロックとメモリー領域間のディスク I/O および変換によるオーバーヘッドを回避するために、メモリー内にデータを保持するタイプのデータベースシステム。 一部のインメモリーデータベースは耐久性 (ACID 設計理念の 「D」) を犠牲にしており、ハードウェア、電源およびその他のタイプの障害に対して脆弱であるため、読取り専用操作に適しています。 ほかのインメモリーデータベースでは、変更ログをディスクに記録したり不揮発性メモリーを使用したりなどの持続性メカニズムを使用します。

同じ種類のメモリー集中型処理に対処する MySQL 機能には、InnoDB バッファプール、適応型ハッシュインデックスおよび読取り専用トランザクションの最適化、MEMORY ストレージエンジン、MyISAM キーキャッシュおよび MySQL クエリーキャッシュが含まれます。

ACID, 適応型ハッシュインデックス, バッファープール, ディスクベース, 読み取り専用トランザクションも参照

一意制約が適用されるカラムまたはカラムセットのインデックス。 インデックスが重複値を含まないことがわかっているので、特定の種類のルックアップとカウント操作が通常の種類のインデックスよりも効率的になります。 このタイプのインデックスに対するほとんどのルックアップは、単純に特定の値が存在するかどうかを判断することです。 インデックス内の値の数は、テーブル内の行数と同じであるか、関連付けられたカラムが NULL 以外の値である行の数以上です。

バッファリングの変更の最適化は、一意インデックスには適用されません。 回避策として、InnoDB テーブルへのバルクデータロードの実行中に unique_checks=0 を一時的に設定できます。

カーディナリティー, 変更バッファリング, 一意制約, 一意のキーも参照

一意のインデックスを構成するカラムセット (1 つまたは複数)。 正確に 1 行に一致する WHERE 条件を定義でき、クエリーが関連付けられた一意のインデックスを使用できるときは、ルックアップおよびエラー処理を非常に効率的に実行できます。

カーディナリティー, 一意制約, 一意のインデックスも参照

重複値をカラムに含むことができないと表明するタイプの制約。 リレーショナル代数の観点では、1 対 1 関係を指定するために使用されます。 ある値を挿入できるかどうかをチェックするときの効率性のために (つまり、その値がカラムにまだ存在していない)、一意制約が基礎となる一意のインデックスでサポートされます。

制約, リレーショナル, 一意のインデックスも参照

データを真に永続的にする必要がない table。 たとえば、一時テーブルを複雑な計算または変換の中間結果のストレージ領域として使用できます。この中間データはクラッシュ後にリカバリする必要がありません。 データベース製品は、データをディスクに書き込むことや再起動をまたがってデータを保護する手段について緻密さを軽減することで、一時テーブルに対する操作パフォーマンスを手軽に改善できます。

トランザクション終了時やセッション終了時などに、データ自体が所定時に自動的に削除されることもあります。 一部のデータベース製品では、テーブル自体も自動的に削除されます。

テーブルも参照

InnoDB では、2 つのタイプの一時テーブルスペースを使用します。 セッション一時テーブルスペースには、オプティマイザによって作成されたユーザー作成一時テーブルおよび内部一時テーブルが格納されます。 グローバル一時テーブルスペースには、ユーザーが作成した一時テーブルに対して行われた変更のためにロールバックセグメントが格納されます。

グローバル一時テーブルスペース, セッション一時テーブルスペース, 一時テーブルも参照

MySQL Server によって処理された SQL ステートメントの診断およびトラブルシューティングに使用されるタイプのログ。 ファイルまたはデータベーステーブルにも格納できます。 この機能を使用するには、general_log 構成オプションを通じて有効にする必要があります。 sql_log_off 構成オプションを通じて特定の接続に対してこれを無効にできます。

スロークエリーログよりも広い範囲のクエリーを記録します。 レプリケーションに使用されるバイナリログとは異なり、一般クエリーログは SELECT ステートメントを含み、厳密な順序を維持しません。 詳細は、セクション5.4.3「一般クエリーログ」を参照してください。

バイナリログ, ログ, スロークエリーログも参照

CREATE TABLESPACE 構文を使用して作成された共有 InnoDB テーブルスペース。 一般テーブルスペースは、MySQL データディレクトリの外部に作成でき、複数のテーブルを保持でき、すべての行形式のテーブルをサポートします。 一般的なテーブルスペースは、MySQL 5.7.6 で導入されました。

テーブルは、CREATE TABLE tbl_name ... TABLESPACE [=] tablespace_name または ALTER TABLE tbl_name TABLESPACE [=] tablespace_name 構文を使用して一般テーブルスペースに追加されます。

システムテーブルスペースおよび file-per-table テーブルスペースと対比してください。

詳細は、セクション15.6.3.3「一般テーブルスペース」を参照してください。

file-per-table, システムテーブルスペース, テーブル, テーブルスペースも参照

snapshot 情報を使用して、同時に実行されている他のトランザクションによって実行された変更に関係なく、ある時点に基づいてクエリー結果を表示する読取り操作。 照会されるデータが別のトランザクションによって変更されている場合、元のデータは Undo ログの内容に基づいて再構築されます。 この方法は、ほかのトランザクションが終了するのを待機するようにトランザクションを強制することによって、並列性を減少させる可能性のあるいくつかのロック問題を回避します。

REPEATABLE READ 分離レベルでは、スナップショットは最初の読取り操作が実行された時間に基づきます。 READ COMMITTED 分離レベルでは、スナップショットは各読取り一貫性操作の時間にリセットされます。

一貫性読み取りは、InnoDB が READ COMMITTED および REPEATABLE READ 分離レベルで SELECT ステートメントを処理する際のデフォルトモードです。 一貫性読み取りはアクセスするテーブルでロックを設定しないので、テーブルで一貫性読み取りが実行されている間、ほかのセッションはそれらのテーブルを自由に変更できます。

適用可能な分離レベルの技術的な詳細は、セクション15.7.2.3「一貫性非ロック読み取り」を参照してください。

並列性, 分離レベル, ロック, READ COMMITTED, REPEATABLE READ, スナップショット, トランザクション, Undo ログも参照

起動後の一定期間、標準的なワークロードでシステムを実行すること。通常の状況時のようにバッファープールとほかのメモリー領域がいっぱいになります。 このプロセスは、MySQL Server が再起動したり新しいワークロードを課せられたりしたときに、一定時間をかけて自然に発生します。

通常は、複数の実行間で一貫した結果を保証するために、一定期間ワークロードを実行してバッファープールをウォームアップしてから、パフォーマンステストを実行してください。そのようにしない場合、パフォーマンスが最初の実行中に不自然に低くなる場合があります。

MySQL 5.6 では、innodb_buffer_pool_dump_at_shutdown および innodb_buffer_pool_load_at_startup 構成オプションを有効にしてウォームアッププロセスを高速化し、再起動後にバッファープールの内容をメモリーに戻すことができます。 これらのオプションは、MySQL 5.7 ではデフォルトで有効になっています。 セクション15.8.3.6「バッファープールの状態の保存と復元」を参照してください。

バッファープール, ワークロードも参照

データベースの実行中に行われるが、バックアッププロセス中に一部のデータベース操作を制限するバックアップ。 たとえば、テーブルが読み取り専用になることがあります。 ビジー状態のアプリケーションおよび web サイトの場合は、ホットバックアップを使用することをお薦めします。

バックアップ, コールドバックアップ, ホットバックアップも参照

埋込み MySQL サーバーライブラリ (libmysqld) を使用すると、client アプリケーション内でフル機能の MySQL サーバーを実行できます。 この主なメリットは組み込みアプリケーションの速度の向上と管理の単純化です。

クライアント, libmysqldも参照

テーブルスペース内のページのグループ。 デフォルトのページサイズが 16KB の場合、エクステントには 64 ページが含まれます。 MySQL 5.6 では、InnoDB インスタンスのページサイズには 4K バイト、8K バイト、16K バイトがあり、innodb_page_size 構成オプションで制御されます。 4K バイト、8K バイト、および 16K バイトのページサイズでは、エクステントサイズは常に 1M バイト (つまり 1048576 バイト) です。

32K バイトおよび 64K バイトの InnoDB ページサイズのサポートが MySQL 5.7.6 で追加されました。 32K バイトページサイズの場合、エクステントサイズは 2M バイトです。 64K バイトページサイズの場合、エクステントサイズは 4M バイトです。

セグメント、先読みリクエスト、および二重書き込みバッファーなどの InnoDB 機能は、一度に 1 つのエクステントでデータの読み取り、書き込み、割り当て、または解放を行う I/O 操作を使用します。

二重書き込みバッファー, ページ, page size, 先読み, セグメント, テーブルスペースも参照

キャッシュまたはその他の一時記憶域 (InnoDB バッファプールなど) からアイテムを削除するプロセス。 常にではないけれども多くの場合、LRU アルゴリズムを使用して、削除する項目を決定します。 ダーティページが削除されると、その内容は flushed からディスクになり、使用済のネイバーページもフラッシュされる可能性があります。

バッファープール, ダーティーページ, フラッシュ, LRU, 隣接ページも参照

MySQL 起動に関する情報と、重要な実行時エラーおよびクラッシュ情報を示すタイプのログ。 詳細は、セクション5.4.2「エラーログ」を参照してください。

クラッシュ, ログも参照

InnoDB テーブルの index 統計をディスクに格納し、クエリーのプランスタビリティを向上させる機能。 詳細は、セクション15.8.10.1「永続的オプティマイザ統計のパラメータの構成」を参照してください。

インデックス, オプティマイザ, 計画安定性, クエリー, テーブルも参照

長すぎるため B ツリーページに収まらない可変長データを含むカラム (BLOB や VARCHAR など)。 データはオーバーフローページに格納されます。 DYNAMIC の行形式は、古い COMPACT の行形式よりもこのような記憶域の方が効率的です。

B ツリー, コンパクト行フォーマット, 動的行フォーマット, オーバーフローページも参照

MySQL の構成パラメータ。オプションファイルに格納されるか、コマンド行で渡されます。

InnoDB テーブルに適用される options の場合、各オプション名は接頭辞 innodb_で始まります。

InnoDB, オプション, オプションファイルも参照

MySQL インスタンスの構成オプションを保持するファイル。 従来、Linux および Unix では、このファイルの名前は my.cnf で、Windows では my.ini です。

構成ファイル, my.cnf, my.ini, オプションも参照

該当するテーブルの特性とデータ分布に基づいて、クエリーに使用する最適なインデックスおよび結合順序を決定する MySQL コンポーネント。

インデックス, 結合, クエリー, テーブルも参照

リレーショナルデータベースシステムの低レベル実装決定を導く概念。 リレーショナルデータベースでパフォーマンスと並列性が必要であることは、操作を迅速に開始またはディスパッチする必要があることを意味します。 一貫性と参照整合性が必要であることは、どの操作も失敗する可能性があることを意味します。つまり、トランザクションがロールバックされ、DML 操作が制約を違反し、ロックのリクエストがデッドロックになり、ネットワークエラーがタイムアウトになる可能性があります。 オプティミスティック戦略は、ほとんどのリクエストまたは試行が成功したことを前提としているため、失敗ケースを準備するために比較的少ない作業が行われます。 この想定が true のときは、データベースは不要な作業をほとんど行いません。リクエストが失敗したときは、変更をクリーンアップして元に戻すために追加作業が必要になります。

InnoDB では、ロック、commits などの操作にオプティミスティック戦略を使用します。 たとえば、トランザクションによって変更されたデータは、コミットが発生する前にデータファイルに書き込むことができるため、コミット自体は非常に速いですが、トランザクションがロールバックされた場合に変更を元に戻すためにより多くの作業が必要です。

オプティミスティック戦略の反対がペシミスティック戦略で、信頼性が低く頻繁に失敗する操作に対応するようにシステムが最適化されます。 この概念はデータベースシステムではまれです。信頼性の高いハードウェア、ネットワーク、およびアルゴリズムを選択することに非常の多くの努力が注ぎ込まれるためです。

コミット, 並列性, DML, ロック, ペシミスティック, 参照整合性も参照

データベースのダウンタイム、ブロック、または制限された操作のないタイプの操作。 通常は DDL に適用されます。 高速インデックス作成など、制限された操作の期間を短かくする操作は、MySQL 5.6 で 幅広いオンライン DDL 操作セットに進化しました。

バックアップのコンテキストでは、ホットバックアップはオンライン操作、ウォームバックアップは部分的にオンライン操作です。

DDL, 高速インデックス作成, ホットバックアップ, オンライン DDL, ウォームバックアップも参照

DDL(主に ALTER TABLE) 操作中の InnoDB テーブルのパフォーマンス、同時実行性および可用性を向上させる機能。 詳細は、セクション15.12「InnoDB とオンライン DDL」を参照してください。

詳細は、操作の種類に応じて異なります。 場合によっては、ALTER TABLE の進行中にテーブルを同時に変更できます。 操作は、テーブルコピーなしで実行することも、特別に最適化されたタイプのテーブルコピーを使用して実行することもできます。 インプレース操作の DML ログ領域使用量は、innodb_online_alter_log_max_size 構成オプションによって制御されます。

この機能は、MySQL 5.5 の高速インデックス作成機能の拡張です。

DDL, 高速インデックス作成, オンラインも参照

可変長カラム (BLOB や VARCHAR など) が長すぎて B ツリーページに収まらない場合に、それらを保持するために別個に割り当てられたディスクページ。 関連付けられたカラムはオフページカラムと呼ばれます。

B ツリー, オフページカラム, ページも参照

特定の種類の InnoDB 操作によって増分される値。 サーバーがどれだけビジーかを測定する、パフォーマンス問題の原因をトラブルシューティングする、(たとえば、クエリーが使用する構成設定またはインデックスへの) 変更が目的の低レベル効果を持っているかどうかをテストする場合に役立ちます。 パフォーマンススキーマテーブルおよび INFORMATION_SCHEMA テーブル (特に INFORMATION_SCHEMA.INNODB_METRICS) では、様々な種類のカウンタを使用できます。

INFORMATION_SCHEMA, メトリックカウンタ, パフォーマンススキーマも参照

クエリーによって取得されたすべてのカラムを含むインデックス。 完全なテーブル行を見つけるためのポインタとしてインデックス値を使用する代わりに、クエリーはインデックス構造から値を返し、ディスク I/O を節約します。 InnoDB セカンダリインデックスには主キーカラムも含まれているため、InnoDB では、MyISAM で可能なより多くのインデックスにこの最適化手法を適用できます。 InnoDB では、トランザクションが終了するまで、トランザクションによって変更されたテーブルに対するクエリーにこの方法を適用できません。

正しいクエリーの場合、どのカラムインデックスまたは複合インデックスでも、カバリングインデックスとして機能できます。 可能な場合は必ず、この最適化方法を活用するようにインデックスおよびクエリーを設計してください。

カラムインデックス, 複合インデックス, インデックス, 主キー, セカンダリインデックスも参照

ストレージおよびセマンティクスがデータ型によって定義される、行内のデータ項目。 それぞれのテーブルおよびインデックスは主に、そこに含まれるカラムセットによって定義されます。

それぞれのカラムにはカーディナリティー値があります。 カラムは、そのテーブルの主キーであったり、主キーの一部であったりします。 カラムは、一意制約または NOT NULL 制約、あるいはその両方により制限される場合があります。 別のカラム内の値には、異なるテーブルにまたがっている場合でも、外部キー関係によってリンクできます。

MySQL 内部操作についてディスカッションするときに、シノニムとしてフィールドが使用されることがあります。

カーディナリティー, 外部キー, インデックス, NOT NULL 制約, 主キー, 行, テーブル, 一意制約も参照

単一カラムのインデックス。

複合インデックス, インデックスも参照

index が長さ指定 (CREATE INDEX idx ON t1 (c1(N)) など) で作成されると、カラム値の最初の N 文字のみがインデックスに格納されます。 インデックスプリフィクスを小さいまま維持すると、インデックスがコンパクトになり、メモリーとディスク I/O の節約によりパフォーマンスが向上します。 (ただし、インデックスプリフィクスを小さくし過ぎると、値の異なる行がクエリーオプティマイザには重複していると見えるようになり、クエリー最適化を妨げる可能性があります。)

バイナリ値や長いテキスト文字列を含むカラムの場合、ソートは主な考慮事項ではなく、値全体をインデックスに格納すると領域が浪費されるので、インデックスは自動的に、最初の N (通常 768) 文字を使用してルックアップおよびソートを行います。

インデックスも参照

SQL ステートメントの結果セットを表す内部 MySQL データ構造。 多くの場合、プリペアドステートメントおよび動的 SQLで使用されます。 これは、ほかの高級言語でのイテレータのように機能し、リクエストに応じて結果セットからそれぞれの値を生成します。

通常、SQL はカーソルの処理を処理しますが、パフォーマンスが重視されるコードを処理する際には、内部の作業に深刻になる可能性があります。

動的 SQL, プリペアドステートメント, クエリーも参照

テーブルカラム内の異なる値の数。 インデックスが関連付けられたカラムをクエリーが参照するときに、各カラムのカーディナリティーはどのアクセス方法がもっとも効率的かに影響します。 たとえば、一意制約が適用されるカラムの場合、異なる値の数はテーブル内の行数に等しくなります。 テーブル内の行数が 100 万なのに、特定のカラムの異なる値が 10 個だけの場合は、各値は (平均) 100,000 回発生します。 したがって、SELECT c1 FROM t1 WHERE c1 = 50; などのクエリーが 1 行を返したり非常に多数の行を返したりする可能性があり、データベースサーバーはこのクエリーを c1 のカーディナリティーに応じてさまざまに処理できます。

カラム内の値が非常に不規則に分布している場合は、カーディナリティーが最善のクエリー計画を決定するうえで適切な方法でないことがあります。 たとえば、SELECT c1 FROM t1 WHERE c1 = x; は x=50 のときに 1 行を返し、x=30 のときに 100 万行を返します。 このような場合、どのルックアップ方法が特定のクエリーにより効率的かについてアドバイスを伝えるために、インデックスヒントを使用する必要があります。

カーディナリティーは、複合インデックスの場合と同様に、複数のカラムに存在する異なる値の数にも適用できます。

カラム, 複合インデックス, インデックス, インデックスヒント, 永続的統計, ランダムダイブ, 選択性, 一意制約も参照

仮想インデックスは、1 つ以上の仮想生成カラム上、または仮想生成カラムと通常のカラムまたは格納された生成カラムの組合せ上のセカンダリインデックスです。 詳細は、セクション13.1.20.9「セカンダリインデックスと生成されたカラム」を参照してください。

セカンダリインデックス, ストアド生成カラム, 仮想生成カラムも参照

カラム定義に含まれる式から値が計算されるカラム。 カラム値は格納されませんが、BEFORE トリガーの直後に行が読み取られたときに評価されます。 仮想生成カラムは記憶域を取りません。 InnoDB では、仮想生成カラムのセカンダリインデックスがサポートされます。

ストアド生成カラムと対比してください。

ベースカラム, 生成されるカラム, ストアド生成カラムも参照

可変長のデータ型。 VARCHAR、VARBINARY、BLOB および TEXT 型は可変長型です。

InnoDB では、768 バイト以上の固定長フィールドは可変長フィールドとして扱われ、off-page に格納できます。 たとえば、utf8mb4 と同様に、文字セットの最大バイト長が 3 より大きい場合、CHAR(255) カラムは 768 バイトを超えることがあります。

オフページカラム, オーバーフローページも参照

ホストでの障害 (MySQL、オペレーティングシステム、ハードウェア、メンテナンス作業での障害を含む) に対処し、必要に応じてリカバリする能力 (ない場合は、ダウンタイムが発生する可能性があります)。 多くの場合、大規模開発の重要な側面として、スケーラビリティーと組み合わされます。

スケーラビリティーも参照

個別の InnoDB テーブルの行間のポインタ関係のタイプ。 外部キー関係は、親テーブルおよび子テーブルの 1 つのカラムに定義されます。

外部キーは、関連情報の高速ルックアップを有効にすることに加えて、データが挿入、更新、および削除されるときにこれらのポインタが無効になるのを防ぐことによって参照整合性を適用するのに役立ちます。 この適用メカニズムは一種の制約です。 別のテーブルをポイントする行は、関連付けられた外部キー値がその別のテーブルに存在しない場合、挿入できません。 行が削除されているか、その外部キー値が変化していて、別のテーブル内の行がその外部キー値をポイントしている場合は、削除を防止したり、ほかのテーブル内の対応するカラム値が NULL になるようにしたり、ほかのテーブル内の対応する行を自動的に削除したりするように外部キーを設定できます。

正規化データベースを設計する際の段階の 1 つは、複製されるデータを特定し、そのデータを新しいテーブルに分離し、結合操作を使用して複数のテーブルを単一テーブルのように照会できるように外部キー関係を設定することです。

子テーブル, FOREIGN KEY 制約, 結合, 正規化, NULL, 親テーブル, 参照整合性, リレーショナルも参照

各 MySQL データベース内のすべてのテーブルと MySQL インスタンス内のすべてのデータベースを含むバックアップ。 部分バックアップと対比してください。

バックアップ, データベース, インスタンス, 部分バックアップ, テーブルも参照

ダーティページが InnoDB バッファプールの flushed である場合に書込み操作を減らす最適化手法。 ページ内の行が複数回更新されたり、同じページ上の複数の行が更新されたりする場合、変更ごとに一度の書き込みではなく、単一書き込み操作でこれらのすべての変更がデータファイルに格納されます。

バッファープール, ダーティーページ, フラッシュも参照

全文検索機能で、検索文字列と FULLTEXT インデックス内のデータとの間の類似性を示す数字。 たとえば、単一の単語を検索する場合、その単語は通常、1 回のみ表示される行よりもテキスト内で複数回出現する行に関連します。

全文検索, FULLTEXT インデックスも参照

頻繁または高速に取り出せるようにデータのコピーを格納するメモリー領域を表す一般的な用語。 InnoDB では、キャッシュ構造の主な種類はバッファプールです。

バッファー, バッファープールも参照

新しい値を挿入できる InnoDB index データ構造内の場所。 SELECT ... FOR UPDATE などのステートメントを使用して行のセットをロックすると、InnoDB ではギャップおよびインデックス内の実際の値に適用されるロックを作成できます。 たとえば、更新に 10 より大きな値をすべて選択した場合、ギャップロックはほかのトランザクションが 10 を超える新しい値を挿入するのを妨げます。 最小上限レコードと最大下限レコードは、現在のすべてのインデックス値よりも大きな値または小さな値をすべて含むギャップを表します。

並列性, ギャップロック, インデックス, 最大下限レコード, 分離レベル, 最小上限レコードも参照

インデックスレコード間のギャップのロック、または先頭インデックスレコードの前や末尾インデックスレコードのあとのギャップのロック。 たとえば、SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE;では、範囲内の既存のすべての値間のギャップがロックされているため、カラムにそのような値がすでに存在するかどうかにかかわらず、他のトランザクションが 15 の値を t.c1 カラムに挿入することを防ぎます。 レコードロックおよびネクストキーロックと対比してください。

ギャップロックは、パフォーマンスと並列性とのトレードオフの一環であり、一部のトランザクション分離レベルで使用され、ほかでは使用されません。

ギャップ, 最大下限レコード, ロック, ネクストキーロック, レコードロック, 最小上限レコードも参照

システムテーブルスペースまたは一般テーブルスペースを参照する別の方法。 一般的なテーブルスペースは、MySQL 5.7 で導入されました。 複数のテーブルを共有テーブルスペースに配置できます。 単一のテーブルのみが file-per-table テーブルスペースに存在できます。

一般テーブルスペース, システムテーブルスペースも参照

ロックの一種。ほかのトランザクションがロックされたオブジェクトを読み取ることを許可し、それに対するほかの共有ロックを獲得することも許可するけれども、それに書き込むことは許可しません。 排他ロックの反対。

排他ロック, ロック, トランザクションも参照

テーブルおよび関連するインデックスを残しながら、テーブルの内容全体を削除する DDL 操作。 ドロップと対比してください。 概念的には、WHERE 句のない DELETE ステートメントと同じ結果になりますが、バックグラウンドでの動作は異なります: InnoDB は新しい空のテーブルを作成し、古いテーブルを削除してから、古いテーブルのかわりに新しいテーブルの名前を変更します。 これは DDL 操作なので、ロールバックできません。

切り捨てられるテーブルに、別のテーブルを参照する外部キーが含まれている場合、切捨て操作では、ON DELETE CASCADE 句で必要に応じて参照テーブルの対応する行を削除できるように、処理速度の遅い行を一度に削除します。 (MySQL 5.5 以降では、このより遅い形式の切り捨てを許可しない代わりに、外部キーが含まれている場合はエラーを返します。 この場合は、代わりに DELETE ステートメントを使用してください。

DDL, ドロップ, 外部キー, ロールバックも参照

現在存在しないキー値または範囲をロックするために使用される、インデックス内の人為レコード。

最大下限レコード, ロック, 最小上限レコードも参照

MySQL Server を起動させるプロセス。 通常、セクション4.3「サーバーおよびサーバーの起動プログラム」に示すプログラムのいずれかによって行われます。 シャットダウンの反対。

シャットダウンも参照

MySQL SQL ステートメント内の識別子は、特殊文字または予約語を含んでいる場合、逆引用符文字 (`) で囲む必要があります。 たとえば、FOO#BAR というテーブルまたは SELECT というカラムを参照するには、`FOO#BAR` および `SELECT` として識別子を指定します。 逆引用符は、安全性のレベルをさらに高めるので、識別子名が前もってわかっていない可能性のあるプログラム生成の SQL ステートメントで広く使用されています。

ほかのデータベースシステムの多くでは、このような特別な名前には二重引用符 (") を使用します。 MySQL では移植性のために、ANSI_QUOTES モードを有効にして、逆引用符の代わりに二重引用符を使用して識別子名を修飾できます。

SQLも参照

SQL で、1 つ以上のテーブルから情報を読み取る操作。 データの編成とクエリーのパラメータに応じて、ルックアップはインデックスを参照することで最適化される可能性があります。 複数のテーブルが使用される場合、そのクエリーは結合と呼ばれます。

歴史的な理由から、ステートメントの内部処理のディスカッションでは、DDL ステートメントや DML ステートメントなどの他のタイプの MySQL ステートメントを含む、より広範な意味で 「query」 が使用される場合があります。

DDL, DML, インデックス, 結合, SQL, テーブルも参照

使用するインデックスやテーブルを結合する順序など、クエリーをもっとも効率的に実行する方法についてオプティマイザによって行われる決定のセット。 計画安定性には、特定のクエリーについて一貫して行われている同じ選択が含まれます。

インデックス, 結合, 計画安定性, クエリーも参照

データベースサーバーの外部で実行され、Connector を介してリクエストを送信してデータベースと通信するプログラム、またはクライアントライブラリを介して使用可能になった API。 データベースサーバーと同じ物理マシン上、またはネットワーク経由で接続されたリモートマシン上で実行できます。 これは、特別な目的のデータベースアプリケーション、または mysql コマンドラインプロセッサなどの汎用プログラムです。

API, クライアントライブラリ, コネクタ, mysql, サーバーも参照

データベースを操作するための関数のコレクションを含むファイル。 これらのライブラリを使用してプログラムをコンパイルするか、アプリケーションと同じシステムにインストールすることで、MySQL サーバーがインストールされていないマシンでデータベースアプリケーション (client と呼ばれる) を実行できます。アプリケーションはネットワークを介してデータベースにアクセスします。 MySQL では、MySQL サーバー自体から libmysqlclient ライブラリを使用できます。

クライアント, libmysqlclientも参照

キャッシュおよび再利用がローカルで管理され、サーバー側のプリペアドステートメントの機能をエミュレートするプリペアドステートメントのタイプ。 従来は、一部の Connector/J、Connector/ODBC および Connector/PHP 開発者がサーバー側ストアドプロシージャの問題を回避するために使用していました。 最新の MySQL サーバーバージョンでは、パフォーマンス、スケーラビリティー、およびメモリー効率を向上させるために、サーバー側のプリペアドステートメントをお勧めします。

Connector/J, Connector/ODBC, Connector/PHP, プリペアドステートメントも参照

主キーインデックスの InnoDB 用語。 InnoDB テーブルの記憶域は、主キーカラムの値に基づいて編成され、主キーカラムに関連するクエリーおよびソートを高速化します。 パフォーマンスが最適になるように、パフォーマンスがもっとも重要なクエリーに基づいて、主キーカラムを慎重に選択してください。 クラスタ化されたインデックスのカラムを変更することは負荷のかかる操作なので、まれにしか、またはまったく更新されない主カラムを選択してください。

Oracle Database 製品では、この種のテーブルはインデックス編成テーブルと呼ばれています。

インデックス, 主キー, セカンダリインデックスも参照

MySQL では、通常、「crash」 という用語は、サーバーが通常のクリーンアップを実行できない予期しない shutdown 操作を指します。 たとえば、クラッシュは、データベースサーバーマシンまたはストレージデバイスでのハードウェア障害、電源障害、MySQL Server の停止を招く潜在的なデータ不一致、DBA で開始された高速シャットダウン、またはその他の多くの理由によって発生することがあります。 InnoDB テーブルの堅牢で自動的なクラッシュリカバリは、DBA が追加作業を行うことなく、サーバーが再起動するときにデータの一貫性を保証します。

クラッシュリカバリ, 高速シャットダウン, InnoDB, シャットダウンも参照

クラッシュ後に MySQL が再度起動したときに行われるクリーンアップアクティビティー。 InnoDB テーブルの場合、不完全なトランザクションからの変更は、Redo ログからのデータを使用して再現されます。 クラッシュ前にコミットされたけれども、まだデータファイルに書き込まれていない変更は、二重書き込みバッファーから再構築されます。 通常どおりデータベースがシャットダウンした場合、このタイプのアクティビティーは、パージ操作によってシャットダウン中に実行されます。

通常操作中、コミットされたデータは、データファイルに書き込まれる前に、一定期間変更バッファーに格納できます。 データファイルを最新の状態に維持すること (通常の操作中にパフォーマンスオーバーヘッドをもたらす) と、データのバッファリング (シャットダウンおよびクラッシュリカバリの時間を長くする可能性がある) との間には、常にトレードオフがあります。

変更バッファー, コミット, クラッシュ, データファイル, 二重書き込みバッファー, InnoDB, パージ, Redo ログも参照

crash または高速シャットダウンではなく、エラーなしで完了し、終了前にすべての変更を InnoDB テーブルに適用する shutdown。 低速シャットダウンのシノニム。

クラッシュ, 高速シャットダウン, シャットダウン, 低速シャットダウンも参照

InnoDB バッファプール内の page は、メモリー内で行われたすべての変更も data files に書き込まれます (flushed)。 ダーティーページの反対です。

バッファープール, データファイル, ダーティーページ, フラッシュ, ページも参照

コミットごとに別々にフラッシュおよび同期するのではなく、一連のコミット操作に対して一度、いくつかの低レベル I/O 操作 (ログ書き込み) を実行する InnoDB 最適化。

バイナリログ, コミットも参照

XA 操作に含まれるタイプのトランザクション。 これは、それ自体はトランザクションであるけれども、すべてがグループとして正しく完了する必要があるか、グループとしてロールバックされる必要がある、いくつかのアクションから構成されます。 基本的に、これは ACID プロパティ「「レベルを上げる」」を拡張して、ACID プロパティも持つグローバル操作のコンポーネントとして複数の ACID トランザクションを同時に実行できるようにします。

ACID, トランザクション, XAも参照

ユーザーが作成した一時テーブルに加えた変更のためにロールバックセグメントを格納する一時テーブルスペース。

一時テーブルスペースも参照

MySQL 内の組み込みの InnoDB ストレージエンジンは、ストレージエンジンの元の配布形式です。 InnoDB Plugin と対比してください。 MySQL 5.5 以降、InnoDB プラグインは組込み InnoDB ストレージエンジン (InnoDB 1.1 と呼ばれる) として MySQL コードベースにマージされます。

この区別は主に MySQL 5.1 で重要です。この場合、機能またはバグの修正が InnoDB プラグインに適用される可能性がありますが、組込み InnoDB には適用されません。その逆も同様です。

InnoDBも参照

オプティマイザで使用される最適化された内部 InnoDB 一時テーブル。

オプティマイザも参照

カラムセットによって定義される論理データ構造。 行セットがテーブルを構成します。 InnoDB データファイル内では、各 page に 1 つ以上の行を含めることができます。

InnoDB では、MySQL 構文との一貫性のために行フォーマットという用語を使用しますが、行形式は各テーブルのプロパティであり、そのテーブルのすべての行に適用されます。

カラム, データファイル, ページ, 行フォーマット, テーブルも参照

InnoDB table の rows のディスク記憶域形式。 InnoDB が compression などの新機能を取得すると、新しい行形式が導入され、記憶域の効率とパフォーマンスが向上します。

InnoDB テーブルの行形式は、ROW_FORMAT オプションまたは innodb_default_row_format 構成オプション (MySQL 5.7.9 で導入) によって指定されます。 行フォーマットには、REDUNDANT, COMPACT, COMPRESSED および DYNAMIC が含まれます。 InnoDB テーブルの行形式を表示するには、SHOW TABLE STATUS ステートメントを発行するか、INFORMATION_SCHEMA で InnoDB テーブルメタデータをクエリーします。

コンパクト行フォーマット, 圧縮行フォーマット, 圧縮, 動的行フォーマット, 冗長行フォーマット, 行, テーブルも参照

レプリカ上の個々の行の変更方法を指定する source からイベントが伝播されるレプリケーションの形式。 innodb_autoinc_lock_mode オプションのすべての設定に安全に使用できます。

自動インクリメントロック, innodb_autoinc_lock_mode, レプリカ, レプリケーション, source, ステートメントベースレプリケーションも参照

InnoDB テーブルに使用されるロックメカニズム。テーブルロックではなく行ロックに依存します。 複数のトランザクションが同時に同じテーブルを変更できます。 2 つのトランザクションが同じ行を変更しようとした場合にのみ、トランザクションの一方は他方が終わる (およびその行ロックを解放する) まで待機します。

InnoDB, ロック, 行ロック, テーブルロック, トランザクションも参照

ロックの 1 つ。互換性のない方法で別のトランザクションが行にアクセスするのを防ぎます。 同じテーブル内のほかの行には、ほかのトランザクションが自由に書き込むことができます。 これは、InnoDB テーブルでの DML 操作によって行われるタイプのロックです。

MyISAM で使用されるテーブルロックとは対照的に、またはオンライン DDLでは実行できない InnoDB テーブルに対する DDL 操作中には、これらのロックによってテーブルへの同時アクセスがブロックされます。

DDL, DML, InnoDB, ロック, ロック, オンライン DDL, テーブルロック, トランザクションも参照

SQL コンテキストでは、トランザクションとは、完全に完了する (コミット時)、またはまったく効果がない (ロールバック時) 作業の単位です。 トランザクションの不可視 (アトミック) プロパティは、頭字語 ACID の 「A」 です。

ACID, コミット, ロールバック, トランザクションも参照

innodb_strict_mode オプションで制御される設定の一般名。 この設定をオンにすると、通常は警告として扱われる条件がエラーと見なされます。 たとえば、通常は警告を生成してデフォルト値で続行するファイル形式と行フォーマットに関連するオプションの特定の無効な組合せによって、CREATE TABLE 操作が失敗するようになりました。innodb_strict_mode は MySQL 5.7 でデフォルトで有効になっています。

MySQL にも厳密モードと呼ばれるものがあります。 セクション5.1.11「サーバー SQL モード」を参照してください。

ファイル形式, innodb_strict_mode, 行フォーマットも参照

MySQL では、全文検索クエリーは特別な種類のインデックス (FULLTEXT インデックス) を使用します。 MySQL 5.6.4 以降で、InnoDB および MyISAM テーブルの両方は FULLTEXT インデックスをサポートします。以前はこれらのインデックスは MyISAM テーブルでのみ利用可能でした。

全文検索, FULLTEXT インデックスも参照

同じ値を保持するテーブル内のカラムを参照することによって、複数のテーブルからデータを取得するクエリー。 理想的には、これらのカラムは InnoDB 外部キー関係の一部であり、参照整合性および結合カラムがインデックス付きであることを確認します。 多くの場合、正規化データ設計で、繰り返される文字列を数値 ID に置き換えることによって領域を節約してクエリーパフォーマンスを改善するために、使用されます。

外部キー, インデックス, 正規化, クエリー, 参照整合性も参照

クエリー実行計画のプロパティーの 1 つ。オプティマイザが渡されたクエリーに毎回同じ選択を行うことで、パフォーマンスが一貫して予測可能になります。

クエリー, クエリー実行計画も参照

MySQL コネクタは、client プログラム用の MySQL サーバーへの接続を提供します。 いくつかのプログラミング言語およびフレームワークには、それぞれ独自のコネクタが関連付けられています。 API によって提供される下位レベルのアクセスと対比してください。

API, クライアント, Connector/C++, Connector/J, Connector/NET, Connector/ODBCも参照

ステートメントインターセプタと同義です。 Connector/NET と Connector/J の両方で使用可能な interceptor デザインパターンの一部分。 Connector/NET がコマンドをコールする内容。Connector/J はステートメントと呼ばれます。 例外インターセプタと対比してください。

Connector/J, Connector/NET, 例外インターセプタ, interceptor, ステートメントインターセプタも参照

トランザクションを終了させ、トランザクションによって行われた変更を永続的にする SQL ステートメント。 これは、トランザクションで行われた変更を元どおりにするロールバックの反対です。

InnoDB では、コミットに optimistic メカニズムを使用するため、コミットが実際に発生する前に変更をデータファイルに書き込むことができます。 この方法は、コミット自体をより高速にしますが、ロールバックの場合には必要な作業が増えるというトレードオフが生じます。

MySQL はデフォルトで、各 SQL ステートメントに続いてコミットを自動的に発行する自動コミット設定を使用します。

自動コミット, オプティミスティック, ロールバック, SQL, トランザクションも参照

InnoDB テーブル用の行フォーマット。 これは、MySQL 5.0.3 から MySQL 5.7.8 へのデフォルトの行形式でした。 MySQL 8.0 では、デフォルトの行フォーマットは、DYNAMIC のデフォルト設定を持つ innodb_default_row_format 構成オプションによって定義されます。 COMPACT の行形式では、REDUNDANT の行形式よりも NULL および可変長のカラムをよりコンパクトに表現できます。

InnoDB COMPACT 行フォーマットの詳細は、セクション15.10「InnoDB の行フォーマット」を参照してください。

動的行フォーマット, ファイル形式, 冗長行フォーマット, 行フォーマットも参照

データベースがシャットダウンしている間に行われるバックアップ。 ビジー状態のアプリケーションおよび web サイトの場合、これは実用的ではなく、ウォームバックアップまたはホットバックアップが望ましい場合があります。

バックアップ, ホットバックアップ, ウォームバックアップも参照

インデックス付けされたカラム (通常は主キー)。値は任意に割り当てられます。 多くの場合、自動インクリメントカラムを使用して行われます。 完全に任意として値を扱うことによって、過度に制限されたルールと欠陥のあるアプリケーション想定を回避できます。 たとえば、ある従業員が雇用を承認されたけれども、実際には入社していない場合、従業員数を表す数値シーケンスにギャップがある可能性があります。 または、従業員番号 100 と従業員番号 500 が会社を退職してあとで再入社した場合、前者が後者よりもあとの雇用日になることがあります。 数値も、予測可能な長さより短い値になります。 たとえば、「Road」、「Boulevard」、「Expressway」 などを意味する数値コードを格納すると、これらの文字列を繰り返し使用するよりも領域効率が高くなります。

サロゲートキーとも呼ばれます。 ナチュラルキーと対比してください。

自動インクリメント, ナチュラルキー, 主キー, サロゲートキーも参照

この行フォーマットは、InnoDB ではなく MyISAM ストレージエンジンによって使用されます。 MySQL 5.7.6 以前で ROW_FORMAT=FIXED オプションを指定して InnoDB テーブルを作成した場合、InnoDB はコンパクトな行形式をかわりに使用しますが、FIXED の値が SHOW TABLE STATUS レポートなどの出力に表示されることがあります。 MySQL 5.7.7 では、ROW_FORMAT=FIXED が指定されている場合、InnoDB はエラーを返します。

コンパクト行フォーマット, 行フォーマットも参照

外部キー関係で子テーブルとは、その行が別のテーブル内の行を参照 (またはポイント) し、特定のカラムについて同じ値を持つもののことです。 これは、FOREIGN KEY ... REFERENCES 句、およびオプションで ON UPDATE および ON DELETE 句を含むテーブルです。 行を子テーブル内に作成するには、その前に親テーブル内に対応する行が存在している必要があります。 子テーブル内の値は、外部キーの作成時に使用される ON CASCADE に基づいて、親テーブルでの削除または更新操作を禁止したり、子テーブル内で自動的に削除または更新したりする場合があります。

外部キー, 親テーブルも参照

起動時に MySQL が使用するオプション値を保持するファイル。 従来、Linux および Unix では、このファイルの名前は my.cnf で、Windows では my.ini です。 ファイルの [mysqld] セクションで、InnoDB に関連した多数のオプションを設定できます。

MySQL が構成ファイルを検索する場所の詳細は、セクション4.2.2.2「オプションファイルの使用」 を参照してください。

MySQL Enterprise Backup 製品を使用する場合、通常は 2 つの構成ファイルを使用: データの取得元とその構造化方法 (サーバーの元の構成ファイルである可能性がある) を指定するものと、バックアップデータの移動先と構造化方法を指定する小さなオプションセットのみを含むストリップダウンされたもの。 MySQL Enterprise Backup 製品で使用される構成ファイルには、通常は通常の構成ファイルから除外される特定のオプションが含まれている必要があるため、MySQL Enterprise Backup で使用するために既存の構成ファイルにオプションを追加する必要がある場合があります。

my.cnf, MySQL Enterprise Backup, オプション, オプションファイルも参照

INSERT ステートメントの 1 つ。自動インクリメント値が新しい行のすべてではなく一部に指定されます。 たとえば、複数値 INSERT では、一部のケースで自動インクリメントカラムの値を、ほかのケースで NULL を指定できます。 InnoDB は、カラム値が NULL として指定された行に自動インクリメント値を生成します。 別の例が、INSERT ... ON DUPLICATE KEY UPDATE ステートメントです。ここでは、INSERT ではなく UPDATE ステートメントとして処理される重複行がある場合、それらに自動インクリメント値が生成されますが、使用されません。

レプリケーション構成の source サーバーとレプリカサーバーの間で整合性の問題が発生する可能性があります。 innodb_autoinc_lock_mode 構成オプションの値の調整が必要な場合があります。

自動インクリメント, innodb_autoinc_lock_mode, レプリカ, レプリケーション, sourceも参照

ORDER BY column DESC 句を処理するためにインデックス記憶域が最適化される index のタイプ。

インデックスも参照

上限を表す値。実行時に超えるべきでないハード制限、または実際に到達した最大値の記録。 低位境界値と対比してください。

低位境界値も参照

InnoDB プラグインで最初に導入された機能は、5.5 以上の MySQL の一部であり、関連付けられたテーブルを完全にリライトする必要がなくなるため、InnoDB セカンダリインデックスの作成が高速化されます。 高速化はセカンダリインデックスの削除にも適用されます。

インデックスを保守することで多数のデータ転送操作にパフォーマンスオーバーヘッドを増やす場合があるので、セカンダリインデックスを用意せずに ALTER TABLE ... ENGINE=INNODB や INSERT INTO ... SELECT * FROM ... などの操作を行い、あとでインデックスを作成することを検討してみてください。

MySQL 5.6 では、この機能がより一般的になります。 インデックスの作成中にテーブルの読取りおよび書込みを行うことができ、テーブルをコピーせずに、または DML 操作をブロックせずに、あるいはその両方で、より多くの種類の ALTER TABLE 操作を実行できます。 したがって、MySQL 5.6 以上では、この機能セットは高速インデックス作成ではなくオンライン DDLと呼ばれます。

関連情報については、セクション15.12「InnoDB とオンライン DDL」を参照してください。

DML, インデックス, オンライン DDL, セカンダリインデックスも参照

innodb_fast_shutdown=1 の構成設定に基づく、InnoDB のデフォルトの shutdown プロシージャ。 時間を節約するために、特定のフラッシュ操作がスキップされます。 フラッシュ操作は次の起動中にクラッシュリカバリの場合と同じメカニズムを使用して実行されるので、通常の使用中にはこのタイプのシャットダウンが安全です。 アップグレードまたはダウングレードのためにデータベースをシャットダウンしている場合は、代わりに低速シャットダウンを行なって、すべての該当する変更がシャットダウン中にデータファイルに適用されることを保証してください。

クラッシュリカバリ, データファイル, フラッシュ, シャットダウン, 低速シャットダウンも参照

バッファプールを表すリスト構造内では、比較的古いページと比較的新しいページは、list の様々な部分によって表されます。 パラメータセットは、これらの部分のサイズと、新しいページと古いページ間の分割ポイントを制御します。

バッファープール, エビクション, リスト, LRUも参照

合成キーのシノニム名。

合成キーも参照

継続的に実行され、別のプログラム (client) からのリクエストの受信および処理を待機するプログラムのタイプ。 多くの場合、コンピュータ全体が 1 つ以上のサーバープログラムを実行することを目的とするため (データベースサーバー、Web サーバー、アプリケーションサーバー、これらの組み合わせなど)、用語サーバーはサーバーソフトウェアを実行するコンピュータを指す場合もあります。

クライアント, mysqldも参照

MySQL サーバーによって管理されるプリペアドステートメント。 これまで、サーバー側のプリペアドステートメントの問題により、Connector/J および Connector/PHP 開発者はかわりにクライアント側のプリペアドステートメントを使用する場合がありました。 最新の MySQL サーバーバージョンでは、パフォーマンス、スケーラビリティー、およびメモリー効率を向上させるために、サーバー側のプリペアドステートメントをお勧めします。

クライアント側のプリペアドステートメント, Connector/J, Connector/PHP, プリペアドステートメントも参照

pages(extent 全体) のグループをバッファプールに非同期にプリフェッチする I/O リクエストのタイプ。これらのページがまもなく必要になる場合に使用します。 線形先読み手法では、前のエクステントのページのアクセスパターンに基づいて、1 つのエクステントのすべてのページがプリフェッチされます。 ランダム先読み方法は、エクステントから特定数のページがバッファープールに入ると、同じエクステントのすべてのページをプリフェッチするものです。 ランダム先読みは、MySQL 5.5 には組み込まれていませんが、innodb_random_read_ahead 構成オプションの制御下で、MySQL 5.6 に再導入されています。

バッファープール, エクステント, ページも参照

InnoDB が DELETE ステートメントを処理すると、行はすぐに削除対象としてマークされ、クエリーによって返されなくなります。 記憶域は、後で、purge 操作と呼ばれる定期的なガベージコレクション中に再利用されます。 大量のデータを削除する場合、独自のパフォーマンス特性を持つ関連操作は TRUNCATE および DROP です。

ドロップ, パージ, 切り捨ても参照

ランダムな I/O を最小限に抑えるために物理書込みを実行できるように、変更を即座に書き込むのではなく、DELETE 操作によって生成されたセカンダリインデックスページへの変更を変更バッファに格納する方法。 (削除操作は 2 ステッププロセスなので、この操作は、通常はインデックスレコードに削除とマークする書き込みをバッファーに入れます。) これは変更バッファリングの一種です。ほかのタイプには挿入バッファリングとパージバッファリングがあります。

変更バッファー, 変更バッファリング, 挿入バッファー, 挿入バッファリング, パージバッファリングも参照

常に一貫する形式でデータを保守する方法。ACID 概念の一部です。 特に、異なるテーブル内のデータは外部キー制約の使用を通じて一貫性が保持され、これによって変更が発生するのを防止したり、それらの変更をすべての関連テーブルに自動的に伝播したりできます。 関連メカニズムには、重複値が間違って挿入されるのを防ぐ一意制約と、ブランク値が間違って挿入されるのを防ぐ NOT NULL 制約が含まれます。

ACID, FOREIGN KEY 制約, NOT NULL 制約, 一意制約も参照

インデックス内の疑似レコードで、そのインデックスの最小値を下回るギャップを表します。 トランザクションに SELECT ... FROM ... WHERE col < 10 FOR UPDATE;などのステートメントがあり、カラム内の最小値が 5 の場合、他のトランザクションが 0 や -10 などの小さい値を挿入できないようにするための、最小レコードに対するロックです。

ギャップ, インデックス, 疑似レコード, 最小上限レコードも参照

インデックス内の疑似レコードで、そのインデックスの最大値を上回るギャップを表します。 トランザクションに SELECT ... FROM ... WHERE col > 10 FOR UPDATE;などのステートメントがあり、カラムの最大値が 20 の場合、他のトランザクションが 50、100 などの大きな値を挿入できないようにするために、そのトランザクションは最高レコードをロックします。

ギャップ, 最大下限レコード, 疑似レコードも参照

InnoDB 関連オブジェクトのメタデータ、変更バッファの記憶域および二重書込みバッファを含む 1 つ以上のデータファイル (ibdata ファイル)。 file-per-table または一般テーブルスペースではなくシステムテーブルスペースにテーブルが作成された場合、InnoDB テーブルのテーブルおよびインデックスデータが含まれることもあります。 システムテーブルスペースのデータおよびメタデータは、MySQL instance のすべてのデータベースに適用されます。

MySQL 5.6.7 より前のデフォルトでは、すべての InnoDB テーブルおよびインデックスがシステムテーブルスペース内に保持されるため、多くの場合、このファイルは非常に大きくなりました。 システムテーブルスペースは決して縮小しないので、大容量の一時データがロードされてから削除された場合、ストレージの問題が発生する可能性があります。 MySQL 8.0 では、デフォルトは file-per-table モードで、各テーブルとそれに関連付けられたインデックスは別々の.ibd ファイルに格納されます。 このデフォルトでは、テーブル compression、オフページカラムの効率的な格納、大規模なインデックスキー接頭辞など、DYNAMIC および COMPRESSED の行形式に依存する InnoDB 機能を簡単に使用できます。

すべてのテーブルデータをシステムテーブルスペースまたは別個の .ibd ファイルのどちらに保持するかは、ストレージ管理全般に影響します。 MySQL Enterprise Backup 製品は、大きなファイルの小さなセットをバックアップすることも、多数のより小さなファイルをバックアップすることもできます。 何千ものテーブルがあるシステムでは、何千もの .ibd ファイルを処理するファイルシステム操作によってボトルネックが発生する可能性があります。

InnoDB では、MySQL 5.7.6 に一般的なテーブルスペースが導入されました。これらは .ibd ファイルでも表されます。 一般テーブルスペースは、CREATE TABLESPACE 構文を使用して作成される共有テーブルスペースです。 これらはデータディレクトリの外部で作成でき、複数のテーブルを保持でき、すべての行形式のテーブルをサポートします。

変更バッファー, 圧縮, データディクショナリ, データベース, 二重書き込みバッファー, 動的行フォーマット, file-per-table, 一般テーブルスペース, .ibd ファイル, ibdata ファイル, innodb_file_per_table, インスタンス, MySQL Enterprise Backup, オフページカラム, テーブルスペース, Undo ログも参照

MySQL Server を停止させるプロセス。 デフォルトでは、このプロセスは InnoDB テーブルの操作をクリーンアップするため、InnoDB は低速で停止できますが、後で高速に起動できます。 クリーンアップ操作をスキップすると、高速で停止しますが、次回の再起動時にクリーンアップを実行する必要があります。

InnoDB の停止モードは、innodb_fast_shutdown オプションによって制御されます。

高速シャットダウン, InnoDB, 低速シャットダウン, 起動も参照

すべてのダーティーバッファープールページ (その Redo エントリが Redo ログのどこかに含まれている) をディスクにフラッシュするプロセス。 InnoDB がログファイルの一部を再利用する前に発生します。ログファイルは循環的に使用されます。 通常は、書き込みの多いワークロードで発生します。

ダーティーページ, フラッシュ, Redo ログ, ワークロードも参照

シリアライズされた形式のディクショナリオブジェクトメタデータ。 SDI は JSON 形式で格納されます。

MySQL 8.0.3 では、SDI は一時テーブルスペースおよび undo テーブルスペースファイルを除くすべての InnoDB テーブルスペースファイルに存在します。 SDI がテーブルスペースファイルに存在すると、メタデータの冗長性が提供されます。 たとえば、データディクショナリが使用できなくなった場合は、ibd2sdi ユーティリティを使用してテーブルスペースファイルからディクショナリオブジェクトメタデータを抽出できます。

MyISAM テーブルの場合、SDI はスキーマディレクトリの .sdi メタデータファイルに格納されます。 IMPORT TABLE 操作を実行するには SDI メタデータファイルが必要です。

file-per-table, 一般テーブルスペース, システムテーブルスペース, テーブルスペースも参照

テーブル内のすべての行を一意に識別できる、このカラムセットに基づくインデックス。 したがって、NULL 値を一切含まない一意インデックスである必要があります。

InnoDB では、すべてのテーブルにこのようなインデックス (クラスタインデックスまたはクラスタインデックスとも呼ばれます) があり、主キーのカラム値に基づいてテーブル記憶域を編成する必要があります。

主キー値を選択するときは、ほかの何らかのソースから派生した値 (ナチュラルキー) に依存するのではなく、任意の値 (合成キー) を使用することを検討してください。

クラスタ化されたインデックス, インデックス, ナチュラルキー, 合成キーも参照

最も古い InnoDB 行フォーマット。 MySQL 5.0.3 より前は、これが InnoDB で利用できる唯一の行フォーマットでした。 MySQL 5.0.3 から MySQL 5.7.8 へのデフォルトの行フォーマットは COMPACT です。 MySQL 5.7.9 では、デフォルトの行フォーマットは、DYNAMIC のデフォルト設定を持つ innodb_default_row_format 構成オプションによって定義されます。 古い InnoDB テーブルとの互換性のために、引き続き REDUNDANT の行形式を指定できます。

詳細は、セクション15.10「InnoDB の行フォーマット」を参照してください。

コンパクト行フォーマット, 動的行フォーマット, 行フォーマットも参照

バックアップファイルセットの 1 つ。バイナリログおよび増分バックアップを適用するすべての段階が終了したあとに、MySQL Enterprise Backup 製品によって生成されます。 結果ファイルは、リストアできる状態です。 適用ステップより前のファイルは raw バックアップと呼ばれます。

バイナリログ, ホットバックアップ, 増分バックアップ, MySQL Enterprise Backup, raw バックアップ, リストアも参照

カラム内に昇順で値を自動的に追加する、テーブルカラムのプロパティー (AUTO_INCREMENT キーワードで指定します)。

これにより、開発者の作業が節約され、新しい行を挿入するときに新しい一意値を生成する必要はありません。 カラムには NULL でなく一意値が含まれているとわかっているので、クエリーオプティマイザに有用な情報をもたらします。 このようなカラムからの値は、さまざまなコンテキストでルックアップキーとして使用でき、自動生成されるので絶えず変更する理由はありません。このため、多くの場合、主キーカラムは自動インクリメントとして指定されます。

タイミングの問題により、レプリカでステートメントをリプレイしてもソースと同じカラム値のセットが生成されない場合があるため、ステートメントベースのレプリケーションでは自動増分カラムに問題が発生する可能性があります。 自動インクリメントする主キーがある場合は、innodb_autoinc_lock_mode=1 の設定だけでステートメントベースレプリケーションを使用できます。 挿入操作でより高い並列性を許可する innodb_autoinc_lock_mode=2 を使用する場合は、ステートメントベースレプリケーションではなく行ベースレプリケーションを使用してください。 互換性の目的以外は、innodb_autoinc_lock_mode=0 の設定を使用しないでください。

連続ロックモード (innodb_autoinc_lock_mode=1) は、MySQL 8.0.3 より前のデフォルト設定です。 MySQL 8.0.3 の時点では、インターリーブロックモード (innodb_autoinc_lock_mode=2) がデフォルトであり、デフォルトのレプリケーションタイプとしてステートメントベースから行ベースのレプリケーションへの変更が反映されます。

自動インクリメントロック, innodb_autoinc_lock_mode, 主キー, 行ベースレプリケーション, ステートメントベースレプリケーションも参照

自動インクリメント主キーの利便性には、並列性とのトレードオフが若干伴います。 もっとも単純なケースでは、あるトランザクションがテーブルに値を挿入している場合に、ほかのトランザクションはそのテーブルへのそれぞれの挿入を待機する必要があるので、最初のトランザクションによって挿入された行が、連続する主キー値を受け取ります。 InnoDB には最適化と innodb_autoinc_lock_mode オプションが含まれているため、自動インクリメント値の予測可能なシーケンスと挿入操作のための最大同時実行性の間で最適なバランスを構成できます。

自動インクリメント, 並列性, innodb_autoinc_lock_modeも参照

各 SQL ステートメントのあとにコミット操作を実行する設定。 複数のステートメントにまたがる transactions で InnoDB テーブルを操作する場合、このモードはお薦めしません。 これは、特に MySQL 5.6.4 以上で、ロックからのオーバーヘッドおよび元に戻すデータの生成を最小限に抑える InnoDB テーブルの読取り専用トランザクションのパフォーマンスに役立ちます。 また、トランザクションを適用できない MyISAM テーブルの操作にも適しています。

コミット, ロック, 読み取り専用トランザクション, SQL, トランザクション, Undoも参照

子テーブルに (から) ポイントされた初期カラム値を保持する、外部キー関係のテーブル。 親テーブル内の行を削除または更新したときの結果は、外部キー定義の ON UPDATE および ON DELETE 句によって異なります。 子テーブル内の対応する値の行が、それに合わせて自動的に削除または更新されたり、これらのカラムが NULL に設定されたり、操作が妨げられたりします。

子テーブル, 外部キーも参照

概念的には、スキーマは、テーブル、テーブルカラム、カラムのデータ型、インデックス、外部キーなど、相互に関連するデータベースオブジェクトのセットです。 カラムがテーブルを構成する、外部キーがテーブルやカラムを参照するなどの理由で、これらのオブジェクトは SQL 構文を通じて接続されます。 理論的には、これらは論理的にも接続し、統合されたアプリケーションまたは柔軟なフレームワークの一部として連携します。 たとえば、INFORMATION_SCHEMA および performance_schema データベースでは、名前に 「schema」 を使用して、含まれるテーブルとカラムの間の密接な関係を強調します。

MySQL では、スキーマは物理的にデータベースと同義です。 MySQL SQL 構文で、DATABASE の代わりにキーワード SCHEMA を代用できます。たとえば、CREATE DATABASE の代わりに CREATE SCHEMA を使用できます。

ほかのデータベース製品では区別しているものがあります。 たとえば、Oracle Database 製品では、スキーマはデータベースの一部、つまり単一ユーザーが所有するテーブルおよびほかのオブジェクトだけを表します。

データベース, INFORMATION_SCHEMA, パフォーマンススキーマも参照

システム能力の限界を超えてもパフォーマンスが突然落ちることがなく、システムにより多くの作業を追加したりより多くの同時リクエストを発行したりできること。 ソフトウェアアーキテクチャー、ハードウェア構成、アプリケーションコーディング、およびワークロードのタイプはすべて、スケーラビリティーで役割を担います。 システムがその最大能力に達したときにスケーラビリティーを増やす一般的な方法には、スケールアップ (既存のハードウェアまたはソフトウェアの能力を増大させる) とスケールアウト (新しいサーバーやより多くの MySQL インスタンスを追加する) があります。 多くの場合、大規模開発の重要な側面として、可用性と組み合わされます。

可用性, スケールアウト, スケールアップも参照

新しいサーバーやより多くの MySQL インスタンスを追加することによってスケーラビリティーを増大させる方法。 たとえば、レプリケーション、NDB Cluster、接続プーリング、またはサーバーのグループ全体に機能を分散させるその他の機能を設定します。 スケールアップと対比してください。

スケーラビリティー, スケールアップも参照

既存のハードウェアまたはソフトウェアの能力を高めることによりスケーラビリティーを増大させる方法。 たとえば、サーバー上でメモリーを増やすこと、innodb_buffer_pool_size や innodb_buffer_pool_instances などのメモリー関連パラメータを調整すること。 スケールアウトと対比してください。

スケーラビリティー, スケールアウトも参照

単数形と複数形、過去、現在、および未来時制など、共通語幹に基づいて単語のさまざまなバリエーションを検索する機能。 この機能は現在、MyISAM 全文検索機能でサポートされていますが、InnoDB テーブルのFULLTEXT インデックスではサポートされていません。

全文検索, FULLTEXT インデックスも参照

データベースアプリケーションによって発行された SQL ステートメントをトレース、デバッグまたは拡張するための interceptor のタイプ。 コマンドインタセプタとも呼ばれます。

Connector/J を使用する Java アプリケーションでは、このタイプのインターセプタを設定するには、com.mysql.jdbc.StatementInterceptorV2 インタフェースを実装し、statementInterceptors プロパティを接続文字列に追加します。

Connector/NET を使用する Visual Studio アプリケーションでは、このタイプのインターセプタを設定するには、BaseCommandInterceptor クラスから継承するクラスを定義し、そのクラス名を接続文字列の一部として指定する必要があります。

コマンドインタセプタ, 接続文字列, Connector/J, Connector/NET, interceptor, Java, Visual Studioも参照

SQL ステートメントが source から送信され、レプリカでリプレイされるレプリケーションの形式。 auto-increment locking の潜在的なタイミング問題を回避するために、innodb_autoinc_lock_mode オプションの設定には注意が必要です。

自動インクリメントロック, innodb_autoinc_lock_mode, レプリカ, レプリケーション, 行ベースレプリケーション, sourceも参照

ストアドプログラムまたはビュー。

ストアドルーチン (プロシージャーまたはファンクション)、トリガー、またはイベントスケジューライベント。

ストアドプロシージャまたはファンクション。

カラム定義に含まれる式から値が計算されるカラム。 カラム値は、行の挿入または更新時に評価および格納されます。 格納された生成カラムには記憶領域が必要で、インデックス付けできます。

仮想生成カラムと対比してください。

ベースカラム, 生成されるカラム, 仮想生成カラムも参照

FULLTEXT インデックスで、十分に一般的または些細なので検索インデックスから除外し、検索クエリーで無視できると考えられている単語。 InnoDB テーブルと MyISAM テーブルとでは、異なる構成設定がストップワード処理を制御します。 詳細は、セクション12.10.4「全文ストップワード」を参照してください。

FULLTEXT インデックス, 検索インデックスも参照

MySQL データベースのコンポーネントの 1 つ。データの格納、更新、および照会という低レベル作業を実行します。 MySQL 5.5 以上では、InnoDB が新しいテーブルのデフォルトのストレージエンジンであり、MyISAM よりも優先されます。 メモリー使用とディスク使用、読み取り速度と書き込み速度、速度と堅牢性など、異なる要因間トレードオフのために異なるストレージエンジンが設計されています。 各ストレージエンジンが特定のテーブルを管理するので、InnoDB テーブル、MyISAM テーブルなどと呼びます。

MySQL Enterprise Backup 製品は、InnoDB テーブルのバックアップ用に最適化されています。 また、MyISAM およびその他のストレージエンジンによって処理されるテーブルをバックアップすることもできます。

InnoDB, MySQL Enterprise Backup, テーブルタイプも参照

特定時点のデータの表現。ほかのトランザクションによって変更がコミットされても変化しません。 一貫性読み取りを許可する分離レベルで使用されます。

コミット, 一貫性読み取り, 分離レベル, トランザクションも参照

実際の空の領域を書き込むのではなく、空のブロックを表すメタデータをディスクに書き込むことで、ファイルシステム領域をより効率的に使用するファイルのタイプ。 InnoDB 透過的ページ圧縮機能は、スパースファイルサポートに依存します。 詳細は、セクション15.9.2「InnoDB ページ圧縮」を参照してください。

ホールパンチング, 透過的ページ圧縮も参照

リソースが利用できるようになるかどうかを継続的にテストするタイプの待機操作。 この手法は、スレッドをスリープさせてコンテキスト切替えを実行するよりも「「ビジーループ」」で待機する方が効率的な短い期間のみ保持されるリソースに使用されます。 リソースが短時間で利用できなくなると、スピンループは中止し、別の待機方法が使用されます。

ラッチ, ロック, 相互排他ロック, 待機も参照

MySQL インスタンス内で InnoDB テーブルスペースを一意に識別するために使用される識別子。 システムテーブルスペースの領域 ID は常にゼロです。この同じ ID は、システムテーブルスペース内または一般テーブルスペース内のすべてのテーブルに適用されます。 各 file-per-table テーブルスペースおよび一般テーブルスペースには、独自の領域 ID があります。

MySQL 5.6 より前では、このハードコードされた値によって、MySQL インスタンス間で InnoDB テーブルスペースファイルを移動することが困難でした。 MySQL 5.6 以降では、ステートメント FLUSH TABLES ... FOR EXPORT、ALTER TABLE ... DISCARD TABLESPACE、および ALTER TABLE ... IMPORT TABLESPACE を含むトランスポータブルテーブルスペース機能を使用することによって、インスタンス間でテーブルスペースファイルをコピーできます。 スペース ID を調整するために必要な情報は、テーブルスペースとともにコピーする .cfg ファイルで伝えられます。 詳細は、セクション15.6.1.3「InnoDB テーブルのインポート」 を参照してください。

.cfg ファイル, file-per-table, 一般テーブルスペース, .ibd ファイル, システムテーブルスペース, テーブルスペース, トランスポータブルテーブルスペースも参照

通常はプロセスより軽量で、高度な並列性に対応できる処理単位。

並列性, マスタースレッド, プロセス, Pthreadsも参照

MySQL Server によって処理される SQL ステートメントのパフォーマンスチューニングに使用されるタイプのログ。 ログ情報はファイルに格納されます。 使用するにはこの機能を有効にする必要があります。 ログに記録する「「低速」」 SQL ステートメントのカテゴリを制御します。 詳細は、セクション5.4.5「スロークエリーログ」を参照してください。

一般クエリーログ, ログも参照

ダーティリード、反復不可能な読み取り、phantom などの現象は、トランザクションが別のトランザクションによって変更されたデータを読み取るときに発生する可能性があります。

ダーティー読み取り, 反復不可能読み取り, ファントムも参照

テーブルのカラムのサブセットを表す InnoDB index のタイプ。 InnoDB テーブルには、ゼロ、1 つまたは複数のセカンダリインデックスを含めることができます。 (各 InnoDB テーブルに必要なクラスタインデックスと対比して、すべてのテーブルのカラムのデータを格納します。)

セカンダリインデックスは、インデックスカラムからの値だけを必要とするクエリーを満たすために使用できます。 より複雑なクエリーの場合、テーブル内の該当行を識別するために使用でき、それらはクラスタ化されたインデックスを使用するルックアップで取得されます。

セカンダリインデックスの作成および削除には、従来、InnoDB テーブルのすべてのデータのコピーによる大きなオーバーヘッドが伴いました。 高速インデックス作成機能を使用すると、InnoDB セカンダリインデックスに対して CREATE INDEX ステートメントと DROP INDEX ステートメントの両方がはるかに高速になります。

クラスタ化されたインデックス, 高速インデックス作成, インデックスも参照

InnoDB テーブルスペース内のディビジョン。 テーブルスペースをディレクトリに例えると、セグメントはそのディレクトリ内のファイルに似ています。 セグメントは増えることができます。 新しいセグメントを作成できます。

たとえば、file-per-table テーブルスペース内では、テーブルデータは 1 つのセグメントにあり、関連付けられた各インデックスは独自のセグメントにあります。 システムテーブルスペースは、多くのテーブルとそれらに関連付けられたインデックスを保持できるため、多くの異なるセグメントを含みます。 MySQL 8.0 より前のシステムテーブルスペースには、undo ログに使用される 1 つ以上のロールバックセグメントも含まれていました。

セグメントは、データの挿入と削除に応じて拡大、縮小します。 セグメントがより多くの領域を必要とする場合、一度に 1 エクステント (1M バイト) ずつ拡張されます。 同様に、セグメントは、あるエクステント内のすべてのデータが不要になると、そのエクステント分の領域を解放します。

エクステント, file-per-table, ロールバックセグメント, システムテーブルスペース, テーブルスペース, Undo ログも参照

InnoDB が内部一時テーブルのディスク上のストレージエンジンとして構成されている場合に、オプティマイザによって作成されたユーザー作成の一時テーブルおよび内部一時テーブルを格納する一時テーブルスペース。

オプティマイザ, 一時テーブル, 一時テーブルスペースも参照

セーブポイントは、ネストされたトランザクションの実装に役立ちます。 それらは、lより大きなトランザクションの一部であるテーブル上での操作にスコープを提供するために使用できます。 たとえば、予約システムで旅行をスケジュールするときに、いくつかの異なる航空便を予約する場合があります。希望の航空便を利用できない場合、予約に成功したそれより早い航空便をロールバックすることなく、その 1 行程の予約に関与する変更をロールバックできます。

ロールバック, トランザクションも参照

SQL LIKE 演算子を使用したり、アプリケーションレベル検索アルゴリズムを作成したりするよりも、より高速、より便利で、かつより柔軟な方法で単語、語句、単語のブール結合などをテーブルデータ内で検索するための MySQL 機能。 これは、SQL 関数 MATCH() および FULLTEXT インデックスを使用します。

FULLTEXT インデックスも参照

データが一貫性を失うのを防ぐために、データベース変更をブロックできる自動テスト。 (コンピュータサイエンス用語では、不変条件に関連する一種のアサーション。) 制約は、データ一貫性を維持するための、ACID 概念の重要な構成要素です。 MySQL によってサポートされる制約には、FOREIGN KEY 制約と一意制約があります。

ACID, 外部キー, 一意制約も参照

アプリケーションと MySQL サーバー間の通信チャネル。 データベースアプリケーションのパフォーマンスおよびスケーラビリティは、データベース接続の確立速度、同時に実行できる数、および永続化の期間に影響されます。 host、port などのパラメータは、Connector/NET では接続文字列として、Connector/ODBC では DSN として表されます。 高トラフィックシステムは、接続プールと呼ばれる最適化を利用します。

接続プール, 接続文字列, Connector/NET, Connector/ODBC, DSN, ホスト, portも参照

データベース操作ごとに新しい接続を設定および切断するのではなく、同じアプリケーション内または異なるアプリケーション間でデータベース connections を再利用できるキャッシュ領域。 この手法は、J2EE アプリケーションサーバーで共通です。 Connector/J を使用する Java アプリケーションでは、Tomcat および他のアプリケーションサーバーの接続プール機能を使用できます。 再利用はアプリケーションに対して透過的です。アプリケーションは通常どおり接続を開いて閉じます。

接続, Connector/J, J2EE, Tomcatも参照

プログラムコードで使用できるように文字列リテラルとしてエンコードされた、データベース connection のパラメータの表現。 文字列の一部は、host や port などの接続パラメータを表します。 接続文字列には、セミコロンで区切られた複数のキーと値のペアが含まれます。 各キーと値のペアは等号で結合されます。 Connector/NET アプリケーションで頻繁に使用されます。詳細は、Creating a Connector/NET Connection String を参照してください。

接続, Connector/NET, ホスト, portも参照

データベース設計戦略の 1 つ。データは複数のテーブルに分割されていて、圧縮された値を ID で表された単一行に複製することで、冗長または長い値を格納、照会、および更新することを回避します。 通常は OLTP アプリケーションで使用されます。

たとえば、住所に一意 ID を与えることで、国勢調査データベースはその ID を家族の各メンバーに関連付けることによって、この住所の住居人という関係を表現できます (米国のある街のメインストリート 123 などの複雑な値のコピーを複数格納するのではなく)。

別の例としては、単純な住所録アプリケーションでは、ある人の名前および住所と同じテーブルにそれぞれの電話番号を格納しますが、電話会社データベースでは、各電話番号に特別な ID を与えてその番号と ID を別のテーブルに格納します。 この正規化表現によって、市外局番が分かれるときの大幅な更新を簡略化できます。

正規化が常に推奨されるわけではありません。 主に照会されるだけで、更新されるのは全体を削除してリロードする場合だけのデータは、多くの場合、重複値の冗長コピーを持つ少数の大きなテーブルで保持されます。 このデータ表現は、非正規化と呼ばれ、データウェアハウスアプリケーションでよく見られます。

非正規化, 外部キー, OLTP, リレーショナルも参照

カラム定義に含まれる式から値が計算されるカラム。 生成されるカラムは、virtual または stored です。

ベースカラム, ストアド生成カラム, 仮想生成カラムも参照

データ分布のプロパティーの 1 つ。カラム内の個別値の数 (その カーディナリティー) をテーブル内のレコード数で割ったもの。 高い選択性は、カラム値が比較的一意であり、インデックスを通じて効率的に取得できることを意味します。 WHERE 句内のテストがテーブル内の少ない数 (または割合) の行にのみ一致すると予測できる場合 (またはクエリーオプティマイザがそう予測する場合)、クエリーがインデックスを使用してそのテストを最初に評価すると、全体的に効率的である傾向があります。

カーディナリティー, クエリーも参照

データベースアクティビティーの量を減らすこと。多くの場合、ALTER TABLE、バックアップ、シャットダウンなどの操作に備えるためです。 最大限のフラッシュの実行を伴う場合があるため (そうでない場合もありますが)、InnoDB はバックグラウンド I/O の実行を継続しません。

MySQL 5.6 以降では、構文 FLUSH TABLES ... FOR EXPORT によって InnoDB テーブルの一部のデータがディスクに書き込まれるので、そのデータファイルをコピーすることでこれらのテーブルをより簡単にバックアップできます。

バックアップ, フラッシュ, InnoDB, シャットダウンも参照

InnoDB インデックスの作成中にデータをソートするために使用されるバッファー。 ソートバッファーサイズは、innodb_sort_buffer_size 構成オプションを使用して構成されます。

ある時点以降に変更されたデータだけを保存する、MySQL Enterprise Backup 製品で実行されるタイプのホットバックアップ。 完全バックアップと一連の増分バックアップがあれば、いくつかの完全バックアップを手元においておくストレージオーバーヘッドなしで、長期間にわたるバックアップデータを再構築できます。 完全バックアップをリストアしてから各増分バックアップを連続して適用したり、各増分バックアップを完全バックアップに適用することでこれを最新の状態に保った状態で単一リストア操作を実行したりできます。

変更データの粒度はページレベルです。 実際は 1 つのページが複数の行をカバーすることがあります。 変更された各ページがバックアップに含まれます。

ホットバックアップ, MySQL Enterprise Backup, ページも参照

SQL での主要な DML 操作の 1 つ。 挿入のパフォーマンスは、データウェアハウスシステム (数百万行をテーブルにロードする) と OLTP システム (多数の並列接続が行を同じテーブルに任意の順序で挿入する可能性がある) で重要な要因です。 挿入パフォーマンスが重要な場合は、変更バッファリングで使用される挿入バッファーや自動インクリメントカラムなどの InnoDB 機能を学習することをお勧めします。

自動インクリメント, 変更バッファリング, データウェアハウス, DML, InnoDB, 挿入バッファー, OLTP, SQLも参照

ランダムな I/O を最小限に抑えるために物理書込みを実行できるように、変更を即座に書き込むのではなく、INSERT 操作によって生成されたセカンダリインデックスページへの変更を変更バッファに格納する方法。 これは変更バッファリングの 1 つのタイプです。ほかに削除バッファリングとパージバッファリングがあります。

セカンダリインデックスが一意の場合には挿入バッファリングは使用されません。新しいエントリが書き出される前に新しい値の一意性を検証できないためです。 ほかの種類の変更バッファリングは一意インデックスに有効です。

変更バッファー, 変更バッファリング, 削除バッファリング, 挿入バッファー, パージバッファリング, 一意のインデックスも参照

変更バッファの以前の名前。 MySQL 5.5 では、DELETE および UPDATE 操作のセカンダリインデックスページへの変更をバッファリングするためのサポートが追加されました。 以前は、INSERT 操作による変更のみがバッファされていました。 現在推奨されている用語は変更バッファです。

変更バッファー, 変更バッファリングも参照

「「mutex 変数」」の非公式略称。 (Mutex 自体は「「相互排他」」の短縮形です。) InnoDB が内部インメモリーデータ構造への排他的アクセスロックを表現および強制するために使用する低レベルオブジェクト。 ロックが獲得されると、ほかのプロセスやスレッドなどは同じロックを獲得できなくなります。 InnoDB が内部インメモリーデータ構造への共有アクセスロックを表現および強制するために使用する rw-locks と対比してください。 相互排他ロックと読み書きロックはまとめて、ラッチと呼ばれます。

ラッチ, ロック, パフォーマンススキーマ, Pthreads, rw ロック (読み書きロック)も参照

順序付けられた要素セットを指定する技術用語。 これは抽象概念で、データベース理論の公式ディスカッションで使用されます。 データベースフィールドでのタプルは通常、テーブル行のカラムによって表されます。 これらはクエリー (テーブルの一部のカラムだけ、または結合されたテーブルからのカラムを取得したクエリー、など) の結果セットで表される場合もあります。

カーソルも参照

InnoDB バッファプール内の page は、メモリー内で更新され、データファイルに変更がまだ書き込まれていません (flushed)。 クリーンページの反対です。

バッファープール, クリーンページ, データファイル, フラッシュ, ページも参照

信頼できないデータ、つまり別のトランザクションによって更新されたけれども、まだコミットされていないデータを取得する操作。 これは、コミットされた読み取りと呼ばれる分離レベルでのみ可能です。

この種の操作は、データベース設計の ACID 原則には準拠しません。 これは非常にリスクが高いと見なされます。データをロールバックできたり、コミットされる前にさらに更新できたりするためです。この場合、ダーティー読み取りを行うトランザクションは、正確であると確定されていないデータを使用することになります。

その反対は読取り一貫性であり、一方で他のトランザクションがコミットしても、InnoDB によって、別のトランザクションによって更新された情報が読み取られないことが保証されます。

ACID, コミット, 一貫性読み取り, 分離レベル, READ UNCOMMITTED, ロールバックも参照

lock、mutex または latch の取得などの操作をすぐに完了できない場合、InnoDB は一時停止して再試行します。 この一時停止のメカニズムはかなり入念に設計されているため、この操作には独自の名前、待機が付けられています。 個々のスレッドは、内部 InnoDB スケジューリング、オペレーティングシステムの wait() コールおよび短期スピンループの組合せを使用して一時停止されます。

負荷が高く、多くのトランザクションがあるシステムでは、SHOW INNODB STATUS コマンドまたはパフォーマンススキーマからの出力を使用して、スレッドが待機時間を過度に費やしているかどうか、および費やしている場合は同時実行性を改善する方法を判断できます。

並列性, ラッチ, ロック, 相互排他ロック, パフォーマンススキーマ, スピンも参照

InnoDB で、テーブルスペース内の page がディスクから InnoDB バッファプールに読み取られたときに破損を検出する検証メカニズム。 この機能は、MySQL 5.5 の innodb_checksums 構成オプションによって制御されます。innodb_checksums は、innodb_checksum_algorithm に置き換えられた MySQL 5.6.3 で非推奨になりました。

innochecksum コマンドは、MySQL サーバーの停止中に指定されたテーブルスペースファイルのチェックサム値をテストすることで、破損の問題の診断に役立ちます。

MySQL はレプリケーションのためにチェックサムも使用します。 詳細は、構成オプション binlog_checksum、master_verify_checksum、および slave_sql_verify_checksum を参照してください。

バッファープール, ページ, テーブルスペースも参照

バッファープールにキャッシュされているデータページに変更が行われると、これらの変更は少しあとからデータファイルに書き込まれます。これはフラッシュと呼ばれるプロセスです。 チェックポイントは、データファイルに正しく書き込まれている (LSN 値で表される) 最新の変更のレコードです。

バッファープール, データファイル, フラッシュ, ファジーチェックポイント, LSNも参照

部分信頼と同義です。 信頼設定の範囲は非常に広いため、「「部分信頼」」をお薦めします。これは、レベルが 3 つのみ (低、中および完全) であることを回避するためです。

Connector/NET, 部分信頼も参照

FULLTEXT インデックスに含まれるカラムセット。

FULLTEXT インデックスも参照

各 MySQL テーブルは、特定のストレージエンジンに関連付けられます。 InnoDB テーブルは、パフォーマンス、スケーラビリティー、バックアップ、管理、およびアプリケーション開発に影響する、特定の物理および論理特性を持っています。

ファイル記憶域に関して、InnoDB テーブルは次のいずれかのテーブルスペースタイプに属します:

.ibd データファイルには、テーブルデータと index データの両方が含まれます。

file-per-table テーブルスペースに作成された InnoDB テーブルでは、DYNAMIC または COMPRESSED の行形式を使用できます。 これらの行形式により、compression などの InnoDB 機能、オフページカラムの効率的な格納、大規模なインデックスキー接頭辞が可能になります。 一般テーブルスペースでは、すべての行形式がサポートされます。

システムテーブルスペースは、REDUNDANT、COMPACT および DYNAMIC の行形式を使用するテーブルをサポートしています。 DYNAMIC 行形式のシステムテーブルスペースサポートが MySQL 5.7.6 で追加されました。

InnoDB テーブルの rows は、クラスタインデックスと呼ばれるインデックス構造に編成され、テーブルの主キーカラムに基づいてエントリがソートされます。 データアクセスは主キーカラムでフィルタおよびソートするクエリーに最適化され、各インデックスには各エントリに関連付けられた主キーカラムのコピーが含まれます。 主キーカラムの値を変更することは負荷の高い操作です。 したがって、InnoDB テーブル設計の重要な側面は、最も重要なクエリーで使用されるカラムを持つ主キーを選択し、値をほとんど変更せずに主キーを短く保つことです。

バックアップ, クラスタ化されたインデックス, コンパクト行フォーマット, 圧縮行フォーマット, 圧縮, 動的行フォーマット, 高速インデックス作成, file-per-table, .ibd ファイル, インデックス, オフページカラム, 主キー, 冗長行フォーマット, 行, システムテーブルスペース, テーブルスペースも参照

index を使用して選択した部分のみでなく、テーブルの内容全体を読み取る必要がある操作。 通常は、小さなルックアップテーブル、またはすべての利用可能なデータが集約および分析される大きなテーブルを持つデータウェアハウジング状況で実行されます。 これらの操作が発生する頻度、および使用可能なメモリーに対するテーブルのサイズは、クエリーの最適化およびバッファプールの管理で使用されるアルゴリズムに影響します。

インデックスの目的は、大きなテーブル内で特定の値または値の範囲をルックアップできるようにし、したがって有用なときはフルテーブルスキャンを回避することです。

バッファープール, インデックスも参照

InnoDB テーブルおよび関連するインデックスのデータを保持できるデータファイル。

システムテーブルスペースには InnoDB データディクショナリが含まれており、MySQL 5.6 より前は、デフォルトで他のすべての InnoDB テーブルが保持されます。

innodb_file_per_table オプションは、MySQL 5.6 以上でデフォルトで有効になっており、独自のテーブルスペースにテーブルを作成できます。 File-per-table テーブルスペースは、オフページカラム、テーブル圧縮、トランスポータブルテーブルスペースの効率的なストレージなどの機能をサポートします。 詳細は、セクション15.6.3.2「File-Per-Table テーブルスペース」 を参照してください。

InnoDB では、MySQL 5.7.6 に一般テーブルスペースが導入されました。 一般テーブルスペースは、CREATE TABLESPACE 構文を使用して作成される共有テーブルスペースです。 これらは MySQL データディレクトリの外部で作成でき、複数のテーブルを保持でき、すべての行形式のテーブルをサポートします。

また、MySQL NDB Cluster はそのテーブルをテーブルスペースにグループ化します。 詳細は、セクション23.5.10.1「NDB Cluster ディスクデータオブジェクト」を参照してください。

圧縮行フォーマット, データディクショナリ, データファイル, file-per-table, 一般テーブルスペース, インデックス, innodb_file_per_table, システムテーブルスペース, テーブルも参照

ストレージエンジンの古いシノニムです。 InnoDB テーブル、MyISAM テーブルなどと呼びます。

InnoDB, ストレージエンジンも参照

ほかのトランザクションがテーブルにアクセスすることを防ぐロック。 InnoDB では、DML ステートメントおよびクエリーの処理にオンライン DDL、行ロック、読取り一貫性などの技術を使用することで、このようなロックを不要にするためにかなりの労力があります。 SQL から LOCK TABLE ステートメントを使用してこのようなロックを作成できます。ほかのデータベースシステムまたは MySQL ストレージエンジンから移行するステップの 1 つは、可能なときはこのようなステートメントを削除することです。

一貫性読み取り, DML, ロック, ロック, オンライン DDL, クエリー, 行ロック, テーブル, トランザクションも参照

ディクショナリオブジェクトキャッシュは、以前にアクセスしたデータディクショナリオブジェクトをメモリーに格納して、オブジェクトの再利用を可能にし、ディスク I/O を最小化します。 LRU ベースのエビクション戦略を使用して、メモリーから最近使用されていないオブジェクトを除去します。 キャッシュは、様々なオブジェクトタイプを格納する複数のパーティションで構成されます。

詳細は、セクション14.4「ディクショナリオブジェクトキャッシュ」を参照してください。

データディクショナリ, LRUも参照

主なボトルネックがディスク I/O であるタイプのワークロード。 (I/O バウンドとも呼ばれます。) 通常は、ディスクへの頻繁な書き込みや、バッファープールに収められるよりも多くのデータのランダム読み取りがかかわります。

ボトルネック, バッファープール, ワークロードも参照

主にディスクストレージ (ハードドライブまたはその同等物) 上のデータを編成するタイプのデータベース。 データは、ディスクとメモリー間でやり取りされて操作されます。 インメモリーデータベースの反対です。 InnoDB はディスクベースですが、バッファプール、複数のバッファープールインスタンス、および特定の種類のワークロードが主にメモリーから機能できる適応型ハッシュインデックスなどの機能も含まれています。

適応型ハッシュインデックス, バッファープール, インメモリーデータベースも参照

さまざまなトランザクションが進行できない状況 (それぞれが、他方が必要とするロックを保持しているため)。 どちらのトランザクションもリソースが使用可能になるのを待機しているため、どちらも保持しているロックを解放しません。

(UPDATE や SELECT ... FOR UPDATE などのステートメントを通じて) トランザクションが複数のテーブル内の行を反対の順にロックすると、デッドロックが発生することがあります。 デッドロックは、このようなステートメントがインデックスレコードとギャップの範囲をロックし、各トランザクションが一部のロックを取得するけれども、タイミングの問題によりほかを取得しない場合にも発生することがあります。

自動的にデッドロックを検出して処理する方法に関する背景情報については、セクション15.7.5.2「デッドロック検出」を参照してください。 デッドロック状況を回避しリカバリするためのヒントについては、セクション15.7.5.3「デッドロックを最小化および処理する方法」を参照してください。

ギャップ, ロック, トランザクションも参照

デッドロックが検出されたときにロールバック済として自動的に選択されるトランザクション。 InnoDB は、更新された行が最も少ないトランザクションをロールバックします。

デッドロック検出は、innodb_deadlock_detect 構成オプションを使用して無効にできます。

デッドロック, デッドロック検出, innodb_lock_wait_timeout, トランザクションも参照

デッドロックが起きていることを自動的に検出し、関係するトランザクションのいずれか (デッドロック対象) を自動的にロールバックするメカニズム。 デッドロック検出は、innodb_deadlock_detect 構成オプションを使用して無効にできます。

デッドロック, ロールバック, トランザクション, デッドロック対象も参照

主に大きなクエリーを実行するデータベースシステムまたはアプリケーション。 読み取り専用または読み取りが大半のデータは、クエリーの効率を高めるために非正規化された形式で編成できます。 MySQL 5.6 以降では、読み取り専用トランザクションの最適化からメリットを得ることができます。 OLTP と対比してください。

非正規化, OLTP, クエリー, 読み取り専用トランザクションも参照

テーブル、インデックス、テーブル columns などのデータベースオブジェクトを追跡するメタデータ。 MySQL 8.0 で導入された MySQL データディクショナリの場合、メタデータは mysql データベースディレクトリの InnoDB file-per-table テーブルスペースファイルに物理的に配置されます。 InnoDB データディクショナリの場合、メタデータは InnoDB システムテーブルスペースに物理的に配置されます。

MySQL Enterprise Backup 製品では常に InnoDB システムテーブルスペースがバックアップされるため、すべてのバックアップに InnoDB データディクショナリの内容が含まれます。

カラム, file-per-table, .frm ファイル, インデックス, MySQL Enterprise Backup, システムテーブルスペース, テーブルも参照

各 MySQL instance が InnoDB 用のデータファイルおよび個々のデータベースを表すディレクトリを保持するディレクトリ。 datadir 構成オプションによって制御されます。

データファイル, インスタンスも参照

table および index データを物理的に格納するファイル。

InnoDB データディクショナリを保持し、複数の InnoDB テーブルのデータを保持できる InnoDB システムテーブルスペースは、1 つ以上の .ibdata データファイルで表されます。

単一の InnoDB テーブルのデータを保持する File-per-table テーブルスペースは、.ibd データファイルで表されます。

複数の InnoDB テーブルのデータを保持できる一般的なテーブルスペース (MySQL 5.7.6 で導入) は、.ibd データファイルでも表されます。

データディクショナリ, file-per-table, 一般テーブルスペース, .ibd ファイル, ibdata ファイル, インデックス, システムテーブルスペース, テーブル, テーブルスペースも参照

MySQL データディレクトリ内では、各データベースは個別のディレクトリで表されます。 MySQL instance 内の複数のデータベースからのテーブルデータを保持できる InnoDB システムテーブルスペースは、個々のデータベースディレクトリの外部にあるデータファイルに保持されます。 file-per-table モードが有効な場合、DATA DIRECTORY 句を使用して別の場所に作成されないかぎり、個々の InnoDB テーブルを表す.ibd ファイルはデータベースディレクトリ内に格納されます。 MySQL 5.7.6 で導入された一般的なテーブルスペースには、.ibd ファイルのテーブルデータも保持されます。 file-per-table .ibd ファイルとは異なり、一般的なテーブルスペース.ibd ファイルは、MySQL instance 内の複数のデータベースからのテーブルデータを保持でき、MySQL データディレクトリに対して相対的または独立したディレクトリに割り当てることができます。

長年 MySQL を使用している人にとって、データベースはなじみ深い概念です。 Oracle Database バックグラウンドからのユーザーは、データベースの MySQL の意味が、Oracle Database が schema をコールする内容に近いことがわかります。

データファイル, file-per-table, .ibd ファイル, インスタンス, スキーマ, システムテーブルスペースも参照

下限を表す値。通常は、何らかの訂正アクションが始まったり、より積極的になったりするしきい値です。 高位境界値と対比してください。

高位境界値も参照

完了前に追加の InnoDB フラッシュ操作を実行する shutdown のタイプ。 クリーンシャットダウンとも呼ばれます。 構成パラメータ innodb_fast_shutdown=0 またはコマンド SET GLOBAL innodb_fast_shutdown=0; で指定されます。 シャットダウン自体には時間がかかる場合がありますが、その後の起動時にその時間を節約する必要があります。

クリーンシャットダウン, 高速シャットダウン, シャットダウンも参照

InnoDB 全文検索の実装で使用される、ドキュメント取得システム用に最適化されたデータ構造。 逆インデックスとして実装された InnoDB FULLTEXT インデックスは、テーブルの行の場所ではなく、ドキュメント内の各ワードの位置を記録します。 単一カラム値 (テキスト文字列として格納されたドキュメント) は多くのエントリで転置インデックスで表現されます。

全文検索, FULLTEXT インデックス, ilistも参照

メモリー内にハッシュインデックスを構築することで、= および IN 演算子を使用して検索を高速化できる InnoDB テーブルの最適化。 MySQL は、InnoDB テーブルのインデックス検索を監視し、クエリーがハッシュインデックスのメリットを得られる場合は、頻繁にアクセスされるインデックス pages のインデックス検索を自動的に作成します。 ある意味では、適応型ハッシュインデックスは、十分なメインメモリーを利用するように MySQL を実行時に構成するので、メインメモリーデータベースのアーキテクチャーに近づいています。 この機能は、innodb_adaptive_hash_index 構成オプションで制御されます。 この機能は、一部のワークロードにはメリットがあってもほかのものにはメリットがなく、ハッシュインデックスに使用されるメモリーはバッファープールで予約されているので、通常はこの機能を有効にした状態と無効にした状態でベンチマークを行うことをお勧めします。

常に、ハッシュインデックスはテーブル上の既存の B ツリーインデックスに基づいて構築されます。 MySQL は、インデックスに対する検索パターンに応じて、B ツリーに定義された任意の長さのキーのプリフィクスに、ハッシュインデックスを構築できます。 ハッシュインデックスは部分的であってもかまいません。B ツリーインデックス全体をバッファープールにキャッシュする必要はありません。

MySQL 5.6 以上では、InnoDB テーブルで高速単一値参照を利用する別の方法は、InnoDB memcached プラグインを使用することです。 詳細は、セクション15.20「InnoDB memcached プラグイン」を参照してください。

B ツリー, バッファープール, ハッシュインデックス, memcached, ページ, セカンダリインデックスも参照

チェックポイントによって生じる I/O オーバーヘッドを軽減する InnoDB テーブル用のアルゴリズム。 MySQL は、変更されたすべてのページをバッファープールからデータファイルに一度にフラッシュするのではなく、変更されたページの小さなセットを定期的にフラッシュします。 適応型フラッシュアルゴリズムは、フラッシュの頻度と Redo 情報の生成速度に基づいてこれらの定期フラッシュの最適な実行頻度を見積もることによって、このプロセスを拡張します。

バッファープール, チェックポイント, データファイル, フラッシュ, InnoDB, ページ, Redo ログも参照

MySQL Enterprise Backup 製品で生成されたバックアップに、バックアップ進行中に行われた最新の変更が含まれない場合、これらの変更を含むようにバックアップファイルを更新するプロセスは適用ステップと呼ばれます。 これは mysqlbackup コマンドの apply-log オプションで指定されます。

変更が適用されるまでは、このファイルは raw バックアップと呼ばれます。 変更が適用されたあとは、このファイルは準備されたバックアップと呼ばれます。 変更は、ibbackup_logfile ファイルに記録されます。適用ステップが終了すると、このファイルは不要になります。

ホットバックアップ, ibbackup_logfile, MySQL Enterprise Backup, 準備されたバックアップ, raw バックアップも参照

SSLも参照

問題の原因を特定するプロセス。 MySQL の問題をトラブルシューティングするためのリソースには、次のものがあります:

トランザクションは、committed またはロールバック済の作業の原子単位です。 トランザクションによってデータベースに複数の変更が行われた場合、トランザクションがコミットされるとすべての変更が完了し、トランザクションがロールバックされるとすべての変更が元に戻されます。

InnoDB によって実装されるデータベーストランザクションには、アトミック性、一貫性、分離性および永続性のために頭字語 ACID によってまとめて知られるプロパティがあります。

ACID, コミット, 分離レベル, ロック, ロールバックも参照

各 row に関連付けられた内部フィールド。 このフィールドは、行をロックしたトランザクションを記録するために、INSERT、UPDATE および DELETE 操作によって物理的に変更されます。

暗黙の行ロック, 行, トランザクションも参照

テーブルスペースがあるインスタンスから別のインスタンスに移動されることを許可する機能。 従来、すべてのテーブルデータがシステムテーブルスペースの一部であったため、これは InnoDB テーブルスペースでは不可能でした。 MySQL 5.6 以上では、FLUSH TABLES ... FOR EXPORT 構文は InnoDB テーブルを別のサーバーにコピーする準備をします。他のサーバーで ALTER TABLE ... DISCARD TABLESPACE および ALTER TABLE ... IMPORT TABLESPACE を実行すると、コピーされたデータファイルが他のインスタンスに取り込まれます。 .ibd ファイルとともにコピーされた個別の.cfg ファイルを使用して、テーブルスペースのインポート時にテーブルメタデータ (スペース IDなど) が更新されます。 使用に関する情報は セクション15.6.1.3「InnoDB テーブルのインポート」を参照してください。

.cfg ファイル, .ibd ファイル, スペース ID, システムテーブルスペース, テーブルスペースも参照

InnoDB 全文検索機能において、各 ilist 値に関連付けられたドキュメントを一意に識別するための、FULLTEXT インデックスを含むテーブルの特別なカラム。 その名前は FTS_DOC_ID (大文字必須) です。 カラム自体は、BIGINT UNSIGNED NOT NULL 型で、FTS_DOC_ID_INDEX という名前の一意インデックス付きである必要があります。 テーブルの作成時にこのカラムを定義することが推奨されます。 FULLTEXT インデックスの作成時に InnoDB でテーブルにカラムを追加する必要がある場合、インデックス付け操作のコストはかなり高くなります。

全文検索, FULLTEXT インデックス, ilistも参照

DDL 操作の一種。DROP TABLE や DROP INDEX などのステートメントを通じてスキーマオブジェクトを削除します。 これは内部的に ALTER TABLE ステートメントにマッピングします。 InnoDB の観点からは、このような操作のパフォーマンス上の考慮事項には、相互に関連するオブジェクトがすべて更新されるようにデータディクショナリがロックされている時間、およびバッファプールなどのメモリー構造を更新する時間が含まれます。 テーブルの場合、ドロップ操作には、切り捨て操作 (TRUNCATE TABLE ステートメント) と多少異なる特性があります。

バッファープール, データディクショナリ, DDL, テーブル, 切り捨ても参照

ステートメントの各部分を文字列変数に連結するナイブテクニックよりも強力でセキュアで効率的な方法を使用してプリペアドステートメントを作成および実行できる機能。

プリペアドステートメントも参照

ODBC でサポートされている cursor のタイプで、行が再度読み取られたときに新しい結果および変更された結果を取得できます。 カーソルに変更が表示されるかどうかとその速度は、関連するテーブルのタイプ (トランザクションまたは非トランザクション) およびトランザクションテーブルの分離レベルによって異なります。 動的カーソルのサポートは明示的に有効にする必要があります。

カーソル, ODBCも参照

動的 SQLを介して作成および実行されるプリペアドステートメント。

動的 SQL, プリペアドステートメントも参照

InnoDB の行フォーマット。 長い可変長のカラム値は、行データを保持するページの外部に格納されるため、ラージオブジェクトを含む行では非常に効率的です。 ラージフィールドは通常、クエリー条件を評価するためにアクセスされることはないので、頻繁にはバッファープールに読み込まれません。その結果、I/O 操作は少なくなり、キャッシュメモリーの利用率が改善します。

MySQL 5.7.9 では、デフォルトの行フォーマットは、DYNAMIC のデフォルト値を持つ innodb_default_row_format によって定義されます。

InnoDB DYNAMIC 行フォーマットの追加情報については、DYNAMIC 行フォーマットを参照してください。

バッファープール, ファイル形式, 行フォーマットも参照

各 InnoDB テーブルおよびインデックスに関連する評価値。効率的なクエリー実行計画の構築に使用されます。 メイン値は、カーディナリティー (個別値の数) と、テーブル行またはインデックスエントリの合計数です。 テーブルの統計は、その主キーインデックス内のデータを表します。 セカンダリインデックスの統計は、このインデックスで扱われる行を表します。

値は正確なカウントではなく、見積もりです。あらゆる瞬間にさまざまなトランザクションが同じテーブルからの行を挿入したり削除したりしている可能性があるためです。 値が頻繁に再計算されないように、永続的統計を有効にできます。この場合、値は InnoDB システムテーブルに格納され、ANALYZE TABLE ステートメントを発行するときにのみ更新されます。

innodb_stats_method 構成オプションで統計を計算するときに、NULL 値がどのように扱われるかを制御できます。

INFORMATION_SCHEMA および PERFORMANCE_SCHEMA テーブルを通じて、ほかのタイプの統計をデータベースオブジェクトおよびデータベースアクティビティーに利用できます。

カーディナリティー, インデックス, INFORMATION_SCHEMA, NULL, パフォーマンススキーマ, 永続的統計, 主キー, クエリー実行計画, セカンダリインデックス, テーブル, トランザクションも参照

file-per-table テーブルスペースに存在する InnoDB テーブルのページレベルの圧縮を可能にする MySQL 5.7.8 で追加された機能。 ページ圧縮を有効にするには、CREATE TABLE または ALTER TABLE で COMPRESSION 属性を指定します。 詳細は、セクション15.9.2「InnoDB ページ圧縮」を参照してください。

file-per-table, ホールパンチング, スパースファイルも参照

インデックス付けされたカラム (通常は主キー)。値には実際の意味があります。 通常は、次の理由のため推奨されていません。

したがって通常は、自動インクリメントカラムを使用するなど、任意の数値を使用して合成キーを作成することをお勧めします。

自動インクリメント, クラスタ化されたインデックス, 主キー, セカンダリインデックス, 合成キーも参照

InnoDB では、二重書込みと呼ばれるファイルフラッシュ手法を使用します。 pages をデータファイルに書き込む前に、InnoDB はまず二重書込みバッファと呼ばれる記憶域に書き込みます。 二重書込みバッファへの書込みおよびフラッシュが完了した後にのみ、InnoDB はデータファイル内の適切な位置にページを書き込みます。 ページ書込みの途中でオペレーティングシステム、ストレージサブシステムまたは mysqld プロセスがクラッシュした場合、InnoDB は後でクラッシュリカバリ中に二重書込みバッファからページの適切なコピーを見つけることができます。

データは常に 2 度書き込まれますが、二重書き込みバッファーには、2 倍の I/O オーバーヘッドも 2 倍の I/O 操作も不要です。 データは、オペレーティングシステムへの単一 fsync() 呼び出しで、大きなシーケンシャルチャンクとしてバッファー自体に書き込まれます。

二重書き込みバッファーをオフにするには、オプション innodb_doublewrite=0 を指定します。

クラッシュリカバリ, データファイル, ページ, パージも参照

libmysqlclient と同義です。

libmysqlも参照

インデックスレコードでのレコードロックと、インデックスレコードの前のギャップでのギャップロックの組み合わせ。

ギャップロック, ロック, レコードロックも参照

大なりや BETWEEN などの範囲演算子ではなく、等値演算子を使用するクエリーを対象とするタイプのインデックス。 これは、MEMORY テーブルで使用できます。 履歴上の理由から、ハッシュインデックスは MEMORY テーブルのデフォルトですが、そのストレージエンジンは B-tree インデックスもサポートしています。これは、一般的な目的のクエリーに適していることがよくあります。

MySQL には、ランタイム条件に基づいて必要に応じて InnoDB テーブル用に自動的に作成される、このインデックスタイプのバリアント (適応型ハッシュインデックス) が含まれています。

適応型ハッシュインデックス, B ツリー, インデックス, InnoDBも参照

システムが適切に機能していることを示すために送信される定期的メッセージ。 レプリケーションコンテキストでは、source がこのようなメッセージの送信を停止すると、レプリカのいずれかが発生します。 クラスタ環境内のすべてのサーバーが正しく動作していることを確認するために、それらの間で類似の方法を使用できます。

レプリケーション, sourceも参照

テーブルデータを変更しようとするすべてのステートメントまたは行の変更のレコードを含むファイル。 バイナリログの内容をリプレイして、レプリケーションシナリオでレプリカを最新の状態にしたり、バックアップからテーブルデータを復元したあとでデータベースを最新の状態にしたりできます。 バイナリロギング機能は、オンとオフを切り替えられますが、レプリケーションを使用したりバックアップを実行したりする場合は、常に有効にしておくことをお勧めします。

mysqlbinlog コマンドを使用すると、バイナリログの内容を検査したり、レプリケーションまたは回復中にそれを再生したりできます。 バイナリログの詳細は、セクション5.4.4「バイナリログ」を参照してください。 バイナリログに関連した MySQL 構成オプションについては、セクション17.1.6.4「バイナリロギングのオプションと変数」を参照してください。

MySQL Enterprise Backup 製品の場合、バイナリログのファイル名とファイル内での現在の位置が重要な詳細です。 レプリケーションコンテキストでバックアップを作成するときにソースのこの情報を記録するには、--slave-info オプションを指定できます。

MySQL 5.0 より前では、更新ログと呼ばれる同様の機能を利用できました。 MySQL 5.0 以上では、更新ログがバイナリログに置き換わりました。

binlog, MySQL Enterprise Backup, レプリケーションも参照

直後に再起動が行われるシャットダウン操作。 パフォーマンスとスループットが迅速に高いレベルに戻るように、ウォームアップ期間が比較的短ければ理想的です。

シャットダウンも参照

保護するために、MySQL インスタンスから一部またはすべてのテーブルデータおよびメタデータをコピーするプロセス。 コピーされたファイルのセットを指す場合もあります。 これは DBA のきわめて重要なタスクです。 このプロセスの反対がリストア操作です。

MySQL では、物理バックアップは MySQL Enterprise Backup 製品で実行され、論理バックアップは mysqldump コマンドで実行されます。 これらの方法は、バックアップデータのサイズおよび表現と速度 (特にリストア操作の速度) の点で特性が異なります。

バックアップはさらに、通常のデータベース操作に干渉する程度に応じて、ホット、ウォーム、コールドに分類されます。 (干渉の程度は、ホットバックアップがもっとも少なく、コールドバックアップがもっとも多くなります。)

コールドバックアップ, ホットバックアップ, 論理バックアップ, MySQL Enterprise Backup, mysqldump, 物理バックアップ, ウォームバックアップも参照

一時ストレージに使用されるメモリーまたはディスク領域。 多数の小さな I/O 操作ではなく少数の大きなものでディスクに効率的に書き込めるように、データはメモリーにバッファリングされます。 データは、信頼性を高めるためにディスクにバッファリングされるので、考えられる最悪の場合にクラッシュやほかの障害が発生してもリカバリできます。 InnoDB で使用される主なバッファタイプは、バッファプール、二重書込みバッファおよび変更バッファです。

バッファープール, 変更バッファー, クラッシュ, 二重書き込みバッファーも参照

テーブルとインデックスの両方のキャッシュされた InnoDB データを保持するメモリー領域。 大容量読み取り操作の効率を高めるため、バッファープールは複数行を保持できるページに分割されます。 キャッシュ管理の効率のために、バッファープールはページのリンクリストとして実装されます。まれにしか使用されないデータは、LRU アルゴリズムのバリエーションを使用してキャッシュからエージアウトされます。 大容量メモリーを備えたシステムでは、バッファープールを複数のバッファープールインスタンスに分割することにより、並列性を改善できます。

いくつかの InnoDB ステータス変数、INFORMATION_SCHEMA テーブルおよび performance_schema テーブルは、バッファプールの内部動作の監視に役立ちます。 MySQL 5.6 以降では、サーバーの停止時にバッファプールの状態を保存し、サーバーの起動時にバッファプールを同じ状態にリストアすることで、サーバーの再起動後、特に大規模なバッファプールを持つインスタンスで長いウォームアップ期間を回避できます。 セクション15.8.3.6「バッファープールの状態の保存と復元」を参照してください。

バッファープールインスタンス, LRU, ページ, ウォームアップも参照

バッファープールは複数の領域に分割できますが、そのいずれか。innodb_buffer_pool_instances 構成オプションで制御されます。 innodb_buffer_pool_size で指定された合計メモリーサイズは、すべてのバッファプールインスタンスに分割されます。 通常、複数のバッファープールインスタンスを持つことは、InnoDB バッファープールに複数の G バイトを割り当てるシステムに適しています。各インスタンスは 1 G バイト以上です。 多数の同時セッションからバッファプール内の大量のデータをロードまたは検索するシステムでは、複数のバッファプールインスタンスを使用すると、バッファプールを管理するデータ構造への排他的アクセスの競合が軽減されます。

バッファープールも参照

InnoDB バッファープールでさまざまなサイズのページを管理するためのメカニズム。

バッファープール, ページ, page sizeも参照

performance_schema スキーマは (MySQL 5.5 以降)、MySQL Server の多くの内部パーツのパフォーマンス特性に関する詳細情報を取得するために照会できる、テーブルセットを提供します。 第27章「MySQL パフォーマンススキーマ」を参照してください。

INFORMATION_SCHEMA, ラッチ, 相互排他ロック, rw ロック (読み書きロック)も参照

(innodb_purge_threads によって制御される) 個別のバックグラウンドスレッドによって実行されるガベージコレクションのタイプで、定期的に実行されます。 パージでは、undo ログページを履歴リストから解析して処理します。これは、(以前の DELETE ステートメントによって) 削除対象としてマークされ、MVCC または rollback では不要になったクラスタインデックスレコードおよびセカンダリインデックスレコードを削除するためです。 パージすると、undo ログページは処理後に履歴リストから解放されます。

履歴リスト, MVCC, ロールバック, Undo ログも参照

定期的な purge 操作の実行専用の InnoDB プロセス内のスレッド。 MySQL 5.6 以降では、複数のパージスレッドが innodb_purge_threads 構成オプションによって有効になっています。

パージ, スレッドも参照

ランダムな I/O を最小限に抑えるために物理書込みを実行できるように、変更を即座に書き込むのではなく、DELETE 操作によって生成されたセカンダリインデックスページへの変更を変更バッファに格納する方法。 (削除操作は 2 ステッププロセスなので、この操作は、通常は以前に削除とマークされたインデックスレコードをパージする書き込みをバッファリングします。) これは変更バッファリングの一種です。ほかには挿入バッファリングと削除バッファリングがあります。

変更バッファー, 変更バッファリング, 削除バッファリング, 挿入バッファー, 挿入バッファリングも参照

InnoDB 履歴リストの別の名前。 innodb_max_purge_lag 構成オプションに関連しています。

履歴リスト, パージも参照

READ COMMITTED と読取り一貫性の組合せである、UPDATE ステートメントに使用される読取り操作のタイプ。 UPDATE ステートメントがすでにロックされている行を調べると、InnoDB は、MySQL に最新のコミット済バージョンを返して、その行が UPDATE の WHERE 条件に一致するかどうかを判断できるようにします。 行が一致する場合 (更新する必要がある場合)、MySQL は行を再度読み取り、今回は InnoDB がロックするか、ロックを待機します。 このタイプの読取り操作は、トランザクションに READ COMMITTED 分離レベルがある場合にのみ実行できます。

一貫性読み取り, 分離レベル, READ COMMITTEDも参照

あるクエリーがデータを取得し、同じトランザクション内のその後のクエリーが同じデータであるはずのものを取得するけれども、それらのクエリーが異なる結果を返す状況 (その間にコミットしている別のトランザクションによって変更された)。

この種の操作は、データベース設計の ACID 原則に反します。 トランザクション内のデータは、予測可能で安定した関係を持ち、一貫しているべきです。

さまざまな分離レベルの中で、反復不可能読み取りは、シリアライズ可能読み取りと反復可能読み取りレベルによって防止され、一貫性読み取りとコミットされていない読み取りレベルで許可されます。

ACID, 一貫性読み取り, 分離レベル, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, トランザクションも参照

ほかのトランザクションが同じ行をロックするのを回避するタイプのロック。 この種のロックは、トランザクション分離レベルに応じて、ほかのトランザクションが同じ行に書き込むのをブロックしたり、ほかのトランザクションが同じ行を読み取るのをブロックしたりできます。 デフォルトの InnoDB 分離レベルである REPEATABLE READ を使用すると、読取り一貫性と呼ばれる手法である排他ロックを持つ行をトランザクションが読み取ることができるため、より高い同時実行性が有効になります。

並列性, 一貫性読み取り, 分離レベル, ロック, REPEATABLE READ, 共有ロック, トランザクションも参照

I/O デバイス構成とハードウェア障害の組み合わせが原因で発生する可能性のあるエラー状況。 データが InnoDB ページサイズより小さいチャンク (デフォルトでは 16KB) で書き出された場合、書込み中にハードウェア障害が発生すると、ページの一部のみがディスクに格納される可能性があります。 InnoDB 二重書込みバッファは、この可能性を防ぎます。

二重書き込みバッファーも参照

営利企業を運営するために使用される、ビジネスソフトウェアの基盤を形作るアクションの関係およびシーケンス。 これらのルールは、法律によって規定されたり、企業ポリシーで規定されたります。 慎重に計画することで、データベースでエンコードされ適用される関係と、アプリケーションロジックを通じて実行されるアクションが、企業の実際のポリシーを正確に反映し、現実の状況を扱うことができます。

たとえば、従業員が会社を退職すると、人事部からアクションシーケンスがトリガーされます。 人事データベースには、雇用されたけれどもまだ就業していない人物に関するデータを表すために、柔軟性も必要になることがあります。 オンラインサービスで口座を閉鎖すると、データがデータベースから削除されたり、口座が再度開設されたりした場合にリカバリできるようにデータが移動またはフラグ付けされたります。 企業は、給与が負数でないなどの基本的なサニティーチェックに加えて、給与の最大、最小、および調整に関するポリシーを確立できます。 小売データベースでは、同じシリアル番号の購入を複数回返すことを禁止したり、一定値を超えるクレジットカード購入を禁止したりしますが、詐欺の検出に使用されるデータベースでは、このようなことを許可する場合があります。

リレーショナルも参照

非同期 I/Oと同じ意味を持つ業界用語。

非同期 I/Oも参照

SELECT ... FOR UPDATE または SELECT ... LOCK IN SHARE MODE 句を使用しないクエリー。 読み取り専用トランザクションでグローバルテーブルに許可される唯一の種類のクエリー。 ロック読み取りの反対。 セクション15.7.2.3「一貫性非ロック読み取り」を参照してください。

MySQL 8.0.1 の SELECT ... LOCK IN SHARE MODE は SELECT ... FOR SHARE に置き換わりますが、LOCK IN SHARE MODE は下位互換性のために引き続き使用できます。

ロック読み取り, クエリー, 読み取り専用トランザクションも参照

I/O が完了するまでほかの処理の進行を許可する I/O 操作のタイプ。 非ブロック化 I/Oとも呼ばれ、AIO と省略されます。 InnoDB では、実際にはリクエストされていないが、すぐに必要になる可能性があるバッファプールへのページの読取りなど、データベースの信頼性に影響を与えることなくパラレルで実行できる特定の操作に、このタイプの I/O が使用されます。

従来、InnoDB は Windows システムでのみ非同期 I/O を使用していました。 InnoDB プラグイン 1.1 および MySQL 5.5 以上では、InnoDB は Linux システムで非同期 I/O を使用します。 この変更により、libaio への依存関係がもたらされます。 Linux システムでの非同期 I/O は、innodb_use_native_aio オプションを使用して構成されます。これはデフォルトで有効になっています。 ほかの Unix 系システムでは、InnoDB は同期 I/O だけを使用します。

バッファープール, 非ブロック化 I/Oも参照

外部キーと結合クエリーでテーブルをリンクするのではなく、複数のテーブルにわたってデータを複製するデータストレージ戦略。 通常はデータウェアハウスアプリケーションで使用されます。この場合、データはロード後に更新されません。 このようなアプリケーションでは、更新中にデータの一貫性を維持することを簡略化するよりも、クエリーパフォーマンスが重要になります。 正規化と対比してください。

データウェアハウス, 外部キー, 結合, 正規化も参照

InnoDB テーブルのファイル形式。

file-per-table, .ibd ファイル, ibdata ファイル, 行フォーマットも参照

データベース処理を妨害するダーティーページを一度にすべてフラッシュするのではなく、ダーティーページの小さなバッチをバッファープールからフラッシュする方法。

バッファープール, ダーティーページ, フラッシュも参照

あるクエリーの結果セットに出現するけれども、以前のクエリーの結果セットにない行。 たとえば、あるクエリーがトランザクション内で 2 度実行されて、その間に別のトランザクションがそのクエリーの WHERE 句に一致する新しい行を挿入または行を更新したあとにコミットされた場合です。

この現象がファントム読み取りと呼ばれます。 このことから保護することは、反復不可能読み取りよりも困難です。最初のクエリー結果セットからのすべての行をロックしても、ファントムが出現する変更は防止されないためです。

さまざまな分離レベルの中で、ファントム読み取りは、シリアライズ可能読み取りで防止され、反復可能読み取り、一貫性読み取り、およびコミットされていない読み取りレベルで許可されます。

一貫性読み取り, 分離レベル, 反復不可能読み取り, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, トランザクションも参照

InnoDB index で、ページが分割される前にインデックスデータによって取得される page の割合。 ページ間でインデックスデータが最初に分割されるときの未使用領域によって、負荷のかかるインデックス保守操作を必要とすることなく、より長い文字列値で行を更新できます。 フィルファクタが低すぎた場合、インデックスは必要以上の領域を消費し、インデックスを読み取るときに余分な I/O オーバーヘッドが生じます。 フィルファクタが高すぎると、カラム値の長さが増える更新で、インデックス保守の追加 I/O オーバーヘッドが生じる可能性があります。 詳細は、セクション15.6.2.2「InnoDB インデックスの物理構造」を参照してください。

インデックス, ページも参照

メモリー領域または一時ディスクストレージ領域にバッファリングされていた変更をデータベースファイルに書き込むこと。 定期的にフラッシュされる InnoDB 記憶域構造には、redo ログ、undo ログおよびバッファプールが含まれます。

フラッシュは、メモリー領域がいっぱいになってシステムが一部の領域を解放する必要があるため、コミット操作が、トランザクションからの変更を完結できることを意味するため、または低速シャットダウン操作が、すべての未処理作業を完結するべきであることを意味するため、行われます。 バッファリングされているデータすべてを一度にフラッシュすることが重要でないときは、InnoDB は、ファジーチェックポイントという方法を使用して、ページの小さなバッチをフラッシュし、I/O オーバーヘッドを分散させることができます。

バッファープール, コミット, ファジーチェックポイント, Redo ログ, 低速シャットダウン, Undo ログも参照

バッファプールでダーティページを追跡する内部 InnoDB データ構造: つまり、変更され、ディスクにライトアウトする必要がある pages。 このデータ構造は、InnoDB 内部 mini-transactions によって頻繁に更新されるため、バッファプールへの同時アクセスを可能にするために独自の mutex によって保護されます。

バッファープール, ダーティーページ, LRU, ミニトランザクション, 相互排他ロック, ページ, ページクリーナーも参照

WITH QUERY EXPANSION 句で有効になる全文検索の特別なモード。 これは検索を 2 度実行し、2 度目の検索には、最初の検索で検出されたドキュメントからのもっとも関連性の強い少数の単語をつなぎ合わせた、独自の検索語句を使用します。 この方法は、主に短い検索語句、おそらく単一単語のみに適用されます。 これは、正確な検索語句がドキュメント内で現れない場合に、関連した一致を見つけることができます。

全文検索も参照

効率的な実行計画を決定するために事前に分析される SQL ステートメント。 毎回解析および分析のオーバーヘッドなしで、複数回実行できます。 プレースホルダを使用して、毎回 WHERE 句のリテラルに異なる値を代入できます。 この置換手法により、セキュリティが向上し、なんらかの SQL インジェクション攻撃から保護されます。 戻り値をプログラム変数に変換およびコピーするためのオーバーヘッドを削減することもできます。

プリペアドステートメントは SQL 構文を介して直接使用できますが、様々なコネクタにはプリペアドステートメントを操作するためのプログラミングインタフェースがあり、これらの API は SQL を介して実行するよりも効率的です。

クライアント側のプリペアドステートメント, コネクタ, サーバー側のプリペアドステートメントも参照

実行中プログラムのインスタンス。 オペレーティングシステムは、複数の実行中プロセスを切り替えることで、一定程度の並列性を実現します。 ほとんどのオペレーティングシステムのプロセスには、リソースを共有する複数の実行スレッドを含めることができます。 スレッド間のコンテキスト切り替えは、プロセス間の同等切り替えより高速です。

並列性, スレッドも参照

データベース処理の基礎の 1 つ。 分離は、頭字語 ACID の I です。分離レベルは、複数のトランザクションが同時に変更を行ったりクエリーを実行したりしているときに、パフォーマンスと信頼性のバランス、一貫性、結果の再現性を微調整する設定です。

もっとも高い一貫性および保護からもっとも低いものまで、InnoDB でサポートされる分離レベルは、SERIALIZABLE、REPEATABLE READ、READ COMMITTED、および READ UNCOMMITTED です。

InnoDB テーブルでは、多くのユーザーがすべての操作に対してデフォルトの分離レベル (REPEATABLE READ) を保持できます。 エキスパートユーザーは、OLTP 処理でスケーラビリティの境界をプッシュするとき、またはわずかな不一致が大量のデータの集計結果に影響しないデータウェアハウス操作中に、READ COMMITTED レベルを選択できます。 両端のレベル (SERIALIZABLE および READ UNCOMMITTED) は、処理動作をまれにしか使用されない程度に変更します。

ACID, OLTP, READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, トランザクションも参照

ディスクブロック、メモリーページ、ファイル、ビット、ディスク読み取りなど、ハードウェア関連側面がかかわるタイプの操作。 物理側面は通常、上級者レベルのパフォーマンスチューニングおよび問題診断中に重要になります。 論理と対比してください。

論理, 物理バックアップも参照

実際のデータファイルをコピーするバックアップ。 たとえば、MySQL Enterprise Backup 製品の mysqlbackup コマンドは物理バックアップを返します。その出力に mysqld サーバーが直接使用できるデータファイルが含まれているためです (リストア操作の速度が向上します)。 論理バックアップと対比してください。

バックアップ, 論理バックアップ, MySQL Enterprise Backup, リストアも参照

複数のカラムを含むインデックス。

インデックスも参照

カラム値の一部 (通常は、長い VARCHAR 値の最初の N 文字 (プリフィクス) だけを表す) インデックス。

インデックス, インデックスプリフィクスも参照

MySQL データベースのテーブルの一部、または MySQL インスタンスのデータベースの一部を含むバックアップ。 完全バックアップと対比してください。