MySQL 面接でよく聞かれる質問への回答

序文：

さまざまな技術職の面接では、MySQL 関連の質問がよくされるようです。開発職の面接でも運用職の面接でも、必ずデータベースに関する質問がいくつかされます。友人から、MySQL の面接の質問にどう対処するかを尋ねるプライベートメッセージがよく送られてきます。実際、面接の質問は似たようなものが多いので、事前に準備しておく必要があります。この記事では、面接でよく聞かれる質問について簡単に説明します。一緒に学びましょう。

1. リレーショナル データベースとは何ですか? MySQL についての理解について話してください。

これは、データベースに対する面接者の理解度をテストする基本的な質問です。一般的に、理解度について簡潔に整理して話すことができます。例えば：

リレーショナル データベースは、リレーショナル モデルを使用してデータを整理し、行と列の形式でデータを保存するデータベースです。リレーショナル データベースの最大の特徴は、トランザクションをサポートしていることです。一般的なリレーショナル データベースには、MySQL、Oracle、SQLServer などがあります。 MySQL は最も人気のあるオープンソース データベースです。 MySQL データベースは、サイズが小さく、速度が速く、総所有コストが低いこと、そして特にオープンソースであることから、多くの企業がコスト削減のために MySQL データベースを採用しています。現在、インターネット上の中小規模の Web サイト、特に OLTP 分野で広く使用されています。

2. MySQL の一般的なストレージ エンジンとその違いは何ですか?

この質問もよく聞かれますが、「InnoDB エンジンと MyISAM エンジンの違いは何ですか?」という質問に似ています。

一般的なストレージ エンジン:

• InnoDB: トランザクション、MVCC、外部キー、行レベル ロック、自動増分列をサポートする、MySQL のデフォルトのストレージ エンジンです。
• MyISAM: フルテキスト インデックス、圧縮、空間関数、テーブル レベルのロックをサポートし、トランザクションはサポートせず、挿入速度が高速です。
• メモリ: すべてのデータはメモリ内に保存され、データ処理速度は高速ですが、セキュリティは高くありません。
• ARCHIVE: 履歴アーカイブ テーブルによく使用され、占有するスペースが少なく、データを更新または削除することはできません。

InnoDB エンジンと MyISAM エンジンにはいくつかの違いがあります。

• InnoDB はトランザクションをサポートしますが、MyISAM はサポートしません。
• InnoDB は外部キーをサポートしますが、MyISAM はサポートしません。
• InnoDB は全文インデックスをサポートしていませんが、MyISAM はサポートしています。
• InnoDB はクラスター化インデックスであり、MyISAM は非クラスター化インデックスです。
• InnoDB はテーブル内の特定の行数を保存しませんが、MyISAM は変数を使用してテーブル全体の行数を保存します。
• InnoDB の最小のロック粒度は行ロックであり、MyISAM の最小のロック粒度はテーブルロックです。
• ストレージ構造が異なります。MyISAM テーブルは frm、MYD、MYI の 3 つのタイプに分かれており、InnoDB テーブルは一般的に frm と ibd の 2 つのタイプに分かれています。

3. MySQL インフラストラクチャについて説明します。

この質問は、面接対象者の MySQL アーキテクチャに関する理解をテストするもので、「SELECT ステートメントの実行フロー」という質問に似ています。

MySQL の論理アーキテクチャは、主に 3 つのレイヤーに分かれています。

• 最初のレイヤー: クライアント接続処理、セキュリティ認証、承認など。各クライアント接続にはサーバー上のスレッドがあり、接続によって開始された各クエリは対応する個別のスレッドで実行されます。
• 第 2 層: MySQL のコア サービス機能層。クエリ解析、分析、クエリ キャッシュ、組み込み関数、ストアド プロシージャ、トリガー、ビューなどが含まれます。選択操作では、まずクエリ キャッシュがヒットするかどうかを確認します。ヒットした場合は、キャッシュされたデータが直接返されます。ヒットしない場合は、クエリが解析され、対応する解析ツリーが作成されます。
• 3 番目のレイヤー: ストレージ エンジン。データの保存と抽出を担当します。MySQL サーバーは API を介してストレージ エンジンと通信し、さまざまなエンジン間の違いを隠します。一般的なストレージ エンジンには、InnoDB、MyISAM などがあります。

選択ステートメントの実行フロー:

• クライアントはコネクタを介して MySQL サーバーとの接続を確立し、ユーザーの読み取りおよび書き込み権限を取得してから、クエリ ステートメントを送信します。
• まず、MySQL はクエリ キャッシュ内の送信されたステートメントをクエリします。ヒットし、ユーザーがテーブルを操作する権限を持っている場合は、クエリ キャッシュ内のクエリ結果をこのクエリの結果として直接返し、クエリはここで終了します。
• クエリ キャッシュが見つからない場合、アナライザーに渡され、アナライザーがステートメントを解析してその正当性をチェックします。ステートメントが MySQL 構文仕様に準拠していない場合、エグゼキュータはエラーを報告し、クエリは終了します。
• ステートメントが有効な場合、オプティマイザーに送られ、SQL ステートメントに最適な実行プランが選択されます。
• 最後にエグゼキュータが登場します。ユーザーにテーブルを操作する権限がある場合、エグゼキュータはストレージ エンジンが提供するインターフェイスを呼び出して SQL 文を実行し、クエリ結果をクライアントに返してクエリはここで終了します。

4. よく使用されるいくつかのフィールドタイプについて説明します。

この質問は、面接対象者の MySQL フィールド タイプに関する理解をテストするもので、char と varchar の違いなど、多くの小さな質問につながる可能性があります。

