mysql詳細

4756 ワード

mysql論理アーキテクチャ
せつぞくそう
最上位層はいくつかのクライアントと接続サービスであり、ローカルscoketの同級生と多くのクライアント/サービスエンドツールに基づいて実現されたtcp/ipのような通信を含み、主にいくつかの類似接続処理、認証認証、および関連するセキュリティスキームを完成し、この層にスレッドプールの概念を導入し、認証によって安全にアクセスしたクライアントにスレッドを提供する.同様に、このレイヤではSSLベースのセキュリティリンクが実現され、サーバはセキュリティアクセスのクライアントごとに操作権限を検証します.
サービス層
第2層のアーキテクチャは主に大多数の核心サービス機能を完成して、例えばSQLインタフェース、そしてキャッシュクエリーを完成して、SQLの分析と最適化と一部の内蔵関数の実行、すべてのストレージエンジンにまたがる機能もこの層で実現して、例えば過程、関数など、この層で、サービス層はクエリーを解析して相応の内部解析木を作成して、そして、応答の最適化を完了してクエリーテーブルの順序を確認し、インデックスを利用するかどうかなどを確認し、最後に相応の実行操作を生成し、select文であれば、サーバは内部のキャッシュをクエリーし、キャッシュ空間が十分に大きい場合、大量の読み取り操作を解決する環境でシステム性能を十分に提供することができる.
ストレージエンジン層
ストレージエンジン層、ストレージエンジンは本当にMySQLの中のデータのストレージと抽出を担当して、サーバーはAPIを通じてストレージエンジンと通信して、異なるストレージエンジンが持つ機能は異なって、このように私達は自分の実際の需要によって選択することができて、例えば:MYISAMとInnoDB.
データストア層
主に裸デバイスで動作するファイルシステムにデータを格納し、ストレージエンジンのインタラクション(ファイルシステム)を完了します.
MyISAMとInnoDBの比較
きのうてん
MyISAM
InnoDB
プライマリ外部キー
サポートされていません
サポート
取引
サポートされていません
サポート
ローテーブルロック
表ロック、1つのレコードを操作しても表全体をロックし、高同時性をサポートしません.
行ロック、1つのレコードを操作すると1行しかロックされず、高同時性に適しています.
キャッシュ
インデックスのみをキャッシュし、データはキャッシュしません.
キャッシュインデックスもデータをキャッシュし、メモリに対する要求が高く、メモリサイズが直接性能に影響する.
表領域
小さい
大きい
注目点
パフォーマンス
取引
デフォルトのインストール
はい
はい
sqlが遅い原因
  • クエリ文の効率が低い
  • インデックスが無効または作成されていない
  • join多すぎ
  • サーバパラメータ設定
  • 索引
    インデックスとは
    インデックスはデータ構造であり、クエリーの効率性を向上させる
    インデックスはデータを並べ替え、すばやく検索できます.
    データベースにはデータのほかに、特定の検索アルゴリズムを満たすデータ構造が維持されています.このデータ構造は何らかの方法でデータを指し、このようなデータ構造を利用して効率的にデータを検索することができます.このデータ構造はインデックスです.
    インデックスの利点
  • クエリー効率の向上、IOコストの削減
  • 列を並べ替え、並べ替えコスト
  • を低減する.
    インデックスの欠点
  • インデックスもテーブルであり、キー値ペアが保存され、実際のデータを指し、インデックス列にもスペースが必要です.
  • インデックスはクエリーの効率を向上させることができますが、insert、update、deleteなどの更新の効率を低下させます.テーブルを更新するとき、mysqlは新しいデータを保存するだけでなく、インデックス列の情報も更新するからです.

  • インデックス分類
  • 単一値インデックス
  • ユニークインデックス
  • 複合インデックス
  • インデックスを作成できる状況
  • プライマリ・キーによる一意のインデックスの自動作成
  • クエリー条件として頻繁に使用されるフィールドは、インデックス
  • を確立する必要があります.
  • 他のテーブルに関連付けられたフィールド、外部キーフィールドはインデックス
  • を確立する
  • クエリーのソートフィールド
  • クエリの統計またはグループ化フィールド
  • インデックスを作成しない場合
  • 表データ少ない(300万以下)
  • 頻繁に削除されるフィールド
  • データが重複して平均的なフィールドであり、このフィールドはインデックスを構築する意味がない
  • である.
    explain
    explainは、オプティマイザがsql文を実行することをシミュレートし、sql文の実行の内部原理を理解し、パフォーマンスのボトルネックを分析します.
    使用方法
    mysql> explain sql_sentence;

    さぎょう
  • テーブルの読み出し順序
  • データベース読み出しの動作タイプ
  • で使用できるインデックスは
  • です.
  • 実際に使用されるインデックスは
  • です.
  • テーブル間の参照
  • 各テーブルのロー数をオプティマイザによって問い合わせる
  • 出力情報
    id
    テーブルの読み込み順序
  • id同じ:上から下へ実行文
  • idが異なる:idが大きいほど優先度が高くなり、
  • を先に実行する.
  • idは同じでも異なっています:先にidの最大の第1個を実行して、それから平級の順序で実行して、更に1級のidの文
  • を実行します
    select_type
    クエリーのタイプ
  • simple:サブクエリまたはunion
  • を含まない単純なselectクエリ
  • primary:クエリに複雑なサブクエリが含まれている場合、最外層のクエリはこのタイプの
  • です.
  • subquery:サブクエリ
  • を含むクエリ
  • derived:一時派生テーブル
  • union:2番目のselectはunionの後
  • に現れる.
  • union result:union以降の結果
  • table
    データ対応テーブル
    type
    クエリーで使用されているタイプを表示
  • system:テーブルには1行のデータしかなく、constタイプの特例
  • である.
  • const:インデックスによって一度に見つかり、プライマリ・キーまたは一意のインデックスによって定数値と比較すると、単一テーブル・クエリ
  • に使用される1行のデータのみが一致します.
  • eq_ref:一意性インデックススキャン、各インデックスキーに対して、テーブルには1つのレコードしか一致せず、マルチテーブル・クエリー
  • に使用される.
  • ref:ユニークでないインデックススキャンは、一致するすべてのロー
  • を返します.
  • range:whereのin、between、>、<
  • などの特定の範囲の行を取得します.
  • index:テーブルのすべてのインデックスフィールドのデータを取得するためにインデックスツリーのみを巡回し、select id from table;
  • all:全テーブルスキャン、ディスクからデータを読み出し、百万レベルのデータクエリーにallが現れると
  • を最適化する必要があります.
    possible_key
    使用可能なインデックス値を表示しますが、必ずしも実際に使用されるとは限りません.
    key
    実際に使用されているインデックスは、空の場合は使用されていないか、インデックスがまったくありません.
    key_len
    インデックスで使用されるバイト数は、短いほど良いです
    実際の長さではなく、インデックスフィールドの最大可能な長さを表します.
    ref
    そのカラムのインデックスが使用されていることを示します.constまたはカラムかもしれません.
    rows
    必要な情報を見つけて読み込むローの数を概算
    extra
    追加情報
  • using filesort:mysqlはデータを再ソートし、インデックスを利用できないソートはファイルソート
  • と呼ばれます.
  • using temporary:ソート時にテンポラリ・テーブル
  • が作成されました.
  • using index:クエリー時にテーブルクエリーを返す必要がなく、インデックスを直接介してクエリーのデータを取得できます.using whereがインデックス列が特定の行を検索するために使用されていることを示している場合、インデックス列はデータ
  • を抽出するためにのみ使用されます.
    インデックスの最適化
    インデックスの無効化の防止
  • 最適左接頭辞法則:複数のカラムがインデックス化されている場合、クエリはインデックスの先頭から開始する必要があり、インデックス内のカラム
  • をスキップすることはできません.
  • インデックス列では、様々な関数操作などの操作を行わないでください.そうしないと、インデックスが失効し、全テーブルスキャン
  • に移行します.
  • whereで範囲を使用すると、範囲右の列は
  • 失効する.
  • できるだけ上書きインデックス(インデックス列とクエリー列の順序が一致する)を使用し、select*
  • を使用しないでください.
  • 等しくない(!=または<>)を使用する場合、インデックスは使用できません.全テーブルスキャン
  • を使用します.
  • is nullとis not nullはインデックス
  • を使用できません.
  • likeがワイルドカードで始まる(like'%xyz')、インデックスは失効し、全テーブルスキャン
  • になります.
  • 暗黙的なタイプ変換は、インデックスの失効をもたらす
  • 少用or
  • スロークエリ
    /var/lib/mysqlにlogファイルがあります
    mysqldumpslowを使用してログを表示する