MySQL高周波面接問題の魂拷問

唯一のインデックスは普通のインデックスより速いですか.なぜですか.
一意のインデックスは、通常のインデックスよりも速くないし、遅いとは限らない.

クエリーの場合、limit 1を使用する場合、1つのデータに一致した後、一意のインデックスが戻る、通常のインデックスが次のデータに一致し続ける、一致しないことが発見された後に戻る.このように唯一のインデックスは1回のマッチングが少ないように見えるが、実際にはこの消費は微々たるものである.

が更新されると、この状況は複雑になります.通常インデックスがchange bufferに記録する文は実行済みである.ユニークインデックスでは、ユニーク性を検証する必要があります.したがって、操作を続行するには、データ・ページをメモリに読み込んで競合がないと判断する必要があります.書き込みの多読が少ない場合、通常インデックスはchange bufferを用いるディスクへのアクセス回数を効果的に減少させるため、通常インデックスの性能は一意インデックスよりも高い.

MySQLはどの部分から構成されていて、それぞれ何に使いますか?

Server

コネクタ:接続の管理、権限の検証.

分析器:文法分析、文法分析.

オプティマイザ:計画生成、インデックスの選択を実行します.

アクチュエータ:記憶エンジンを操作する、実行結果を返す.

記憶エンジン:データを記憶し、読み書きインターフェースを提供する.

MySQLクエリーキャッシュにはどのような弊害があり、どのような状況で使用すべきか、8.0バージョンはクエリーキャッシュにどのような変更があるか.

クエリーキャッシュは非常に頻繁に失効する可能性があり、1つのテーブルに対して更新がある限り、そのテーブルのすべてのクエリーキャッシュが空になる.したがって、頻繁に更新テーブルでは、クエリキャッシュが必ずしも正面効果を発揮するとは限らない.

は、読み書きよりはるかに多いテーブルに対してクエリーキャッシュを用いることを考慮することができる.

8.0バージョンのクエリーキャッシュ機能が削除されました(̄.̄).

MyISAMとInnoDBの違いはどれらがあります

InnoDBはトランザクションをサポートし、MyISAMはサポートしていません.

InnoDBは行レベルロックをサポートし、MyISAMは表レベルロックをサポートする.

InnoDBはマルチバージョン同時制御(MVVC)をサポートし、MyISAMはサポートしない.

InnoDBは外部キーをサポートし、MyISAMはサポートしない.

MyISAMは全文インデックスをサポートしているが、InnoDBはサポートしていない(ただしSphinxプラグインを使用可能)

MySQLはどのように半月前のデータを回復します
ライブラリ全体のバックアップ+binlogでリカバリする.定期的にライブラリ全体をバックアップしbinlogログを保存することを前提とする.
MySQLトランザクションの独立性レベル、それぞれの特徴

未読コミット(RU):1つのトランザクションがコミットされていない場合、その変更は別のトランザクションに表示されます.

リードコミット(RC):1つのトランザクションがコミットされた後、その変更は他のトランザクションによって表示されます.

繰り返し読み取り可能(RR):1つのトランザクションの実行中に見られるデータは、常にこのトランザクションの開始時に見られるデータと一致する.もちろん、繰り返し読み取り可能な独立性レベルでは、コミットされていない変更は他のトランザクションにも表示されない.

シリアル化(S):同じ行の記録に対して、読み書きはロックされる.読み書きロックの競合が発生すると、後でアクセスするトランザクションは、実行を続行する前のトランザクションの実行が完了するまで待たなければならない.

MySQLインデックスの最適化

はできるだけプライマリ・キー・クエリーを使用する:クラスタ・インデックスにはすべてのデータが格納されており、通常のインデックス・クエリーよりもリターン・テーブルの消費量が減少する.

MySQL5.6以降、インデックスのプッシュダウン最適化を導入する、コンビネーションインデックスを適切に使用することにより、リターン判定の消費を低減する.

あるカラムのデータを頻繁に照会すると、上書きインデックスを利用してリターンテーブルを回避することが考えられる.

連合インデックスは、高周波フィールドを一番左に配置する.

データベースのパターンを簡単に説明します

第1のパターン:属性は再分割できない.

第2のパターン:1つのパターンに基づいて、データベーステーブル内の各インスタンスまたは行を唯一の地域に分割する必要がある.通常、各インスタンスの一意の識別子を格納するために、テーブルに列を追加する必要がある.この唯一の属性列は、プライマリキーまたはプライマリキーと呼ばれる.

第3のパターン:2つのパターンに基づいて、1つのデータベーステーブルに他のテーブルにすでに含まれている非プライマリキー情報が含まれていないことを要求する.したがって、第3のパターンは、以下の特徴を有する:1).各カラムには1つの値しかありません.2). 行ごとに区別できる.3). 各テーブルには、他のテーブルにすでに含む非プライマリキー情報は含まれていない.

1千万件のデータのテーブル、どのようにページを分けてクエリーします
データ量が多すぎる場合、limit offsetページはスキャンデータが多すぎるため、以降のクエリほど遅くなる.現在のページの最後のIDに合わせて照会することができる、SELECT * FROM T WHERE id > #{ID} LIMIT #{LIMIT}.もちろん、この場合のIDは秩序化する必要があり、これも秩序化IDの利点の一つである.
オーダー・テーブルのデータ量が増加するにつれて、クエリーが遅くなり、どのように処理するか
分库分表履歴受注の使用率は高くないため、高周波は最近の受注にすぎない可能性があるため、受注表を時間別に分割し、データ量の大きさに基づいて月別または年別に計算する.注文IDには、時間(例えば、雪花アルゴリズムにより生成する)が含まれることが好ましい、この場合、注文IDに基づいて直接注文記録を取得することもできるし、時間に従って照会することもできる.