よく使用されるフィールドタイプの分類:

数値型:

文字列型:

日付と時刻の種類:

int(M) の M は最大表示幅を表します。「最大表示幅」に対する最初の反応は、フィールドに格納できる値の最大幅です。int(1) を作成したので、データ 10 は格納できないと思うかもしれません。実際はそうではありません。int(5) と int(10) の格納範囲は同じです。

CHAR 型は固定長であり、MySQL は定義された文字列の長さに基づいて常に十分なスペースを割り当てます。 CHAR 値が格納される際には、指定された長さまで右側にスペースが埋め込まれ、CHAR 値が取得される際には末尾のスペースが削除されます。 VARCHAR 型は可変長文字列を格納する場合に使用します。格納時に文字数が定義した桁数に達しない場合は末尾にスペースは追加されません。 char(M) と varchar(M) の M は、保存できる文字の最大数を表します。1 つの文字、数字、漢字などは 1 文字を占めます。

5. インデックスの役割、構造、使用仕様について説明します。

インデックス作成に関する質問は非常に多いため、明確に説明するには数記事以上かかる可能性があります。以下の質問に対する答えを共有してください。

インデックス作成の目的は、クエリの効率を向上させることです。辞書のディレクトリに例えることができます。辞書コンテンツを検索するときに、ディレクトリに基づいてデータの保存場所を見つけ、直接取得することができます。インデックスはテーブル ディレクトリです。コンテンツを検索する前に、まずディレクトリ内のインデックスの場所を検索して、クエリ データをすばやく見つけることができます。

InnoDB エンジンでは、B+ ツリー インデックスが主に使用されます。各インデックスは実際には B+ ツリーです。B+ ツリーは、ディスクやその他のストレージ補助デバイス用に設計されたバランス検索ツリー (バイナリ ツリーではありません) です。B+ ツリーでは、すべてのデータがリーフ ノードにあり、各リーフ ノードには次のノードへのポインターがあり、順序付けられたリンク リストを形成します。

物理ストレージの観点から見ると、InnoDB インデックスはクラスター化インデックスとセカンダリ インデックスまたは補助インデックスに分けられます。クラスター化インデックスのリーフ ノードには、データの行全体が格納されます。クエリでクラスター化インデックスを使用する場合、必要なレコードを取得するには、クラスター化インデックスの B+ ツリーをスキャンするだけで済みます。セカンダリ インデックスを通じて完全なレコードを検索する場合は、テーブルに戻る必要があります。つまり、セカンダリ インデックスを通じて主キー値を検索し、クラスター化インデックスで完全なレコードを検索します。

インデックスの明らかな利点はクエリを高速化できることですが、インデックスの作成にはコストもかかります。まず、インデックスが作成されるたびに、そのインデックス用の B+ ツリーを作成する必要があり、追加のストレージ スペースが必要になります。次に、テーブル内のデータが追加、削除、または変更されると、インデックスも動的に維持する必要があるため、データ維持の速度が低下します。そのため、インデックスの作成と使用には原則があります。一般的に、インデックスは検索、並べ替え、グループ化、結合に使用される列に対してのみ作成されます。選択性の低い列には、できるだけインデックスを作成しないようにします。

6. MySQL トランザクションの特性と分離レベルについて説明します。

MySQL トランザクションに関連する質問もよく寄せられますが、いくつかの原則については、まだ詳細に研究する必要があります。

ACID には 4 つの特性があります。

• A (原子性): トランザクション内のすべての操作は成功するか失敗します。
• C (一貫性): データベースは常に 1 つの一貫性のある状態から別の一貫性のある状態に切り替わります。制約に違反すると、一貫性の条件は満たされません。
• I (独立性): トランザクションの実行は他のトランザクションによって妨害されることはありません。つまり、トランザクション内で使用される操作とデータは他の同時トランザクションから分離されており、同時に実行されるトランザクションは互いに干渉できません。
• D (耐久性): トランザクションがコミットされると、その変更はデータベースに永続的に保存されます。

トランザクション分離レベル:

• コミットされていない読み取り: トランザクション内の変更は、コミットされていない場合でも、他のトランザクションに表示されます。
• コミットされた読み取り: トランザクション内の変更は、コミットされた後にのみ他のトランザクションに表示されます。
• 繰り返し読み取り: トランザクション内で同じレコードを複数回クエリする場合、結果は常に一貫しています (デフォルトの分離レベル)。
• シリアル化可能: トランザクションはシリアルに実行され、読み取りはロックされ、書き込みはロックされます。

同時トランザクションによって発生する問題:

• ダーティ リード: トランザクション A はトランザクション B によってコミットされていないデータを読み取り、その後 B は操作をロールバックします。この場合、A によって読み取られたデータはダーティ データです。
• 反復不可能な読み取り: トランザクション A は同じデータを複数回読み取ります。トランザクション A がデータを複数回読み取るプロセス中に、トランザクション B がデータを更新してコミットするため、トランザクション A が同じデータを複数回読み取ると、結果に一貫性がなくなります。
• ファントム リード: ファントム リードは、繰り返し不可能なリードに似ています。これは、トランザクション A が数行のデータを読み取り、その後、別の同時トランザクション B がデータを挿入するときに発生します。後続のクエリでは、トランザクション A は、まるで錯覚のように、元々存在しなかったいくつかの追加レコードを見つけるため、ファントム リードと呼ばれます。

上記は、MySQL 面接で頻繁に聞かれる質問に対する詳細な回答です。MySQL 面接で頻繁に聞かれる質問の詳細については、123WORDPRESS.COM の他の関連記事をご覧ください。