MySQL 用語集

これらの用語は、MySQL データベースサーバーに関する情報で一般的に使用されます。この用語集は、InnoDB ストレージエンジンに関する用語のリファレンスとして作成され、大部分の定義は InnoDB 関連です。

.

.ARM ファイル

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

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

.ARZ ファイル

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

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

.cfg ファイル

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

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

.frm ファイル

MySQL テーブルのメタデータ (テーブル定義など) を含むファイル。

バックアップの場合、バックアップ後に変更または削除されたテーブルをリストアできるように、バックアップデータとともに .frm ファイルの完全セットを常に保持する必要があります。

それぞれの InnoDB テーブルには .frm ファイルがありますが、InnoDB は独自のテーブルメタデータをシステムテーブルスペースに保持しています。InnoDB が InnoDB テーブルを処理する場合、.frm ファイルは不要です。

これらのファイルは、MySQL Enterprise Backup 製品によってバックアップされます。バックアップが行われている間にこれらのファイルを ALTER TABLE 操作で変更してはいけないため、InnoDB でないテーブルを含むバックアップは .frm ファイルのバックアップ中に、FLUSH TABLES WITH READ LOCK 操作を実行してこのようなアクティビティーをフリーズします。バックアップをリストアするときに、バックアップ時点のデータベースの状態に一致するように、.frm ファイルが作成、変更、または削除される場合があります。

MySQL Enterprise Backupも参照

.ibd ファイル

file-per-table モードを使用して作成された各 InnoDB テーブルは、データベースディレクトリ内で、.ibd 拡張子の専用のテーブルスペースファイルに書き込まれます。このファイルにはテーブルデータと、テーブルのインデックスが含まれます。innodb_file_per_table オプションで制御される file-per-table モードは、InnoDB ストレージの使用法およびパフォーマンスの多くの側面に影響し、MySQL 5.6.7 以降でデフォルトで有効になっています。

この拡張子は、ibdata ファイルから構成されるシステムテーブルスペースには適用されません。

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

MySQL 5.6 以降で DATA DIRECTORY = 句を使用してテーブルが作成された場合、.ibd ファイルは、通常のデータベースディレクトリの外部に置かれ、.isl ファイルによってポイントされます。

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

.ibz ファイル

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

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

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

.isl ファイル

MySQL 5.6 以降の DATA DIRECTORY = 句で作成された InnoDB テーブルの、.ibd ファイルの場所を指定するファイル。これは、実際のシンボリックリンクメカニズムのプラットフォーム制限なしで、シンボリックリンクのように機能します。データベースディレクトリ外部 (たとえば、テーブルの使用状況に応じて特別に大きなまたは高速なストレージデバイス) に InnoDB テーブルスペースを格納できます。詳細は、セクション14.5.4「テーブルスペースの位置の指定」を参照してください。

データベース, .ibd ファイル, テーブル, テーブルスペースも参照

.MRG ファイル

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

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

.MYD ファイル

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

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

.MYI ファイル

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

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

.OPT ファイル

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

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

.PAR ファイル

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

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

.TRG ファイル

トリガーパラメータを含むファイル。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されるバックアップに含められます。

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

.TRN ファイル

トリガー名前空間情報を含むファイル。この拡張子を持つファイルは常に、MySQL Enterprise Backup 製品の mysqlbackup コマンドで生成されるバックアップに含められます。

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

2

2 フェーズコミット

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

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

A

ACID

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

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

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

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

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

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

AHI

適応型ハッシュインデックス (Adaptive Hash Index) の頭字語。

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

AIO

非同期 I/O (Asynchronous I/O) の頭字語。この頭字語は InnoDB メッセージやキーワードで見られます。

非同期 I/Oも参照

Antelope

元の InnoDB ファイル形式のコード名。これは、冗長および簡易行フォーマットをサポートしますが、Barracuda ファイル形式で利用できるより新しい動的および圧縮行フォーマットはサポートしません。

アプリケーションが、InnoDB テーブル圧縮からメリットを受けられるか、動的行フォーマットからメリットを受けられる BLOB またはラージテキストカラムを使用する場合、一部のテーブルを Barracuda 形式に切り替えることができます。テーブルの作成前に innodb_file_format オプションを設定することによって、使用するファイル形式を選択します。

Barracuda, コンパクト行フォーマット, 圧縮行フォーマット, 動的行フォーマット, ファイル形式, innodb_file_format, 冗長行フォーマットも参照

B

B ツリー

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

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

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

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

Barracuda

テーブルデータの圧縮をサポートする InnoDB ファイル形式のコード名。このファイル形式は、最初に InnoDB Plugin に導入されました。これは、InnoDB テーブル圧縮に対応した圧縮行フォーマットと、BLOB およびラージテキストカラムのストレージレイアウトを改善する動的行フォーマットをサポートします。これは innodb_file_format オプションで選択できます。

InnoDB システムテーブルスペースは元の Antelope ファイル形式で格納されるため、Barracuda ファイル形式を使用するには、システムテーブルスペースとは別の独自のテーブルスペースに新しく作成したテーブルを格納する file-per-table 設定も有効にする必要があります。

MySQL Enterprise Backup 製品バージョン 3.5 以降では、Barracuda ファイル形式を使用するテーブルスペースのバックアップをサポートします。

Antelope, コンパクト行フォーマット, 圧縮行フォーマット, 動的行フォーマット, ファイル形式, file-per-table, innodb_file_format, MySQL Enterprise Backup, 行フォーマット, システムテーブルスペースも参照

binlog

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

バイナリログも参照

C

CPU バウンド

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

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

CRUD

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

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

D

DCL

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

DDL, DML, SQLも参照

DDL

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

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

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

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

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

DML

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

InnoDB テーブルの DML ステートメントはトランザクションのコンテキストで動作するため、その効果は単一の単位としてコミットまたはロールバックできます。

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

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

F

file-per-table

innodb_file_per_table オプションで制御される設定に対する一般名。これは、InnoDB ファイルストレージの多くの側面、機能の利用可能性、および I/O 特性に影響する、非常に重要な構成オプションです。MySQL 5.6.7 以降ではデフォルトで有効になっています。MySQL 5.6.7 より前では、デフォルトで無効になっています。

この設定が有効である間に作成されたテーブルごとに、データは、システムテーブルスペースの ibdata ファイルではなく、個別の .ibd ファイルに格納されます。テーブルデータが個々のファイルに格納されている場合、データ圧縮などの機能に必要な、デフォルト以外のファイル形式と行フォーマットを選択できる柔軟性が得られます。TRUNCATE TABLE 操作も高速化され、解放された領域は、InnoDB に予約されたままではなく、オペレーティングシステムで使用できます。

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

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

FOREIGN KEY 制約

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

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

FTS

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

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

FULLTEXT インデックス

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

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

G

GA

「一般提供 (Generally Available)」。ソフトウェア製品がベータを終え、販売、公式サポート、および本番使用に利用できるようになった段階。

ベータ, アーリーアダプタも参照

global_transaction

XA 操作に含まれるタイプのトランザクション。これは、それ自体はトランザクションであるけれども、すべてがグループとして正しく完了する必要があるか、グループとしてロールバックされる必要がある、いくつかのアクションから構成されます。基本的に、これは ACID 特性を 1 レベル上に拡張することにより、複数の ACID トランザクションを、同じく ACID 特性を持つグローバル操作のコンポーネントとして連携して実行できるようにします。この種の分散トランザクションの場合、SERIALIZABLE 分離レベルを使用して ACID 特性を実現する必要があります。

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

H

HDD

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

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

I

I/O バウンド

ディスクバウンドも参照

ib-file セット

MySQL データベース内で InnoDB によって管理されるファイルのセット (システムテーブルスペース、file-per-table テーブルスペース、(通常は 2 つの) Redo ログファイル)。InnoDB ファイル構造および形式の詳細なディスカッションで、さまざまな DBMS 製品間でのデータベースの意味と、MySQL データベースに含まれている可能性がある非 InnoDB ファイルとの間のあいまいさを避けるために使用されることがあります。

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

ibbackup_logfile

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

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

ibdata ファイル

InnoDB システムテーブルスペースを構成する、ibdata1 や ibdata2 などの名前を持つファイルのセット。これらのファイルには、InnoDB テーブルに関するメタデータ (データディクショナリ) と、Undo ログ、変更バッファー、二重書き込みバッファーのストレージ領域が含まれます。(各テーブルの作成時に file-per-table モードが有効であるかどうかによって) テーブルデータの一部またはすべてを含めることもできます。innodb_file_per_table オプションが有効であるときに、新しく作成されたテーブルのデータおよびインデックスは、システムテーブルスペースではなく個別の .ibd ファイルに格納されます。

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

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

ibtmp ファイル

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

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

ib_logfile

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

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

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

ilist

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

FULLTEXT インデックスも参照

INFORMATION_SCHEMA

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

情報スキーマには、INNODB_LOCKS や INNODB_TRX など、InnoDB に固有のいくつかのテーブルが含まれます。これらのテーブルは、データベースがどのように構造化されているかを確認するためではなく、InnoDB テーブルの動作に関するリアルタイム情報を得るために使用してください (パフォーマンスモニタリング、チューニング、トラブルシューティングに役立ちます)。これらのテーブルは特に、圧縮、トランザクション、およびそれらに関連付けられたロックに関連する MySQL 機能についての情報を提供します。

圧縮, データディクショナリ, データベース, InnoDB, ロック, トランザクションも参照

InnoDB

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

MySQL 5.5 以降では、InnoDB が新しいテーブルのデフォルトストレージエンジンなので、ENGINE=INNODB 句は必要ありません。MySQL 5.1 でのみ、高度な InnoDB 機能の多くで InnoDB Plugin と呼ばれるコンポーネントを有効にする必要があります。InnoDB テーブルがデフォルトである最近のリリースへの移行に関する考慮事項については、セクション14.1.1「デフォルトの MySQL ストレージエンジンとしての InnoDB」を参照してください。

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

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

innodb_autoinc_lock_mode

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

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

innodb_file_format

innodb_file_format オプションは、このオプションの値を指定したあとに作成されるすべての InnoDB テーブルスペースのファイル形式を決定します。システムテーブルスペース以外のテーブルスペースを作成するには、file-per-table オプションも使用する必要があります。現在のところ、Antelope および Barracuda ファイル形式を指定できます。

Antelope, Barracuda, ファイル形式, file-per-table, innodb_file_per_table, システムテーブルスペース, テーブルスペースも参照

innodb_file_per_table

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

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

このオプションは、テーブル圧縮などの多くのほかの InnoDB 機能や、MySQL Enterprise Backup での特定のテーブルのバックアップを十分に活用するために必要です。

このオプションは以前は静的でしたが、SET GLOBAL コマンドを使用して設定できるようになりました。

参照情報については、innodb_file_per_table を参照してください。使用法情報については、セクション14.5.2「InnoDB File-Per-Table モード」を参照してください。

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

innodb_lock_wait_timeout

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

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

innodb_strict_mode

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

このモードは MySQL 5.5.5 以降のデフォルト設定です。

厳密モードも参照

IOPS

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

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

K

KEY_BLOCK_SIZE

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

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

L

lock mode

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

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

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

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

loose_

MySQL 5.1 で、サーバーの起動後に InnoDB Plugin をインストールするときに、InnoDB 構成オプションに追加されるプリフィクス。したがって、現在のレベルの MySQL で認識されない新しい構成オプションは起動エラーを引き起こしません。MySQL は、このプリフィクスで始まる構成オプションを処理しますが、プリフィクスに続く部分が認識されるオプションでない場合、エラーではなく警告を返します。

プラグインも参照

LRU

「Least Recently Used」の頭字語。ストレージ領域を管理するための一般的な方法。より新しい項目をキャッシュするための領域が必要なときは、最近使用されていない項目は削除されます。InnoDB は、バッファープール内のページを管理するためにデフォルトで LRU メカニズムを使用しますが、ページが 1 回だけ読み取られる場合 (フルテーブルスキャン中など) を例外扱いします。LRU アルゴリズムのこのバリエーションはミッドポイント挿入戦略と呼ばれます。バッファープール管理が従来の LRU アルゴリズムと異なる点は、オプション innodb_old_blocks_pct、innodb_old_blocks_time と、新しい MySQL 5.6 オプション innodb_lru_scan_depth および innodb_flush_neighbors により微調整されることです。

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

LSN

「ログシーケンス番号 (Log Sequence Number)」の頭字語。この任意の増加し続ける値は、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 ログ, トランザクションも参照

M

MDL

「メタデータロック (MetaData Lock)」の頭字語。

メタデータロックも参照

memcached

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

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

InnoDB, NoSQLも参照

mtr

ミニトランザクションも参照

MVCC

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

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

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

my.cnf

UNIX または Linux システムでの MySQL オプションファイルの名前。

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

my.ini

Windows システムでの MySQL オプションファイルの名前。

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

mysql

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

mysqld, SQLも参照

MySQL Enterprise Backup

MySQL データベースのホットバックアップを実行するライセンス製品。InnoDB テーブルをバックアップするときに効率性と柔軟性がもっとも高くなりますが、MyISAM とほかの種類のテーブルもバックアップできます。

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

mysqlbackup コマンド

MySQL Enterprise Backup 製品のコマンド行ツール。InnoDB テーブルにはホットバックアップ操作を、MyISAM とほかの種類のテーブルにはウォームバックアップ操作を実行します。このコマンドの詳細は、セクション25.2「MySQL Enterprise Backup」を参照してください。

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

mysqld

mysqld プログラムは、MySQL データベース用のデータベースエンジンです。UNIX デーモンまたは Windows サービスとして動作し、常にリクエストを待機し、バックグラウンドで保守作業を実行します。

mysqlも参照

mysqldump

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

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

N

NoSQL

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

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

NOT NULL 制約

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

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

NULL

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

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

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

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

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

O

OLTP

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

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

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

P

page size

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

MySQL 5.6 以降、InnoDB インスタンスのページサイズは 4K バイト、8K バイト、または 16K バイトに設定でき、innodb_page_size 構成オプションで制御できます。MySQL 5.7.6 以降の InnoDB は、32K バイトおよび 64K バイトページサイズのサポートも提供します。どちらのページサイズでも、ROW_FORMAT=COMPRESSED はサポートされず、最大レコードサイズは 16K バイトです。

サイズは MySQL インスタンス作成時に設定し、その後は不変です。同じページサイズが、すべての InnoDB テーブルスペース (システムテーブルスペースと、file-per-table モードで別個に作成されるテーブルスペース) に適用されます。

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

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

PITR

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

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

Pthreads

POSIX スレッド標準。UNIX および Linux システムでのスレッドおよびロック操作の API を定義します。UNIX および Linux システムでは、InnoDB はこの相互排他ロック実装を使用します。

相互排他ロックも参照

R

RAID

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

並列性も参照

raw バックアップ

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

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

READ COMMITTED

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

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

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

READ UNCOMMITTED

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

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

Redo

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

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

Redo ログ

クラッシュリカバリ中に、不完全なトランザクションによって書き込まれるデータを訂正するために使用されるディスクベースデータ構造。通常の操作中に、InnoDB テーブルデータを変更するリクエスト (SQL ステートメント、または NoSQL インタフェースからの低レベル 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, シャットダウン, トランザクションも参照

REPEATABLE READ

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

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

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

rw ロック (読み書きロック)

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

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

• s ロックは、共有リソースへの読み取りアクセスを提供します。

• x ロックは、共有リソースへの書き込みアクセスを提供し、ほかのスレッドによる不整合読み取りを許可しません。

• sx ロックは、共有リソースへの書き込みアクセスを提供し、ほかのスレッドによる不整合読み取りを許可します。sx ロックは、読み取り/書き込みワークロードの並列性を最適化し、スケーラビリティーを改善するために MySQL 5.7 で導入されました。

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

	S	SX	X
S	互換	互換	競合
SX	互換	競合	競合
X	競合	競合	競合

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

S

SERIALIZABLE

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

これは、SQL 標準で指定されるデフォルト分離レベルです。実際にはこの程度の厳密さはまれにしか必要でないので、InnoDB のデフォルト分離レベルは次にもっとも厳密な反復可能読み取りです。

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

SQL

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

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

SSD

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

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

T

TPS

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

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

U

Undo

トランザクションの生存期間保持されるデータ。ロールバック操作の場合に元に戻せるようにすべての変更を記録します。これは、システムテーブルスペース内または別個の Undo テーブルスペース内の Undo ログに格納され、ロールバックセグメントとも呼ばれます。

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

Undo テーブルスペース

innodb_undo_tablespaces および innodb_undo_directory 構成オプションによって Undo ログがシステムテーブルスペースから分離されているときに、Undo ログを含むファイルセットの 1 つ。MySQL 5.6 以降にのみ適用されます。

システムテーブルスペース, Undo ログも参照

Undo バッファー

Undo ログも参照

Undo ログ

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

この領域はデフォルトで物理的にシステムテーブルスペースの一部です。MySQL 5.6 以降では、innodb_undo_tablespaces および innodb_undo_directory 構成オプションを使用して、これを 1 つまたは複数の別個のテーブルスペースファイル (Undo テーブルスペース) に分割でき、オプションで SSD などの別のストレージデバイスに格納できます。

Undo ログは、別個の部分、挿入 Undo バッファーと更新 Undo バッファーに分割されます。これらの部分はまとめて、Oracle DBA になじみ深い用語、ロールバックセグメントとも呼ばれます。

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

W

Windows

組み込み InnoDB ストレージエンジンと InnoDB Plugin が、MySQL Server と同じすべての Microsoft Windows バージョンでサポートされます。MySQL Enterprise Backup 製品は、InnoDB Hot Backup 製品の後継ですが、Windows システムをより包括的にサポートします。

InnoDB, MySQL Enterprise Backup, プラグインも参照

X

XA

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

XA 分散トランザクションサポートは、デフォルトでオンになっています。この機能を使用していない場合でも、innodb_support_xa 構成オプションを無効にすることで、トランザクションごとに追加 fsync のパフォーマンスオーバーヘッドを回避できます。

コミット, トランザクション, 2 フェーズコミットも参照

ア

アトミック命令

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

アプリケーションプログラミングインタフェース (API)

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

アーリーアダプタ

ソフトウェア製品が一般的に重要度の低い設定でパフォーマンス、機能、および互換性について評価される、ベータに類似した段階。InnoDB では、ベータではなく、継続的なポイントリリースを経てしだいに GA リリースに至る、アーリーアダプタ名称を使用します。

ベータ, GAも参照

圧縮

使用するディスク領域の縮小、実行する I/O の減少、および使用するキャッシュ用のメモリーの軽減による幅広いメリットを伴う機能。データベース操作中、InnoDB テーブルおよびインデックスデータは圧縮形式で保持できます。

データはクエリーで必要になると圧縮解除され、DML 操作によって変更が行われると再圧縮されます。テーブルの圧縮を有効にしたあと、この処理はユーザーとアプリケーション開発者に対して透過的です。DBA は、information_schema テーブルを参照して、圧縮パラメータが MySQL インスタンスおよび特定の圧縮テーブルに対してどれだけ効率的に機能するかをモニターできます。

InnoDB テーブルデータが圧縮されると、圧縮はテーブル自体、関連付けられたインデックスデータ、およびバッファープールにロードされたページに適用されます。圧縮は、Undo バッファー内のページに適用されません。

テーブル圧縮機能では、MySQL 5.5 以降、または MySQL 5.1 以前の InnoDB Plugin を使用する必要があり、innodb_file_per_table 設定をオンにした状態で Barracuda ファイル形式と圧縮行フォーマットを使用するテーブルを作成する必要があります。テーブルごとの圧縮は、CREATE TABLE および ALTER TABLE ステートメントの KEY_BLOCK_SIZE 句によって影響されます。MySQL 5.6 以降の圧縮は、サーバー全体の構成オプション innodb_compression_failure_threshold_pct、innodb_compression_level、および innodb_compression_pad_pct_max にも影響されます。使用法の詳細は、セクション14.7「InnoDB 圧縮テーブル」を参照してください。

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

Barracuda, バッファープール, 圧縮行フォーマット, DML, ホットバックアップ, インデックス, INFORMATION_SCHEMA, innodb_file_per_table, プラグイン, テーブル, Undo バッファーも参照

圧縮テーブル

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

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

圧縮バックアップ

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

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

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

適用, バイナリログ, 圧縮, ホットバックアップ, 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 テーブルのデータおよびインデックス圧縮を有効にする行フォーマット。これは、InnoDB Plugin で導入され、Barracuda ファイル形式の一部として利用できます。ラージフィールドは、動的行フォーマットと同様に、残りの行データを保持するページとは別に格納されます。インデックスページとラージフィールドの両方が圧縮され、メモリーとディスクの節約をもたらします。データの構造に応じて、メモリーおよびディスク使用量の減少は、使用時にデータを圧縮解除するときのパフォーマンスオーバーヘッドを上回る場合も、上回らない場合もあります。使用法の詳細は、セクション14.7「InnoDB 圧縮テーブル」を参照してください。

InnoDB COMPRESSED 行フォーマットの追加情報については、セクション14.9.3「DYNAMIC および COMPRESSED 行フォーマット」を参照してください。

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

新しい

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

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

暗黙の行ロック

明確にリクエストしなくても、InnoDB が一貫性を保証するために獲得する行ロック。

行ロックも参照

イ

インスタンス

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

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

インストゥルメンテーション

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

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

インテンションロック

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

ロック, lock mode, ロックも参照

インテンション共有ロック

インテンションロックも参照

インテンション排他ロック

インテンションロックも参照

インデックス

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

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

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

B ツリーインデックスがもっとも一般的ですが、MEMORY ストレージエンジンや InnoDB 適応型ハッシュインデックスと同様に、ハッシュインデックスには別の種類のデータ構造が使用されます。

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

インデックスキャッシュ

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

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

インデックスヒント

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

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

インデックスプリフィクス

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

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

インデックス統計

統計も参照

インメモリーデータベース

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

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

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

一時テーブル

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

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

テーブルも参照

一時テーブルスペース

非圧縮 InnoDB 一時テーブルと関連オブジェクト用のテーブルスペース。このテーブルスペースは MySQL 5.7.1 で導入されました。構成ファイルオプション innodb_temp_data_file_path は、ユーザーが一時データファイルの相対パスを定義することを許可します。innodb_temp_data_file_path が指定されない場合のデフォルト動作は、データディレクトリ内に ibdata1 と一緒に、ibtmp1 という名前の単一自動拡張 12M バイトデータファイルを作成することです。一時テーブルスペースは、サーバー起動ごとに再作成され、動的に生成されるスペース ID を受け取ります。これは、既存のスペース ID との競合回避に役立ちます。一時テーブルスペースを raw デバイスに置くことはできません。一時テーブルを作成できないときまたは作成時のエラーは致命的と扱われ、サーバー起動が拒否されます。

このテーブルスペースは、通常シャットダウンまたは初期中断 (たとえば、ユーザーが間違った起動オプションを指定したときに発生する可能性がある) 時は削除されます。一時テーブルスペースはクラッシュ発生時は削除されません。この場合、データベース管理者はこのテーブルスペースを手動で削除したり、同じ構成でサーバーを再起動 (一時テーブルスペースが削除されて再作成されます) したりできます。

ibtmp ファイルも参照

一般クエリーログ

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

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

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

一般ログ

一般クエリーログも参照

一貫性読み取り

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

反復可能読み取り分離レベルでは、スナップショットは最初の読み取り操作が実行された時点に基づきます。コミットされた読み取り分離レベルでは、スナップショットはそれぞれの一貫性読み取り操作の時点にリセットされます。

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

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

ACID, 並列性, 分離レベル, ロック, MVCC, READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, トランザクション, Undo ログも参照

ウ

ウォームアップ

起動後の一定期間、標準的なワークロードでシステムを実行すること。通常の状況時のようにバッファープールとほかのメモリー領域がいっぱいになります。

このプロセスは、MySQL Server が再起動したり新しいワークロードを課せられたりしたときに、一定時間をかけて自然に発生します。MySQL 5.6 以降では、構成変数 innodb_buffer_pool_dump_at_shutdown=ON および innodb_buffer_pool_load_at_startup=ON を設定して再起動後にバッファープールの内容をメモリーに戻すことによって、ウォームアッププロセスを高速化できます。通常は、複数の実行間で一貫した結果を保証するために、一定期間ワークロードを実行してバッファープールをウォームアップしてから、パフォーマンステストを実行してください。そのようにしない場合、パフォーマンスが最初の実行中に不自然に低くなる場合があります。

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

ウォームバックアップ

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

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

エ

エクステント

テーブルスペース内のページのグループ。16K バイトのデフォルトページサイズでは、エクステントに 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 アルゴリズムを使用して、削除する項目を決定します。ダーティーページが削除されるとき、その内容はディスクにフラッシュされ、隣接するダーティーページもフラッシュされる可能性があります。

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

エラーログ

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

クラッシュ, ログも参照

永続的統計

MySQL 5.6 の機能の 1 つ。ディスク上の InnoDB テーブルのインデックス統計を格納し、クエリーの計画安定性が向上します。詳細は、セクション14.13.16.1「永続的オプティマイザ統計のパラメータの構成」を参照してください。

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

オ

オフページカラム

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

B ツリー, Barracuda, オーバーフローページも参照

オプション

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

InnoDB テーブルに適用されるオプションの場合、各オプション名はプリフィクス innodb_ で始まります。

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

オプションファイル

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

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

オプティマイザ

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

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

オプティミスティック

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

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

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

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

オンライン

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

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

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

オンライン DDL

DDL (主に ALTER TABLE) 操作中の InnoDB テーブルのパフォーマンス、並列性、および可用性を改善する機能。詳細は、セクション14.11「InnoDB とオンライン DDL」を参照してください。

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

この機能は、MySQL 5.5、および MySQL 5.1 用の InnoDB Plugin の高速インデックス作成機能の拡張です。

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

オーバーフローページ

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

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

親テーブル

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

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

カ

カウンタ

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

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

カバリングインデックス

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

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

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

カラム

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

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

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

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

カラムインデックス

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

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

カラムプリフィクス

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

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

インデックスも参照

カーソル

クエリー、または SQL WHERE 句を使用する検索を実行するほかの操作の結果セットを表すために使用される内部データ構造。これは、ほかの高級言語でのイテレータのように機能し、リクエストに応じて結果セットからそれぞれの値を生成します。

通常は 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 万行を返します。このような場合、どのルックアップ方法が特定のクエリーにより効率的かについてアドバイスを伝えるために、インデックスヒントを使用する必要があります。

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

InnoDB の場合、インデックスのカーディナリティーを見積もるプロセスは、innodb_stats_sample_pages および innodb_stats_on_metadata 構成オプションの影響を受けます。永続的統計機能が有効のときは、見積もられる値はより安定します (MySQL 5.6 以降)。

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

一意のインデックス

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

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

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

一意のキー

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

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

一意制約

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

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

可用性

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

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

外部キー

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

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

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

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

完全バックアップ

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

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

書き込み結合

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

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

関連性

全文検索機能で、検索文字列と FULLTEXT インデックス内のデータとの間の類似性を示す数字。たとえば、単一語を検索するときに、その語は通常、一度だけ現れる行よりも、テキストに複数回発生した行に高い関連性があります。

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

キ

キャッシュ

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

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

ギャップ

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

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

ギャップロック

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

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

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

共有テーブルスペース

システムテーブルスペースを参照する別の方法。

システムテーブルスペースも参照

共有ロック

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

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

切り捨て

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

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

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

疑似レコード

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

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

起動

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

シャットダウンも参照

逆引用符

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

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

SQLも参照

ク

クエリー

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

これまでの経緯が理由で、ステートメントの内部処理のディスカッションでは (DDL および DML ステートメントなどのほかのタイプの MySQL ステートメントを含めて)、「クエリー」をより広い意味で使用することがあります。

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

クエリーログ

一般クエリーログも参照

クエリー実行計画

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

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

クライアント

リクエストをサーバーに送信し、結果を解釈または処理するタイプのプログラム。クライアントソフトウェアは、一定の時間だけ実行する場合 (メールやチャットプログラムなど) や、インタラクティブに実行する場合 (mysql コマンドプロセッサなど) があります。

mysql, サーバーも参照

クラスタ化されたインデックス

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

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

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

クラッシュ

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

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

クラッシュリカバリ

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

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

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

クリーンシャットダウン

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

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

クリーンページ

InnoDB バッファープール内のページ の 1 つ。ここでは、メモリー内で行われたすべての変更がデータファイルにも書き込まれて (フラッシュされて) います。ダーティーページの反対です。

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

グループコミット

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

バイナリログが有効になっているときは通常、構成オプション sync_binlog=0 も設定してください。バイナリログのグループコミットは、これが 0 に設定されている場合にのみサポートされるためです。

コミット, プラグイン, XAも参照

組み込み

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

この区別は、主に MySQL 5.1 で重要です。ここでは、機能またはバグ修正が InnoDB Plugin に適用され、組み込み InnoDB にされない場合や、その反対の場合があります。

InnoDB, プラグインも参照

行ベースレプリケーション

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

自動インクリメントロック, innodb_autoinc_lock_mode, マスターサーバー, レプリケーション, スレーブサーバー, ステートメントベースレプリケーションも参照

行ロック

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

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

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

ケ

原子的

SQL コンテキストでは、トランザクションとは、完全に完了する (コミット時)、またはまったく効果がない (ロールバック時) 作業の単位です。トランザクションの分割できない (「原子的」) という特性は、頭字語 ACID の「A」に当たります。

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

厳密モード

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

MySQL にも厳密モードと呼ばれるものがあります。

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

検索インデックス

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

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

結合

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

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

計画安定性

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

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

コ

コミット

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

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

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

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

コンパクト行フォーマット

MySQL 5.0.3 以降のデフォルト InnoDB 行フォーマット。Antelope ファイル形式を使用するテーブルで利用できます。この Null および可変長フィールドの表現は、以前のデフォルト (冗長行フォーマット) よりもコンパクトです。

InnoDB の B ツリーインデックスは行ルックアップを非常に高速にするため、すべての行を同じサイズに維持することにパフォーマンス上のメリットはほとんどありません。

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

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

コールドバックアップ

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

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

合成キー

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

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

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

固定行フォーマット

この行フォーマットは、InnoDB ではなく MyISAM ストレージエンジンで使用されます。オプション row_format=fixed を使用して InnoDB テーブルを作成する場合、InnoDB はこのオプションの代わりにコンパクト行フォーマットを使用するように変換します。ただし、SHOW TABLE STATUS レポートなどの出力には fixed 値が表示される場合があります。

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

子テーブル

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

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

構成ファイル

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

このファイルは通常、場所 /etc/my.cnf、/etc/mysql/my.cnf、/usr/local/mysql/etc/my.cnf、および ~/.my.cnf で検索されます。このファイルの検索パスの詳細は、セクション4.2.6「オプションファイルの使用」を参照してください。

MySQL Enterprise Backup 製品を使用するときには通常、2 つの構成ファイルを使用します。データが得られる場所と構造化される方法を指定するもの (実際のサーバー用の元の構成ファイルである場合もあります) と、バックアップデータの保存先とそれが構造化される方法を指定する小さなオプションセットを含む必要最低限のものです。MySQL Enterprise Backup 製品で使用される構成ファイルは通常の構成ファイルには通常は含まれていないオプションを含んでいる必要があり、その場合には既存の構成ファイルに MySQL Enterprise Backup で使用するいくつかのオプションを追加する必要がある場合があります。

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

混在モード挿入

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

レプリケーション構成のマスターおよびスレーブサーバー間で一貫性の問題を引き起こす可能性があります。innodb_autoinc_lock_mode 構成オプションの値の調整が必要な場合があります。

自動インクリメント, innodb_autoinc_lock_mode, マスターサーバー, レプリケーション, スレーブサーバーも参照

降順インデックス

一部のデータベースシステムで利用できるタイプのインデックス。ここでは ORDER BY column DESC 句を処理するようにインデックスストレージが最適化されます。現在のところ、MySQL は、CREATE TABLE ステートメントで DESC キーワードを許可しますが、結果のインデックスに特殊なストレージレイアウトを使用しません。

インデックスも参照

高位境界値

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

低位境界値も参照

高速インデックス作成

関連付けられたテーブルを完全に書き直す必要性をなくすことによって InnoDB セカンダリインデックスの作成を高速化する、InnoDB Plugin に最初に導入されて現在 5.5 以降の MySQL Server に組み込まれている機能。高速化はセカンダリインデックスの削除にも適用されます。

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

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

関連情報については、InnoDB Fast Index Creationおよびセクション14.11「InnoDB とオンライン DDL」を参照してください。

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

高速シャットダウン

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

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

サ

サブリスト

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

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

サロゲートキー

合成キーのシノニム名。

合成キーも参照

サーバー

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

クライアント, mysqldも参照

先読み

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

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

削除

InnoDB が DELETE ステートメントを処理すると、行が即座に削除とマークされ、これ以降クエリーから返されなくなります。ストレージは以降の任意の時点で、別のスレッドによって実行される、パージ操作と呼ばれる定期的ガベージコレクション中に解放されます。大量のデータを削除する場合、独自のパフォーマンス特性を持つ関連操作は、切り捨ておよびドロップです。

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

削除バッファリング

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

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

参照整合性

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

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

最大下限レコード

インデックス内の疑似レコードで、そのインデックスの最小値を下回るギャップを表します。トランザクションに SELECT ... FOR UPDATE ... WHERE col < 10; などのステートメントがあり、カラム内の最小値が 5 である場合、これは、ほかのトランザクションが 0 や -10 などのさらに小さな値を挿入するのを防ぐ最大下限レコードでのロックです。

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

最小上限レコード

インデックス内の疑似レコードで、そのインデックスの最大値を上回るギャップを表します。トランザクションに SELECT ... FOR UPDATE ... WHERE col > 10; などのステートメントが含まれ、カラム内の最大値が 20 の場合、これは、ほかのトランザクションが 50 や 100 などのさらに大きな値を挿入することを防ぐ最小上限レコードに対するロックです。

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

シ

システムテーブルスペース

InnoDB テーブル関連オブジェクト (データディクショナリ) と Undo ログ、変更バッファー、二重書き込みバッファーのストレージ領域のメタデータを含むデータファイル (ibdata ファイル) の小さなセット。innodb_file_per_table の設定に応じて、テーブルの作成時に一部またはすべての InnoDB テーブルのテーブルとインデックスデータが含まれる場合もあります。システムテーブルスペース内のデータとメタデータは、MySQL インスタンス内のすべてのデータベースに適用されます。

MySQL 5.6.5 で導入されたリグレッションにより、innodb_file_per_table が有効のときに、FULLTEXT インデックステーブルは独自の個々のテーブルスペースではなく InnoDB システムテーブルスペース (スペース 0) に作成されます。このバグは、MySQL 5.6.20 および MySQL 5.7.5 で修正されました (Bug#18635485)。

MySQL 5.6.7 より前のデフォルトは、すべての InnoDB テーブルとインデックスをシステムテーブルスペース内部に保持することで、多くの場合、このファイルが非常に大きくなっていました。システムテーブルスペースは決して縮小しないので、大容量の一時データがロードされてから削除された場合、ストレージの問題が発生する可能性があります。MySQL 5.6.7 以降では、デフォルトは file-per-table モードで、各テーブルとそれに関連付けられたインデックスが別個の .ibd ファイルに格納されます。この新しいデフォルトによって、テーブル圧縮や DYNAMIC 行フォーマットなど、Barracuda ファイル形式に依存する InnoDB 機能をより簡単に使用できるようになります。

MySQL 5.6 以降では、innodb_undo_tablespaces オプションの値を設定すると、Undo ログが 1 つ以上の別個のテーブルスペースファイルに分割されます。これらのファイルは引き続きシステムテーブルスペースの一部と見なされます。

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

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

シャットダウン

MySQL Server を停止させるプロセス。このプロセスはデフォルトで InnoDB テーブルのクリーンアップ操作を行うので、シャットダウンは遅くなりますが、その後の起動は速くなります。クリーンアップ操作を省略した場合、シャットダウンは速くなりますが、次の起動中にクリーンアップを行う必要があります。

シャットダウンモードは、innodb_fast_shutdown オプションで制御されます。

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

シャープチェックポイント

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

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

主キー

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

InnoDB は、すべてのテーブルにこのようなインデックス (クラスタ化されたインデックスまたはクラスタインデックスとも呼ばれます) があることを要求し、主キーのカラム値に基づいてテーブルストレージを編成します。

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

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

冗長行フォーマット

もっとも古い InnoDB 行フォーマット。Antelope ファイル形式を使用するテーブルに利用できます。MySQL 5.0.3 より前は、これが InnoDB で利用できる唯一の行フォーマットでした。My SQL 5.0.3 以降では、デフォルトはコンパクト行フォーマットです。古い InnoDB テーブルとの互換性のために、冗長行フォーマットを引き続き指定できます。

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

Antelope, コンパクト行フォーマット, ファイル形式, 行フォーマットも参照

準備されたバックアップ

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

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

自動インクリメント

カラム内に昇順で値を自動的に追加する、テーブルカラムのプロパティー (AUTO_INCREMENT キーワードで指定します)。InnoDB は主キーカラムについてのみ自動インクリメントをサポートします。

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

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

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

自動インクリメントロック

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

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

自動コミット

各 SQL ステートメントのあとにコミット操作を実行する設定。このモードは、複数のステートメントにわたるトランザクションで InnoDB テーブルを操作する場合には推奨されません。これは、InnoDB テーブルでの読み取り専用トランザクションのパフォーマンスに役立つことがあります。この場合、特に MySQL 5.6.4 以降で、Undo データのロックおよび生成のオーバーヘッドを最小限に抑えます。これは、MyISAM テーブル (トランザクションが適用されない) を操作する場合にも適切です。

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

ス

スキーマ

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

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

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

データベース, ib-file セット, INFORMATION_SCHEMA, パフォーマンススキーマも参照

スケーラビリティー

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

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

スケールアウト

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

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

スケールアップ

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

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

ステミング

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

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

ステートメントベースレプリケーション

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

自動インクリメントロック, innodb_autoinc_lock_mode, マスターサーバー, レプリケーション, 行ベースレプリケーション, スレーブサーバーも参照

ストップワード

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

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

ストレージエンジン

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

MySQL Enterprise Backup 製品は、InnoDB テーブルのバックアップに最適化されています。MyISAM およびほかのストレージエンジンで扱われるテーブルもバックアップできます。

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

スナップショット

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

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

スピン

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

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

スペース ID

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 ファイルで伝えられます。詳細は、セクション14.5.5「テーブルスペースの別のサーバーへのコピー (トランスポータブルテーブルスペース)」を参照してください。

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

スレッド

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

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

スレーブサーバー

多くの場合、「スレーブ」と短縮されます。レプリケーションシナリオのデータベースサーバーマシンの 1 つ。別のサーバー (マスター) から変更を受け取り、これらの同じ変更を適用します。したがって、ある程度遅れる可能性がありますが、マスターと同じ内容を保持します。

MySQL のスレーブサーバーは一般に、ディザスタリカバリで使用され、障害の発生したマスターサーバーに代わります。これらはまた一般に、データベース構成変更がパフォーマンスや信頼性の問題を起こさないことを保証するために、ソフトウェアアップグレードと新しい設定をテストする場合にも使用されます。

スレーブサーバーは通常、ユーザークエリーと同様に、マスターからリレーされるすべての DML (書き込み) 操作を処理するので、ワークロードが高くなります。スレーブサーバーがマスターからの変更を十分高速に適用できることを保証するために、それらは多くの場合、高速 I/O デバイスおよび十分な CPU とメモリーを備えて複数のデータベースインスタンスを同じスレーブサーバー上で実行します。たとえば、マスターサーバーがハードドライブストレージを使用し、スレーブサーバーが SSD を使用する場合があります。

DML, レプリケーション, サーバー, SSDも参照

スロークエリーログ

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

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

セ

セカンダリインデックス

テーブルカラムのサブセットを表すタイプの InnoDB インデックス。InnoDB テーブルは、ゼロ個、1 個、または複数個のセカンダリインデックスを持つことができます。(クラスタ化されたインデックスと対比してください。こちらは各 InnoDB テーブルに必要で、すべてのテーブルカラムのデータを格納します。)

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

セカンダリインデックスの作成および削除には従来、InnoDB テーブル内のすべてのデータをコピーするためにかなりのオーバーヘッドが必要でした。InnoDB Plugin の高速インデックス作成機能によって、InnoDB セカンダリインデックスの CREATE INDEX および DROP INDEX ステートメントの速度が向上します。

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

セグメント

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

たとえば、file-per-table テーブルスペース内で、テーブルデータは 1 セグメント内にあり、それぞれに関連付けられたインデックスがそれが属するセグメント内にあります。システムテーブルスペースは、多くのテーブルとそれらに関連付けられたインデックスを保持できるため、多くの異なるセグメントを含みます。システムテーブルスペースには、Undo ログを構成する最大 128 のロールバックセグメントも含まれます。

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

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

セーブポイント

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

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

全文検索

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

FULLTEXT インデックスも参照

制約

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

ACID, 外部キー, リレーショナル, 一意制約も参照

正規化

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

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

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

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

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

選択性

データ分布のプロパティーの 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も参照

挿入バッファリング

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

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

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

挿入バッファー

変更バッファーの旧名。変更バッファリングには、挿入だけでなく削除および更新操作が含まれるので、「変更バッファー」が望ましい用語です。

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

相互排他ロック

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

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

タ

タプル

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

カーソルも参照

ダーティーページ

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

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

ダーティー読み取り

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

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

この正反対が一貫性読み取りです。InnoDB はあらゆる手を尽くして、トランザクションが別のトランザクションによって更新された情報を読み取らないことを保証します (別のトランザクションがその間にコミットした場合でも)。

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

待機

ロック、相互排他ロック、またはラッチを獲得するなどの操作を即座に完了できないとき、InnoDB は一時停止して再試行します。この一時停止のメカニズムはかなり入念に設計されているため、この操作には独自の名前、待機が付けられています。個々のスレッドは、内部 InnoDB スケジューリング、オペレーティングシステム wait() 呼び出し、および短期間スピンループの組み合わせを使用して一時停止されます。

重い負荷と多数のトランザクションが発生するシステムでは、SHOW INNODB STATUS コマンドからの出力を使用して、スレッドに非常に多くの時間を待機に消費しているかどうか、該当する場合は並列性をどのように改善できるかを判断できます。

並列性, ラッチ, ロック, 相互排他ロック, スピンも参照

チ

チェックサム

テーブルスペース内のページがディスクから InnoDB バッファープールに読み込まれるときに破損を検出する、InnoDB での検証メカニズム。innodb_checksums 構成オプションで、この機能のオンとオフが切り替わります。MySQL 5.6 では、構成オプション innodb_checksum_algorithm=crc32 も指定することによって、高速なチェックサムアルゴリズムを有効にできます。

innochecksum コマンドは、MySQL Server がシャットダウンする間に、指定のテーブルスペースファイルのチェックサム値をテストすることによって、破損の問題の診断に役立ちます。

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

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

チェックポイント

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

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

テ

テキストコレクション

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

FULLTEXT インデックスも参照

テーブル

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

ファイルストレージの観点では、各 InnoDB テーブルは、単一の大きな InnoDB システムテーブルスペースの一部か、またはテーブルが file-per-table モードで作成される場合は別個の .ibd ファイル内です。.ibd ファイルは、テーブルとそのすべてのインデックスのデータを保持し、テーブルスペースと呼ばれます。

file-per-table テーブルで作成される InnoDB テーブルは、Barracuda ファイル形式を使用できます。Barracuda テーブルは、DYNAMIC 行フォーマットまたは COMPRESSED 行フォーマットを使用できます。これらの比較的新しい設定は、圧縮、高速インデックス作成、オフページカラムなどのいくつかの InnoDB 機能を有効にします

MySQL 5.1 以前との後方互換性のため、システムテーブルスペース内部の InnoDB テーブルは、コンパクト行フォーマットと冗長行フォーマットをサポートする Antelope ファイル形式を使用する必要があります。

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

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

テーブルの完全スキャン

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

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

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

テーブルスキャン

テーブルの完全スキャンも参照

テーブルスペース

1 つ以上の InnoDB テーブルおよび関連付けられたインデックスのデータを保持できるデータファイル。システムテーブルスペースは、データディクショナリを構成するテーブルを含み、MySQL 5.6 以前ではデフォルトでほかの InnoDB テーブルをすべて保持します。innodb_file_per_table オプションをオンにすると (MySQL 5.6 以降のデフォルト)、新しく作成されるテーブルに独自のテーブルスペース、テーブルごとに別個のデータファイルが割り当てられます。

innodb_file_per_table オプションをオンにして複数のテーブルスペースを使用することは、テーブル圧縮やトランスポータブルテーブルスペースなどの多くの MySQL 機能を使用し、ディスク使用状況を管理することにとって非常に重要です。詳細は、セクション14.5.2「InnoDB File-Per-Table モード」を参照してください。

組み込み InnoDB ストレージエンジンで作成されるテーブルスペースは、InnoDB Plugin と上方互換です。InnoDB Plugin で作成されるテーブルスペースは、Antelope ファイル形式を使用する場合は、組み込み InnoDB ストレージエンジンと下方互換です。

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

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

テーブルスペースディクショナリ

InnoDB テーブルスペース内で、テーブルのデータディクショナリメタデータの表現。テーブルが開かれるときにこのメタデータを .frm ファイルに対して一貫性をチェックすることで、古い .frm ファイルが原因のエラーを診断できます。この情報は、システムテーブルスペースの一部である InnoDB テーブルと、file-per-table オプションのために独自の .ibd ファイルを持つテーブルに提示されます。

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

テーブルタイプ

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

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

テーブルロック

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

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

テーブル統計

統計も参照

ディスクバウンド

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

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

ディスクベース

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

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

デッドロック

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

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

デッドロックの可能性を減らすには、LOCK TABLE ステートメントではなくトランザクションを使用したり、データを挿入または更新するトランザクションを長期間開かないでいいように小さくしたり、さまざまなトランザクションが複数のテーブルまたは大きな範囲の行を更新するときに、各トランザクションで同じ操作順序を使用したり (SELECT ... FOR UPDATE など)、SELECT ... FOR UPDATE および UPDATE ... WHERE ステートメントで使用されるカラムにインデックスを作成したりしてください。デッドロックの可能性は、分離レベルに影響を受けません。分離レベルは読み取り操作の動作を変更し、デッドロックは書き込み操作のために発生するからです。

デッドロックが発生した場合、InnoDB は状況を検出し、いずれかのトランザクション (デッドロック対象) をロールバックします。したがって、アプリケーションロジックが完全に正しい場合でも、トランザクションを再試行する必要があるケースを扱う必要があります。InnoDB ユーザートランザクションでの最後のデッドロックを確認するには、コマンド SHOW ENGINE INNODB STATUS を使用してください。デッドロックが頻繁に発生して、トランザクション構造やアプリケーションエラー処理に問題があるらしいと思われる場合は、mysqld エラーログにすべてのデッドロックに関する情報を出力するために、innodb_print_all_deadlocks 設定を有効にした状態で実行してください。

自動的にデッドロックを検出して処理する方法に関する背景情報については、セクション14.2.10「デッドロックの検出とロールバック」を参照してください。デッドロック状況を回避しリカバリするためのヒントについては、セクション14.2.11「デッドロックの対処方法」を参照してください。

並列性, ギャップ, 分離レベル, ロック, ロック, ロールバック, トランザクション, デッドロック対象も参照

デッドロック対象

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

デッドロック, デッドロック検出, innodb_lock_wait_timeoutも参照

デッドロック検出

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

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

データウェアハウス

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

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

データディクショナリ

テーブル、インデックス、テーブルカラムなどの InnoDB 関連オブジェクトを追跡するメタデータ。このメタデータは、InnoDB システムテーブルスペースに物理的に置かれています。これまでの経緯が理由で、これは .frm ファイルに格納された情報とある程度重複します。

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

カラム, .frm ファイル, ホットバックアップ, インデックス, MySQL Enterprise Backup, システムテーブルスペース, テーブルも参照

データディレクトリ

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

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

データファイル

物理的に InnoDB テーブルおよびインデックスデータを含むファイル。システムテーブルスペース (データディクショナリと同様に複数の InnoDB テーブルを保持できる) の場合のように、データファイルとテーブルとの間に 1 対多関係が存在することがあります。file-per-table 設定が有効で、新しく作成する各テーブルが個別のテーブルスペースに格納されるときのように、データファイルとテーブルとの間に 1 対 1 関係が存在することもあります。

データディクショナリ, file-per-table, インデックス, システムテーブルスペース, テーブル, テーブルスペースも参照

データベース

MySQL データディレクトリ内では、各データベースは個別のディレクトリで表されます。InnoDB システムテーブルスペース (MySQL インスタンス内で複数のデータベースからテーブルデータを保持できる) は、個々のデータベースディレクトリの外部に存在するそのデータファイルに保持されます。file-per-table モードが有効のときは、個々の InnoDB テーブルを表す .ibd ファイルがデータベースディレクトリ内部に格納されます。

長年 MySQL を使用している人にとって、データベースはなじみ深い概念です。Oracle Database のバックグラウンドを持つユーザーは、MySQL でのデータベースの意味は Oracle Database でスキーマと呼ばれているものに似ています。

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

データ定義言語

DDLも参照

データ操作言語

DMLも参照

低位境界値

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

高位境界値も参照

低速シャットダウン

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

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

転置インデックス

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

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

適応型ハッシュインデックス

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

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

MySQL 5.6 以降では、InnoDB テーブルで高速な単一値ルックアップを利用するには、このほかに、InnoDB との memcached インタフェースを使用するという方法があります。詳細は、セクション14.18「InnoDB と memcached の統合」を参照してください。

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

適応型フラッシュ

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

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

適用

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

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

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

ト

トラブルシューティング

InnoDB の信頼性とパフォーマンスの問題をトラブルシューティングするためのリソースには、情報スキーマテーブルが含まれます。

トランザクション

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

InnoDB が実装するデータベーストランザクションには、原始性、一貫性、分離性、持続性を表す頭字語 ACID で総称される特性があります。

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

トランザクション ID

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

暗黙の行ロックも参照

トランスポータブルテーブルスペース

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

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

ドキュメント ID

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

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

ドロップ

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

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

動的行フォーマット

InnoDB Plugin で導入された行フォーマットの 1 つ。Barracuda ファイル形式の一部として利用できます。行データを保持しているページの残りの外部に TEXT および BLOB フィールドが格納されるので、これはラージオブジェクトを含む行にとって非常に効率的です。ラージフィールドは通常、クエリー条件を評価するためにアクセスされることはないので、頻繁にはバッファープールに読み込まれません。その結果、I/O 操作は少なくなり、キャッシュメモリーの利用率が改善します。

InnoDB DYNAMIC 行フォーマットの追加情報については、セクション14.9.3「DYNAMIC および COMPRESSED 行フォーマット」を参照してください。

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

統計

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

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

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

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

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

ナ

ナチュラルキー

値が現実世界の何らかの意味を持つインデックスカラム (通常は主キー)。通常は、次の理由のため推奨されていません。

• 値が万が一変化した場合、クラスタ化されたインデックスを再ソートし、それぞれのセカンダリインデックスで繰り返される主キー値のコピーを更新するために、多数インデックス保守が必要になる可能性があります。

• 一見したところ安定した値でも、データベースで正しく表すことが難しい予測不可能な変化をすることがあります。たとえば、1 つの国が 2 つ以上に分かれ、元の国コードが古くなることがあります。または、一意値に関するルールに例外が発生する場合があります。たとえば、納税者 ID が単一の人物に一意であるように意図されている場合でも、データベースでは、ID 窃盗などでそのルールに違反するレコードを処理する必要があることがあります。また、納税者 ID やその他の機密 ID 番号からは、低品質の主キーが作成されます。それらはセキュリティー保護し、暗号化し、またはほかのカラムと異なる方法で扱う必要がある場合があるためです。

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

自動インクリメント, 主キー, セカンダリインデックス, 合成キーも参照

ニ

二重書き込みバッファー

InnoDB は、二重書き込みと呼ばれる新しいファイルフラッシュ方法を使用します。ページをデータファイルに書き込む前に、InnoDB は最初に二重書き込みバッファーと呼ばれる連続領域に書き込みます。二重書き込みバッファーへの書き込みとフラッシュが完了したあとにはじめて、InnoDB はそれらのページをデータファイル内の適切な位置に書き込みます。ページ書き込みの最中にオペレーティングシステム、ストレージサブシステム、または mysqld プロセスのクラッシュが発生した場合、InnoDB は、あとでクラッシュリカバリ中にそのページの正常なコピーを二重書き込みバッファーから見つけることができます。

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

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

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

ネ

ネクストキーロック

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

ギャップロック, ロック, レコードロックも参照

ハ

ハッシュインデックス

大なりや BETWEEN などの範囲演算子ではなく、等値演算子を使用するクエリーを対象とするタイプのインデックス。MEMORY テーブルに利用できます。これまでの経緯が理由でハッシュインデックスは MEMORY テーブルのデフォルトですが、そのストレージエンジンは B ツリーインデックスもサポートします。こちらのほうが汎用目的のクエリーにとって適切な選択肢であることが多いです。

MySQL には、このインデックス型のバリアントである適応型ハッシュインデックスが含まれます。これは必要に応じて実行時の条件に基づいて InnoDB テーブル用に自動的に構築されます。

適応型ハッシュインデックス, B ツリー, インデックス, InnoDBも参照

ハートビート

システムが適切に機能していることを示すために送信される定期的メッセージ。レプリケーションコンテキストでは、マスターがこのようなメッセージの送信を停止した場合、スレーブの 1 つがそれに代わることができます。クラスタ環境内のすべてのサーバーが正しく動作していることを確認するために、それらの間で類似の方法を使用できます。

レプリケーションも参照

バイナリログ

テーブルデータを変更しようとするすべてのステートメントのレコードを含むファイル。レプリケーションシナリオでスレーブサーバーを最新にしたり、バックアップからテーブルデータをリストアしたあとでデータベースを最新にしたりするために、これらのステートメントを再現できます。バイナリロギング機能は、オンとオフを切り替えられますが、レプリケーションを使用したりバックアップを実行したりする場合は、常に有効にしておくことをお勧めします。

mysqlbinlog コマンドを使用することによって、バイナリログの内容を調べたり、レプリケーションまたはリカバリ中にこれらのステートメントを再現したりできます。バイナリログの詳細は、セクション5.2.4「バイナリログ」を参照してください。バイナリログに関連した MySQL 構成オプションについては、セクション17.1.4.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 以降では、innodb_buffer_pool_dump_at_shutdown や innodb_buffer_pool_load_at_startup などの InnoDB 構成変数セットを通じて、シャットダウンおよび再起動中に自動的に、または随時手動で、バッファープールの内容をダンプおよびリストアすることもできます。

バッファープールインスタンス, LRU, ページ, ウォームアップも参照

バッファープールインスタンス

バッファープールは複数の領域に分割できますが、そのいずれか。innodb_buffer_pool_instances 構成オプションで制御されます。innodb_buffer_pool_size で指定された総メモリーサイズは、すべてのインスタンスに配分されます。複数のバッファープールインスタンスは通常、数 G バイトを InnoDB バッファープールに、1G バイト以上を各インスタンスに割り当てるシステムに適しています。多くの並列セッションからの大容量のデータをバッファープールにロードしそこで検索するシステム上では、複数のインスタンスがあれば、バッファープールを管理するデータ構造への排他的アクセスに対する競合が軽減します。

バッファープールも参照

バディーアロケータ

InnoDB バッファープールでさまざまなサイズのページを管理するためのメカニズム。

バッファープール, ページ, page sizeも参照

パフォーマンススキーマ

performance_schema スキーマは (MySQL 5.5 以降)、MySQL Server の多くの内部パーツのパフォーマンス特性に関する詳細情報を取得するために照会できる、テーブルセットを提供します。

ラッチ, 相互排他ロック, rw ロック (読み書きロック)も参照

パージ

別個のスレッドによって実行されるタイプのガベージコレクション。定期的スケジュールで実行されます。パージにはこれらのアクションが含まれます: インデックスから古い値を削除する、以前の DELETE ステートメントで削除とマークされた行を物理的に削除する。

クラッシュリカバリ, 削除, 二重書き込みバッファーも参照

パージスレッド

InnoDB プロセス内のスレッドの 1 つで、定期パージ操作を実行するためのもの。MySQL 5.6 以降では、複数のパージスレッドが innodb_purge_threads 構成オプションによって有効になっています。

パージ, スレッドも参照

パージバッファリング

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

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

パージ遅延

InnoDB 履歴リストの別の名前。innodb_max_purge_lag 構成オプションに関連しています。

履歴リスト, パージも参照

半一貫性読み取り

UPDATE ステートメントで使用されるタイプの読み取り操作。コミットされた読み取りと一貫性読み取りの組み合わせ。UPDATE ステートメントがすでにロックされている行を調べるとき、行が UPDATE の WHERE 条件に一致しているかどうかを MySQL が判断できるように、InnoDB は最後にコミットされたバージョンを MySQL に返します。行が一致する場合 (更新する必要がある場合)、MySQL は行を再度読み取り、InnoDB は今度はそれをロックするか、そのロックを待機します。このタイプの読み取り操作は、トランザクションの分離レベルがコミットされた読み取りで場合、または innodb_locks_unsafe_for_binlog オプションが有効である場合にのみ発生できます。

一貫性読み取り, 分離レベル, READ COMMITTEDも参照

反復不可能読み取り

あるクエリーがデータを取得し、同じトランザクション内のその後のクエリーが同じデータであるはずのものを取得するけれども、それらのクエリーが異なる結果を返す状況 (その間にコミットしている別のトランザクションによって変更された)。

この種の操作は、データベース設計の ACID 原則に反します。トランザクション内のデータは、予測可能で安定した関係を持ち、一貫しているべきです。

さまざまな分離レベルの中で、反復不可能読み取りは、シリアライズ可能読み取りと反復可能読み取りレベルによって防止され、一貫性読み取りとコミットされていない読み取りレベルで許可されます。

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

排他ロック

ほかのトランザクションが同じ行をロックするのを回避するタイプのロック。この種のロックは、トランザクション分離レベルに応じて、ほかのトランザクションが同じ行に書き込むのをブロックしたり、ほかのトランザクションが同じ行を読み取るのをブロックしたりできます。デフォルト InnoDB 分離レベル、REPEATABLE READ は、排他ロックを持つ行をトランザクションが読み取ることを許可する (一貫性読み取りと呼ばれる方法) ことによって、より高い並列性を実現します。

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

破損ページ

I/O デバイス構成とハードウェア障害の組み合わせが原因で発生する可能性のあるエラー状況。データが InnoDB ページサイズ (デフォルトで 16K バイト) より小さなチャンクで書き出される場合、書き込み中のハードウェア障害によってページの一部だけがディスクに格納されることがあります。InnoDB 二重書き込みバッファーを使用することで、この可能性から保護されます。

二重書き込みバッファーも参照

ヒ

ビジネスルール

営利企業を運営するために使用される、ビジネスソフトウェアの基盤を形作るアクションの関係およびシーケンス。これらのルールは、法律によって規定されたり、企業ポリシーで規定されたります。慎重に計画することで、データベースでエンコードされ適用される関係と、アプリケーションロジックを通じて実行されるアクションが、企業の実際のポリシーを正確に反映し、現実の状況を扱うことができます。

たとえば、従業員が会社を退職すると、人事部からアクションシーケンスがトリガーされます。人事データベースには、雇用されたけれどもまだ就業していない人物に関するデータを表すために、柔軟性も必要になることがあります。オンラインサービスで口座を閉鎖すると、データがデータベースから削除されたり、口座が再度開設されたりした場合にリカバリできるようにデータが移動またはフラグ付けされたります。企業は、給与が負数でないなどの基本的なサニティーチェックに加えて、給与の最大、最小、および調整に関するポリシーを確立できます。小売データベースでは、同じシリアル番号の購入を複数回返すことを禁止したり、一定値を超えるクレジットカード購入を禁止したりしますが、詐欺の検出に使用されるデータベースでは、このようなことを許可する場合があります。

リレーショナルも参照

非ブロック I/O

非同期 I/Oと同じ意味を持つ業界用語。

非同期 I/Oも参照

非ロック読み取り

SELECT ... FOR UPDATE または SELECT ... LOCK IN SHARE MODE 句を使用しないクエリー。読み取り専用トランザクションでグローバルテーブルに許可される唯一の種類のクエリー。ロック読み取りの反対。

ロック読み取り, クエリー, 読み取り専用トランザクションも参照

非同期 I/O

I/O が完了するまでほかの処理の進行を許可する I/O 操作のタイプ。非ブロック I/O とも呼ばれ、AIO と略記されます。InnoDB は、実際にはリクエストされていないがすぐに必要になる可能性のあるページをバッファープールに読み取るなど、データベースの信頼性に影響を与えずに並列で実行できる操作にこのタイプの I/O を使用します。

InnoDB は従来、Windows システムでのみ非同期 I/O を使用してきました。InnoDB Plugin 1.1 および MySQL 5.5 以降から、InnoDB は Linux システムで非同期 I/O を使用します。この変更により、libaio への依存関係がもたらされます。Linux システムでの非同期 I/O は、innodb_use_native_aio オプションを使用して構成されます。これはデフォルトで有効になっています。ほかの Unix 系システムでは、InnoDB は同期 I/O だけを使用します。

バッファープール, 非ブロック I/Oも参照

非正規化

外部キーと結合クエリーでテーブルをリンクするのではなく、複数のテーブルにわたってデータを複製するデータストレージ戦略。通常はデータウェアハウスアプリケーションで使用されます。この場合、データはロード後に更新されません。このようなアプリケーションでは、更新中にデータの一貫性を維持することを簡略化するよりも、クエリーパフォーマンスが重要になります。正規化と対比してください。

データウェアハウス, 正規化も参照

フ

ファイル形式

InnoDB で各テーブルに使用される形式。通常は、各テーブルが個別の .ibd ファイルに格納されるように、file-per-table 設定が有効にされます。現在、InnoDB で利用できるファイル形式は Antelope および Barracuda と呼ばれています。各ファイル形式は、1 つ以上の行フォーマットをサポートします。Barracuda テーブルで利用できる行フォーマット、COMPRESSED および DYNAMIC は、InnoDB テーブルの新しい重要なストレージ機能を有効にします。

Antelope, Barracuda, file-per-table, .ibd ファイル, ibdata ファイル, 行フォーマットも参照

ファジーチェックポイント

データベース処理を妨害するダーティーページを一度にすべてフラッシュするのではなく、ダーティーページの小さなバッチをバッファープールからフラッシュする方法。

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

ファントム

あるクエリーの結果セットに出現するけれども、以前のクエリーの結果セットにない行。たとえば、あるクエリーがトランザクション内で 2 度実行されて、その間に別のトランザクションがそのクエリーの WHERE 句に一致する新しい行を挿入または行を更新したあとにコミットされた場合です。

この現象がファントム読み取りと呼ばれます。このことから保護することは、反復不可能読み取りよりも困難です。最初のクエリー結果セットからのすべての行をロックしても、ファントムが出現する変更は防止されないためです。

さまざまな分離レベルの中で、ファントム読み取りは、シリアライズ可能読み取りで防止され、反復可能読み取り、一貫性読み取り、およびコミットされていない読み取りレベルで許可されます。

一貫性読み取り, 分離レベル, 反復不可能読み取り, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, トランザクションも参照

フィルファクタ

InnoDB インデックスにおいて、ページが分割される前にインデックスデータで占められるページの割合。ページ間でインデックスデータが最初に分割されるときの未使用領域によって、負荷のかかるインデックス保守操作を必要とすることなく、より長い文字列値で行を更新できます。フィルファクタが低すぎた場合、インデックスは必要以上の領域を消費し、インデックスを読み取るときに余分な I/O オーバーヘッドが生じます。フィルファクタが高すぎると、カラム値の長さが増える更新で、インデックス保守の追加 I/O オーバーヘッドが生じる可能性があります。詳細は、セクション14.2.13.4「InnoDB インデックスの物理構造」を参照してください。

インデックス, ページも参照

フラッシュ

メモリー領域または一時ディスクストレージ領域にバッファリングされていた変更をデータベースファイルに書き込むこと。定期的にフラッシュされる InnoDB ストレージ構造には、Redo ログ、Undo ログ、およびバッファープールが含まれます。

フラッシュは、メモリー領域がいっぱいになってシステムが一部の領域を解放する必要があるため、コミット操作が、トランザクションからの変更を完結できることを意味するため、または低速シャットダウン操作が、すべての未処理作業を完結するべきであることを意味するため、行われます。バッファリングされているデータすべてを一度にフラッシュすることが重要でないときは、InnoDB は、ファジーチェックポイントという方法を使用して、ページの小さなバッチをフラッシュし、I/O オーバーヘッドを分散させることができます。

バッファープール, コミット, ファジーチェックポイント, 隣接ページ, Redo ログ, 低速シャットダウン, Undo ログも参照

フラッシュリスト

バッファープール内のダーティーページ (変更されて、ディスクに書き戻す必要があるページ) を追跡する内部 InnoDB データ構造。このデータ構造は、InnoDB の内部ミニトランザクションによって頻繁に更新されるため、バッファープールへの同時アクセスを許可するように独自の相互排他ロックで保護されています。

バッファープール, ダーティーページ, LRU, ミニトランザクション, 相互排他ロック, ページ, ページクリーナーも参照

ブラインドクエリー拡張

WITH QUERY EXPANSION 句で有効になる全文検索の特別なモード。これは検索を 2 度実行し、2 度目の検索には、最初の検索で検出されたドキュメントからのもっとも関連性の強い少数の単語をつなぎ合わせた、独自の検索語句を使用します。この方法は、主に短い検索語句、おそらく単一単語のみに適用されます。これは、正確な検索語句がドキュメント内で現れない場合に、関連した一致を見つけることができます。

全文検索も参照

プラグイン

MySQL 5.1 以前で、個別にインストールできる形式の InnoDB ストレージエンジン。これらのリリースに内蔵されている InnoDB に含まれない機能およびパフォーマンス拡張機能を含んでいます。

MySQL 5.5 以降の場合、MySQL 配布に InnoDB 1.1 と呼ばれる最新の InnoDB 機能およびパフォーマンス拡張機能が含まれ、個別の InnoDB Plugin は存在しません。

この区別は、主に MySQL 5.1 で重要です。ここでは、機能またはバグ修正が InnoDB Plugin に適用され、組み込み InnoDB にされない場合や、その反対の場合があります。

組み込み, InnoDBも参照

プリフィクス

インデックスプリフィクスも参照

プロセス

実行中プログラムのインスタンス。オペレーティングシステムは、複数の実行中プロセスを切り替えることで、一定程度の並列性を実現します。ほとんどのオペレーティングシステムのプロセスには、リソースを共有する複数の実行スレッドを含めることができます。スレッド間のコンテキスト切り替えは、プロセス間の同等切り替えより高速です。

並列性, スレッドも参照

分離レベル

データベース処理の基礎の 1 つ。分離は、頭字語 ACID の I です。分離レベルは、複数のトランザクションが同時に変更を行ったりクエリーを実行したりしているときに、パフォーマンスと信頼性のバランス、一貫性、結果の再現性を微調整する設定です。

もっとも高い一貫性および保護からもっとも低いものまで、InnoDB でサポートされる分離レベルは、SERIALIZABLE、REPEATABLE READ、READ COMMITTED、および READ UNCOMMITTED です。

InnoDB テーブルの多くのユーザーは、すべての操作にデフォルト分離レベル (REPEATABLE READ) を保持できます。上級ユーザーは、OLTP 処理でスケーラビリティーの境界をプッシュするとき、または小さな不整合が大量のデータの集計結果に影響しないデータウェアハウス操作中に、コミットされた読み取りレベルを選択できます。両端のレベル (SERIALIZABLE および READ UNCOMMITTED) は、処理動作をまれにしか使用されない程度に変更します。

ACID, READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ, SERIALIZABLE, トランザクションも参照

物理

ディスクブロック、メモリーページ、ファイル、ビット、ディスク読み取りなど、ハードウェア関連側面がかかわるタイプの操作。物理側面は通常、上級者レベルのパフォーマンスチューニングおよび問題診断中に重要になります。論理と対比してください。

論理, 物理バックアップも参照

物理バックアップ

実際のデータファイルをコピーするバックアップ。たとえば、MySQL Enterprise Backup 製品の mysqlbackup コマンドは物理バックアップを返します。その出力に mysqld サーバーが直接使用できるデータファイルが含まれているためです (リストア操作の速度が向上します)。論理バックアップと対比してください。

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

複合インデックス

複数のカラムを含むインデックス。

インデックス, インデックスプリフィクスも参照

部分インデックス

カラム値の一部 (通常は、長い VARCHAR 値の最初の N 文字 (プリフィクス) だけを表す) インデックス。

インデックス, インデックスプリフィクスも参照

部分バックアップ

MySQL データベースのテーブルの一部、または MySQL インスタンスのデータベースの一部を含むバックアップ。完全バックアップと対比してください。

バックアップ, 完全バックアップ, テーブルも参照

ヘ

ベータ

ソフトウェア製品の存続期間の初期段階。評価にのみ利用できる期間で、通常は確定したリリース番号や 1 未満の数がありません。InnoDB ではベータの名称を使用せず、複数のポイントリリースに進展し GA リリースに至るアーリーアダプタフェーズを使用します。

アーリーアダプタ, GAも参照

ペシミスティック

パフォーマンスまたは並列性を犠牲にして、安全性を優先する概念。リクエストまたは試行が高い割合で失敗する可能性がある場合、または失敗したリクエストの結果が深刻である場合に適しています。InnoDB は、ペシミスティックロック戦略と呼ばれるものを使用して、デッドロックの可能性を最小限に抑えます。アプリケーションレベルでは、トランザクションが必要とするすべてのロックを最初に獲得するペシミスティック戦略を使用することによって、デッドロックを回避できる可能性があります。

多くのデータベースに組み込まれているメカニズムでは、反対のオプティミスティック概念が使用されます。

デッドロック, ロック, オプティミスティックも参照

ページ

InnoDB がディスク (データファイル) とメモリー (バッファープール) 間で一度に転送するデータ量を表す単位。ページには 1 つ以上の行を含めることができます (各行のデータ量に依存)。行全体が単一ページに収まらない場合、InnoDB はその行に関する情報を 1 ページに格納できるように、追加ポインタスタイルデータ構造を設定します。

各ページにより多くのデータを収める方法の 1 つは、圧縮行フォーマットを使用ことです。BLOB またはラージテキストフィールドを使用するテーブルの場合、コンパクト行フォーマットを使用してこれらのラージカラムを残りの行とは別個に格納することで、これらのカラムを参照しないクエリーの I/O オーバーヘッドとメモリー使用量を減らすことができます。

InnoDB は、I/O スループットを増やすためにページセットをバッチとして読み書きするときは、一度に 1 エクステントを読み書きします。

MySQL インスタンス内のすべての InnoDB ディスクデータ構造は、同じページサイズを共有します。

バッファープール, コンパクト行フォーマット, 圧縮行フォーマット, データファイル, エクステント, page size, 行も参照

ページクリーナー

InnoDB バックグラウンドスレッドの 1 つ。ダーティーページをバッファープールからフラッシュします。MySQL 5.6 より前では、このアクティビティーはマスタースレッドによって実行されていました

バッファープール, ダーティーページ, フラッシュ, マスタースレッド, スレッドも参照

並列性

複数の操作 (データベース用語では、トランザクション) が互いに干渉することなく同時に実行できること。並列性はパフォーマンスにも関係しています。理論的には、ロックの効率的なメカニズムを使用して、複数の同時トランザクションの保護が最小のパフォーマンスオーバーヘッドで機能するためです。

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

変更バッファリング

変更バッファーを使用する機能の汎用用語で、挿入バッファリング、削除バッファリング、およびパージバッファリングから構成されます。SQL ステートメントから生じるインデックス変更は、通常はランダム I/O 操作を使用し、バックグラウンドスレッドによって保持されて定期的に実行されます。この操作シーケンスは、値が即座にディスクに書き込まれる場合よりも効率的に、一連のインデックス値のディスクブロックを書き込むことができます。innodb_change_buffering および innodb_change_buffer_max_size 構成オプションによって制御されます。

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

変更バッファー

セカンダリインデックス内のページへの変更を記録する特殊なデータ構造。これらの値は、SQL INSERT、UPDATE、または DELETE ステートメント (DML) の結果として発生する可能性があります。変更バッファーを使用する一連の機能は、まとめて変更バッファリングと呼ばれ、挿入バッファリング、削除バッファリング、およびパージバッファリングから構成されています。

セカンダリインデックスからの関連ページがバッファープールに存在しない場合、変更は変更バッファーにのみ記録されます。関連付けられた変更が変更バッファー内にまだあるときに該当するインデックスページがバッファープールに読み取られた場合、そのページに関する変更は、変更バッファーからのデータを使用してバッファープールに適用 (マージ) されます。システムがほとんどアイドル状態になっているとき、または低速シャットダウン中に実行するパージ操作は、定期的に新しいインデックスページをディスクに書き込みます。パージ操作は、それぞれの値を即座にディスクに書き込む場合よりも効率的に、一連のインデックス値のディスクブロックを書き込むことができます。

物理的に変更バッファーは、システムテーブルスペースの一部なので、インデックス変更はデータベースの再起動をまたがってバッファーに残ります。変更は、ほかの読み取り操作によってページがバッファープールに読み取られたときにのみ、適用 (マージ) されます。

変更バッファーに格納されたデータの種類と容量は、innodb_change_buffering および innodb_change_buffer_max_size 構成オプションで制御されます。変更バッファー内の現在のデータに関する情報を確認するには、SHOW ENGINE INNODB STATUS コマンドを発行してください。

以前には挿入バッファーと呼ばれていました。

バッファープール, 変更バッファリング, 削除バッファリング, DML, 挿入バッファー, 挿入バッファリング, マージ, ページ, パージ, パージバッファリング, セカンダリインデックス, システムテーブルスペースも参照

ホ

ホット

行、テーブル、または内部データ構造が非常に頻繁にアクセスされ、何らかの形式のロックまたは相互排他が必要になり、結果としてパフォーマンスまたはスケーラビリティーの問題が発生する状況。

「ホット」は一般に望ましくない状態を示しますが、ホットバックアップは優先されるタイプのバックアップです。

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

ホットバックアップ

データベースが実行中で、アプリケーションがそれに対して読み取りおよび書き込みを行なっている間に取得されるバックアップ。バックアップはデータファイルを単純にコピーするだけではありません。バックアップが進行していた間に挿入または更新されたデータを含める必要があり、バックアップが進行していた間に削除されたデータを排除する必要があり、コミットされなかった変更を無視する必要があります。

InnoDB テーブルだけでなく、特に MyISAM およびほかのストレージエンジンからのテーブルのホットバックアップも実行する Oracle 製品は、MySQL Enterprise Backup として知られています。

ホットバックアッププロセスは 2 つのステージから構成されます。データファイルの初期コピーは raw バックアップを生成します。適用ステップにより、バックアップの実行中に行われたデータベースへの変更が組み込まれます。変更の適用により、準備されたバックアップが生成されます。これらのファイルは、必要な場合はいつでもリストアできる状態です。

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

ボトルネック

システム内で、全体的なスループットを制限する影響を持つ、サイズまたは容量に制約がある部分。たとえば、メモリー領域が必要な容量に満たないことがありますが、この場合、必要な単一リソースにアクセスするだけで、複数の CPU コアが同時に実行できなくなったり、ディスク I/O が完了するまで待機することで、CPU がフル稼働できなくなったりする可能性があります。ボトルネックを取り除くと、並列性が改善する傾向があります。たとえば、複数の InnoDB バッファープールインスタンスを持つことができれば、複数のセッションが同時にこのバッファープールに対して読み取り/書き込みするときの競合が軽減します。

バッファープール, 並列性も参照

ポイントインタイムリカバリ

特定日時のデータベースの状態を再作成するためにバックアップをリストアするプロセス。一般に PITR と略記されます。指定した時間がバックアップの時点に正確に対応する可能性は低いので、この方法は通常、物理バックアップおよび論理バックアップと組み合わせる必要があります。たとえば、MySQL Enterprise Backup 製品では、指定した特定の時点より前に取得した最後のバックアップをリストアしてから、そのバックアップ時点から PITR 時点までのバイナリログから変更を再現します。

バックアップ, 論理バックアップ, MySQL Enterprise Backup, 物理バックアップ, PITRも参照

マ

マスターサーバー

よく「マスター」と短縮されます。レプリケーションシナリオでのデータベースサーバーマシンで、データの初期挿入、更新、および削除リクエストを処理します。これらの変更は、スレーブサーバーと呼ばれるほかのサーバーに伝播されて、再現されます。

レプリケーション, スレーブサーバーも参照

マスタースレッド

バックグラウンドでさまざまなタスクを実行する InnoDB スレッド。これらのタスクのほとんどは、挿入バッファーからの変更を適切なセカンダリインデックスに書き込むなど、I/O 関連です。

並列性を改善するために、アクションがマスタースレッドから個別のバックグラウンドスレッドに移される場合があります。たとえば、MySQL 5.6 以降では、ダーティーページは、マスタースレッドではなくページクリーナースレッドで、バッファープールからフラッシュされます。

バッファープール, ダーティーページ, フラッシュ, 挿入バッファー, ページクリーナー, スレッドも参照

マルチコア

MySQL Server などのマルチスレッドプログラムを活用できるタイプのプロセッサ。

マルチバージョン並列性制御

MVCCも参照

マージ

ページがバッファープールに読み込まれたときや、変更バッファーに記録された適用可能な変更がバッファープール内のページに組み込まれたときなどに、メモリーにキャッシュされたデータに変更を適用すること。更新されたデータは最終的に、フラッシュメカニズムによってテーブルスペースに書き込まれます。

バッファープール, 変更バッファー, フラッシュ, テーブルスペースも参照

ミ

ミッドポイント挿入戦略

InnoDB バッファープールリストの「最新の」末尾ではなく、中間のどこかにページを最初に読み込ませる方法。このポイントの正確な位置は、innodb_old_blocks_pct オプションの設定に基づいて変わります。その意図は、フルテーブルスキャン中などに一度だけ読み取られるブロックが、厳密な LRU アルゴリズムを使用した場合よりも早くバッファープールからエージアウトできるということです。

バッファープール, テーブルの完全スキャン, LRU, ページも参照

ミニトランザクション

DML 操作中に内部データ構造に物理レベルで変更を行うときの、InnoDB 処理の内部フェーズ。ミニトランザクション (mtr) にはロールバックの概念はありません。単一トランザクション内で複数のミニトランザクションを発生できます。ミニトランザクションは、クラッシュリカバリ中に使用される Redo ログに情報を書き込みます。ミニトランザクションは、たとえばバックグラウンドスレッドによるパージ処理中など、通常のトランザクションのコンテキスト外でも発生できます。

コミット, クラッシュリカバリ, DML, 物理, パージ, Redo ログ, ロールバック, トランザクションも参照

メ

メタデータロック

別のトランザクションによって同時に使用されているテーブルでの DDL 操作を防止するタイプのロック。詳細は、セクション8.10.4「メタデータのロック」を参照してください。

オンライン操作への拡張機能は (特に MySQL 5.6 以降)、メタデータロックの量を減らすことに注力しています。その目標は、ほかのトランザクションによってテーブルに照会や更新などが行われている間に、テーブル構造を変更しない DDL 操作 (InnoDB テーブルに対する CREATE INDEX や DROP INDEX など) を進行できるようにすることです。

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

メトリックカウンタ

MySQL 5.6 以降で、information_schema の innodb_metrics テーブルによって実装された機能。低レベル InnoDB 操作に関するカウントおよび合計を照会し、その結果を performance_schema からのデータと組み合わせてパフォーマンスチューニングに使用できます。

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

ユ

行

カラムセットによって定義される論理データ構造。行セットがテーブルを構成します。InnoDB データファイル内で、各ページには 1 つまたは複数の行を含められます。

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

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

行フォーマット

InnoDB テーブルからの行のディスクストレージフォーマット。InnoDB に圧縮などの新しい機能が用意されるのに伴い、ストレージの効率性とパフォーマンスの向上をサポートするために新しい行フォーマットが導入されます。

テーブルごとに独自の行フォーマットがあり、ROW_FORMAT オプションを通じて指定されます。各 InnoDB テーブルの行フォーマットを確認するには、コマンド SHOW TABLE STATUS を発行します。システムテーブルスペース内のすべてのテーブルが同じ行フォーマットを共有するので、ほかの行フォーマットを活用するには通常、各テーブルは個別のテーブルスペースに格納されるように innodb_file_per_table オプションを設定する必要があります。

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

行レベルロック

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

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

ヨ

読み取りビュー

InnoDB の MVCC メカニズムで使用される内部スナップショット。ある種のトランザクションは、その分離レベル に応じて、トランザクション (または、場合によってはステートメント) が開始した時点のデータ値を見ます。読み取りビューを使用する分離レベルは、REPEATABLE READ、READ COMMITTED、および READ UNCOMMITTED です。

分離レベル, MVCC, READ COMMITTED, READ UNCOMMITTED, REPEATABLE READ, トランザクションも参照

読み取り専用トランザクション

トランザクションごとの読み取りビューを作成することに関係する管理の一部を省略することによって、InnoDB テーブルに最適化できるタイプのトランザクション。非ロック読み取りクエリーだけを実行できます。構文 START TRANSACTION READ ONLY で明示的に開始したり、特定の条件下で自動的に開始したりできます。詳細は、セクション14.13.14「InnoDB の読み取り専用トランザクションの最適化」を参照してください。

非ロック読み取り, 読み取りビュー, トランザクションも参照

ラ

ラッチ

独自の内部メモリー構造にロックを実装するために InnoDB で使用される軽量構造で、通常はミリ秒またはマイクロ秒単位で計測される短い期間保持されます。相互排他ロック (排他アクセスの場合) と読み書きロック (共有アクセスの場合) の両方を含む一般用語。ある種のラッチは、データディクショナリ相互排他ロックなど、InnoDB パフォーマンスチューニングにとって重要です。ラッチの使用と競合に関する統計は、パフォーマンススキーマインタフェースから入手できます。

データディクショナリ, ロック, ロック, 相互排他ロック, パフォーマンススキーマ, rw ロック (読み書きロック)も参照

ランダムダイブ

カラム内のさまざまな値の数 (カラムのカーディナリティー) をすばやく見積もる方法。InnoDB は、インデックスからランダムにページをサンプリングし、そのデータを使用してさまざまな値の数を見積もります。この操作は、各テーブルが最初に開かれるときに発生します。

従来は、サンプリングされるページ数は 8 に固定されていました。現在は、innodb_stats_sample_pages パラメータの設定によって決定されます。

ランダムページが選択される方法は、innodb_use_legacy_cardinality_algorithm パラメータの設定に応じて変わります。デフォルト設定 (OFF) のランダム性は古いリリースのものより向上しています。

カーディナリティーも参照

リ

リスト

InnoDB バッファープールは、メモリーページのリストとして表されます。リストは、新しいページがアクセスされてバッファープールに読み込まれたとき、バッファープール内のページが再度アクセスされてより新しいと見なされたとき、長時間アクセスされていないページがバッファープールから削除されたときに、並べ替えられます。バッファープールは、実際にはサブリストに分割され、その置換ポリシーはよく知られた LRU 手法のバリエーションです。

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

リストア

MySQL Enterprise Backup 製品からのバックアップファイルセットを MySQL で使用できるように準備するプロセス。この操作は、破損したデータベースを修復して、以前のどこか特定の時点に戻したり、(レプリケーションコンテキストで) 新しいスレーブデータベースを設定したりするために実行できます。MySQL Enterprise Backup 製品では、この操作は mysqlbackup コマンドの copy-back オプションで実行されます。

ホットバックアップ, MySQL Enterprise Backup, mysqlbackup コマンド, 準備されたバックアップ, レプリケーションも参照

リレーショナル

現代のデータベースシステムの重要な側面。データベースサーバーは、1 対 1、1 対多、多対 1、一意性などの関係をエンコードし適用します。たとえば、住所データベースでは、ある人にゼロ個、1 個、または複数個の電話番号が関連付けられていたり、単一電話番号が家族の複数のメンバーに関連付けられていたりします。金融データベースでは、1 人の人に正確に 1 つの納税者 ID が割り当てられる必要があり、納税者 ID は 1 人の人にのみ関連付けることができます。

データベースサーバーは、これらの関係を使用して、不良データが挿入されるのを防ぎ、情報をルックアップする効率的な方法を見つけることができます。たとえば、値が一意であると宣言されている場合、サーバーは、最初の一致が見つかるとすぐに検索を停止し、同じ値の 2 番目のコピーを挿入しようとする試みを拒否できます。

データベースレベルではこれらの関係は、テーブル内のカラム、一意および NOT NULL 制約、外部キー、さまざまな種類の結合操作などの SQL 機能を通じて表されます。複雑な関係には通常、複数のテーブル間で分割されたデータが使用されます。多くの場合、データは正規化されるので、1 対多の関係での重複値は一度だけ格納されます。

数学的なコンテキストでは、データベース内の関係は集合論から派生されます。たとえば、WHERE 句の OR および AND 演算子は、論理和と論理積の概念を表します。

ACID, 制約, 外部キー, 正規化も参照

履歴リスト

削除マークが付けられたレコードが InnoDB パージ操作で処理されるようにスケジュールされているトランザクションのリスト。Undo ログに記録されます。履歴リストの長さはコマンド SHOW ENGINE INNODB STATUS で報告されます。履歴リストが innodb_max_purge_lag 構成オプションの値よりも長くなった場合、パージ操作が削除済みレコードのフラッシュを完了できるように各 DML 操作が少し遅くなります。

パージラグとも呼ばれます。

フラッシュ, パージ, パージ遅延, ロールバックセグメント, トランザクション, Undo ログも参照

隣接ページ

特定のページと同じエクステント内のページ。ページがフラッシュの対象として選択されると、ダーティーである隣接ページがある場合は、通常はそれらも従来ハードディスクの I/O 最適化としてフラッシュされます。MySQL 5.6 以降では、この動作は構成変数 innodb_flush_neighbors で制御できます。小さなデータバッチをランダムな場所に書き込むため同じオーバーヘッドは発生しない SSD ドライブでは、この設定をオフにできます。

ダーティーページ, エクステント, フラッシュ, ページも参照

レ

レコードロック

インデックスレコードでのロック。たとえば、SELECT c1 FOR UPDATE FROM t WHERE c1 = 10; は、ほかのトランザクションの、t.c1 の値が 10 である行が挿入、更新、削除されるのを回避します。ギャップロックおよびネクストキーロックと対比してください。

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

レプリケーション

すべてのデータベースが同じデータを持つように、マスターデータベースから 1 つまたは複数のスレーブデータベースに変更を送信する作業。この方法は、スケーラビリティー向上のためのロードバランシング、ディザスタリカバリ、ソフトウェアアップグレードおよび構成変更のテストなど、幅広く使用されます。変更は、行ベースレプリケーションおよびステートメントベースレプリケーションと呼ばれる方法によって、データベース間で送信できます。

行ベースレプリケーション, ステートメントベースレプリケーションも参照

連結されたインデックス

複合インデックスも参照

ロ

ログ

InnoDB コンテキストでは、「ログ」または「ログファイル」は通常、ib_logfile* ファイルによって表される Redo ログを示します。もう 1 つのログ領域 (物理的にはシステムテーブルスペースの一部) は Undo ログです。

MySQL で重要なほかの種類のログには、エラーログ (起動および実行時の問題を診断するため), バイナリログ (レプリケーションを操作し、特定時点のリストアを実行するため)、一般クエリーログ (アプリケーションの問題を診断するため)、およびスロークエリーログ (パフォーマンスの問題を診断するため) があります。

バイナリログ, エラーログ, 一般クエリーログ, ib_logfile, Redo ログ, スロークエリーログ, システムテーブルスペース, Undo ログも参照

ロググループ

Redo ログを構成するファイルのセット。通常、ib_logfile0 および ib_logfile1 の名前が付けられています。(この理由のため、ib_logfile と総称される場合があります。)

ib_logfile, Redo ログも参照

ログバッファー

Redo ログを構成するログファイルに書き込まれるデータを保持するメモリー領域。これは、innodb_log_buffer_size 構成オプションで制御されます。

ログファイル, Redo ログも参照

ログファイル

Redo ログを構成する ib_logfileN ファイルの 1 つ。データは、ログバッファーメモリー領域からこれらのファイルに書き込まれます。

ib_logfile, ログバッファー, Redo ログも参照

ロック

ロック戦略の一環として、テーブル、行、内部データ構造などのリソースへのアクセスを制御するオブジェクトの高レベル概念。パフォーマンスを集中的にチューニングする場合は、相互排他ロックやラッチなど、ロックを実装する実際の構造を徹底的に調べることができます。

ラッチ, lock mode, ロック, 相互排他ロックも参照

ロック

ほかのトランザクションによって照会または変更されているデータをトランザクションが見たり変更したりすることを防止するシステム。ロック戦略は、データベース操作の信頼性および一貫性 (ACID 概念の原則) と、良質な並列性に必要なパフォーマンスとのバランスを取る必要があります。ロック戦略を調整するときは、多くの場合、分離レベルを選択し、すべてのデータベース操作がその分離レベルについて安全で信頼性を持つことを保証する必要があります。

ACID, 並列性, 分離レベル, ラッチ, ロック, 相互排他ロック, トランザクションも参照

ロックエスカレーション

一部のデータベースシステムで使用される、多くの行ロックを単一テーブルロックに変換する操作。メモリー領域を節約しながら、テーブルへの並列アクセスを減らします。InnoDB は、行ロックに領域効率のよい表現を使用するので、ロックエスカレーションは必要ありません。

ロック, 行ロック, テーブルロックも参照

ロック読み取り

InnoDB テーブルでのロック操作も実行する SELECT ステートメント。SELECT ... FOR UPDATE または SELECT ... LOCK IN SHARE MODE のどちらか。トランザクションの分離レベルに応じて、デッドロックを発生させる可能性があります。非ロック読み取りの反対。読み取り専用トランザクション内のグローバルテーブルには許可されません。

デッドロック, 分離レベル, ロック, 非ロック読み取り, 読み取り専用トランザクションも参照

ロールバック

トランザクションが行なった変更を元に戻してトランザクションを終了する SQL ステートメント。これは、トランザクションで行われた変更を永続的にするコミットの反対です。

MySQL はデフォルトで、各 SQL ステートメントに続いてコミットを自動的に発行する自動コミット設定を使用します。ロールバック方法を使用する前に、この設定を変更する必要があります。

ACID, コミット, トランザクションも参照

ロールバックセグメント

Undo ログを含むストレージ領域。システムテーブルスペースの一部です。

システムテーブルスペース, Undo ログも参照

論理

テーブル、クエリー、インデックス、その他の SQL 概念など、高レベル抽象側面を含むタイプの操作。論理側面は通常、データベース管理およびアプリケーション開発を便利で使用可能なものにするために重要です。物理と対比してください。

論理バックアップ, 物理も参照

論理バックアップ

実際のデータファイルをコピーせずにテーブル構造とデータを再生成するバックアップ。たとえば、mysqldump コマンドは論理バックアップを生成します。その出力に、データを再作成できる CREATE TABLE や INSERT などのステートメントが含まれるためです。物理バックアップと対比してください。論理バックアップは柔軟性 (たとえば、リストア前に、テーブル定義を編集したりステートメントを挿入したりできます) を提供しますが、物理バックアップよりもリストアにかなり長い時間がかかる可能性があります。

バックアップ, mysqldump, 物理バックアップ, リストアも参照

ワ

ワークロード

標準またはピーク使用時にデータベースアプリケーションによって実行される、SQL およびほかのデータベース操作の組み合わせおよび量。ボトルネックを識別するパフォーマンステスト中や容量計画中に、データベースに特定のワークロードを課すことができます。

ボトルネック, CPU バウンド, ディスクバウンド, SQLも参照