この記事では、mysql に関する関連知識をお届けします。主にストレージ エンジン InnoDB アーキテクチャに関する関連コンテンツを紹介します。InnoDB は、トランザクション セキュリティをサポートするストレージ エンジンである MySQL のデフォルト エンジンです。それを見て、皆さんのお役に立てれば幸いです。
推奨学習: mysql ビデオ チュートリアル
現在の MySQL8.x バージョンのデータベースはすでに多くのストレージ エンジンをサポートしていますが、一般的には固定的な考え方が形成されやすく、他のストレージ エンジンを簡単に採用できないため、ストレージを最適化する多くの機能が欠けています。したがって、現在サポートされている 9 つのデータベース ストレージ エンジンの機能を明確に理解することを学ぶ価値があります。この記事では、これら8つのデータベースストレージエンジンの機能や機能、利用シーンをわかりやすく解説します。
この一連の記事は、私のコラム「さまざまな SQL データベース操作をすぐに学ぶ」に掲載されます。基本的に、日常業務、従来のクエリ データベース分析、および複雑な操作を処理するための SQL の使用に関するすべての側面をカバーしています。データベースとテーブルを構築する基本的な手順から、さまざまな複雑なデータベース操作の処理、一般的な SQL 関数の専門的な説明まで、作成には多くの時間と労力が費やされています。データ開発については、最も実践的でよく使われる知識を初めて学ぶコラムの購読をお勧めします。このブログは非常に長いので、よく読んで練習する必要がありますが、最良の部分を選択して実践方法を詳しく説明します。ブロガーは長期にわたってブログ記事を管理していきますので、間違いや疑問がございましたら、コメント欄でご指摘いただければ幸いです。
1. サポートされているストレージ エンジン
MySQL データベースにアクセスしてストレージ エンジンを表示すると、MySQL データベースでサポートされているすべてのストレージ エンジンを確認できます:
SHOW ENGINES
現在、Federated がサポートしていないエンジンがあります。他の 8 つのデータベース ストレージについてのみ明確にする必要があります。
MySQL の一般的なデータベース エンジンには、MyISAM、InnoDB、Memory などがあります。それでは、まずこれら 3 つのエンジンについて理解しましょう。
2. InnoDB エンジン
InnoDB は MySQL のデフォルト エンジンであり、トランザクション セキュリティをサポートするストレージ エンジンです。 MySQL のデータは物理ディスクに保存され、実際のデータ処理はメモリ内で実行されます。ディスクの読み取りおよび書き込み速度は非常に遅いため、操作ごとに頻繁にディスクの読み取りおよび書き込みが行われると、パフォーマンスが非常に低下します。
上記の問題を解決するために、InnoDB は、ディスクとメモリ間の対話の基本単位としてページを使用して、データを複数のページに分割します (一般的なページ サイズは 16 KB)。この場合、一度に少なくとも 1 ページのデータがメモリに読み込まれるか、1 ページのデータがディスクに書き込まれます。メモリとディスク間のやり取りの数を減らすことで、パフォーマンスを向上させます。
これは本質的に典型的なキャッシュ設計の考え方です。一般に、キャッシュ設計は基本的に時間次元または空間次元から検討されます:
時間次元: データの場合が使用されている場合、次の期間に再び使用される可能性が高くなります。ホットスポット データ キャッシュは、このアイデアの実装に属すると考えることができます。
空間次元: あるデータが使用されている場合、その近くに保存されているデータもすぐに使用される可能性が高くなります。 InnoDB のデータ ページとオペレーティング システムのページ キャッシュは、このアイデアを具体化したものです。
以下は公式の InnoDB エンジン構造図です。主にメモリ構造とディスク構造の 2 つの部分に分かれています。
メモリ構造には主に、バッファ プール、変更バッファ、アダプティブ ハッシュ インデックス、ログ バッファの 4 つのコンポーネントが含まれています。
1.バッファプール
バッファプールは、データ、インデックス、挿入バッファ、アダプティブハッシュインデックス、ロック情報、データディクショナリで構成されます。バッファー プール。BP と呼ばれます。 BP はページに基づいており、デフォルト サイズは 16K です。BP の最下層は、リンク リスト データ構造を使用してページを管理します。 InnoDB がテーブル レコードとインデックスにアクセスすると、それらはページ ページにキャッシュされ、後で使用することでディスク IO 操作が軽減され、効率が向上します。
バッファ プールは、データベースのパフォーマンスに対する遅いディスク速度の影響を補うためにメモリの速度を使用する単なるメモリ領域です。データベースのページを読み取る場合、まずディスクから読み取ったページをバッファプールに格納しますが、この処理をページをバッファプールに「FIX」と呼びます。次回同じページが読み取られるときは、まずそのページがバッファ プール内にあるかどうかを確認します。ページがバッファ プール内にある場合、そのページはバッファ プール内でヒットしたと言われます。ページを直接読んでください。それ以外の場合は、ディスク上のページが読み取られます。データベース内のページの変更操作では、バッファ プール内のページが最初に変更され、次に特定の頻度でディスクに更新されます。ここで注意する必要があるのは、ページをバッファ プールからディスクにフラッシュする操作は、ページが更新されるたびにトリガーされるのではなく、チェックポイントと呼ばれるメカニズムを通じてディスクにフラッシュされることです。これも、データベース全体のパフォーマンスを向上させるためです。
従来の LUR アルゴリズム
バッファ プールは、LRU (最近使用されたもの、最も最近使用されたもの) アルゴリズム、つまり最も頻繁に使用されるアルゴリズムを通じて管理されます。ページ LRU リストの先頭にあり、最も使用されていないページは LRU リストの末尾にあります。バッファ プールが新しく読み取られたページを格納できない場合、LRU リストの末尾にあるページが最初に解放されます:
(1) ページ 既にバッファー プール内にある場合は、LRU ヘッドへの「移動」アクションのみが実行され、ページは削除されません。
(2) ページは削除されません。 LRU ヘッドにページを「置く」アクションを除き、バッファ プールに追加します。アクションだけでなく、LRU テール ページを「削除」することもできます。
ただし、InnoDB の LUR アルゴリズムは、従来の LUR アルゴリズムではありません。
ここには 2 つの問題があります:
(1) 事前読み取りの失敗;
(2) バッファープールの汚染;
まず、事前読み取りとは何かを理解しましょう。 -reading は Read;
先読み
ディスクの読み取りと書き込みはオンデマンドでの読み取りではなく、ページごと (少なくとも 1 ページ) で読み取ります。一度にページデータ (通常は 4K) を取得し、将来読み取られるデータがページ内にある場合、後続のディスク IO を省略でき、効率が向上します。通常、データアクセスは「集中的な読み書き」の原則に従い、あるデータを使用する場合、近くのデータが使用される可能性が高く、早期ロードが有効であることを示す、いわゆる「ローカリティ原理」を示します。実際にディスク IO を削減できます。
先読み失敗
先読み (Read-Ahead) により、ページは事前にバッファ プールに置かれ、しかし、最終的に MySQL は失敗しました。 ページからデータを読み取ることは、先読みエラーと呼ばれます。
先読みの失敗を最適化するためのアイデアは次のとおりです。
(1) 先読みに失敗したページをできるだけ短い時間バッファ プール LRU に留まらせる。
( 2) 実際に読み取られるページをバッファ プール LRU の先頭に移動させます。
は、実際に読み取られるホット データがバッファ プール内にできるだけ長く留まるようにするためです。できるだけ。
具体的な方法は次のとおりです。
(1) LRU を 2 つの部分に分割します。
新世代 (新しいサブリスト)
旧世代 (古いサブリスト) ) )
(2) 新しい世代と古い世代の端は接続されています。つまり、新しい世代の末尾は古い世代の先頭に接続されています。
(3)新しいページ (たとえば、次のように) 先読みページがバッファー プールに追加されると、古い世代の先頭にのみ追加されます:
データが実際に読み取られる場合 (先読みは成功した場合)、新しい世代の先頭に追加されます
データが読み取られていない場合は、新しい世代の「ホット データ ページ」よりも先にバッファ プールから削除されます
新世代および旧世代の LRU の改良版では、バッファ プール汚染の問題は依然として解決できません。
2.ログ バッファ
ログ バッファは、REDO ログをキャッシュするために使用されます。
InnoDB には、undo ログと redo ログという 2 つの非常に重要なログがあります。
(1) Undo ログを通じて、以前のバージョンのデータを確認したり、MVCC を実装したり、トランザクションやその他の機能をロールバックしたりできます。
(2) REDO ログを使用してトランザクションの耐久性を確保します。
#REDO ログ バッファは、ディスク上のログ ファイルに書き込まれるデータを保存するために使用されるメモリ記憶領域です。ログ バッファのサイズは innodb_log_buffer_size 変数で定義され、デフォルトのサイズは 16MB です。
ログ バッファの内容は定期的にディスクにフラッシュされます。ログ バッファが大きいと、トランザクションがコミットされる前に REDO ログ データがディスクに書き込まれることなく、大規模なトランザクションを実行できます。したがって、多くの行を更新、挿入、または削除するトランザクションがある場合、ログ バッファー サイズを増やすとディスク I/O を節約できます。
innodb_flush_log_at_trx_commit: ログ バッファーの内容をディスクに書き込み、フラッシュする方法を制御します。
innodb_flush_log_at_timeout: ログの更新頻度を制御します。
多くの BLOB エントリを含むトランザクションなど、ディスク I/O によってパフォーマンスの問題が発生している場合は、トランザクションを観察する必要があります。 InnoDB ログ バッファは満杯になるたびにディスクにフラッシュされるため、バッファ サイズを増やすと I/O が削減される可能性があります。
ログ ファイルのデフォルトの数は、ib_logfile0 と ib_logfile1 の 2 つです。
ログのサイズは固定されており、デフォルトのサイズは MySQL のバージョンによって異なります。
3.アダプティブ ハッシュ インデックス
アダプティブ ハッシュ インデックスアダプティブ ハッシュ インデックスは、ホット ページが配置されているレコードを格納するキーと値のペアのストレージ構造です。 InnoDB ストレージ エンジンは、アクセスの頻度とパターンに基づいて、特定のページのハッシュ インデックスを自動的に作成します。
#上の図は、B-tree インデックスとアダプティブ ハッシュ インデックスの違いです。 innodb_adaptive_hash_index パラメータを使用してこの機能を無効または有効にします。このパラメータはデフォルトで有効になっています。
4.変更バッファ
変更バッファ: MySQL のデータはメモリとディスクの 2 つの部分に分割され、ホット データ ページとインデックス ページをバッファ プールにキャッシュしてディスク読み取りを削減し、変更を通じてバッファはディスクへの書き込みを容易にする手段です。
データ ページを更新する必要がある場合、データ ページがメモリ内にある場合は直接更新します。データ ページがメモリ内にない場合。データの一貫性に影響を与えることなく、InooDB はこれらの更新操作を変更バッファーにキャッシュするため、このデータ ページをディスクから読み取る必要はありません。次のクエリでこのデータ ページにアクセスする必要がある場合、データ ページをメモリに読み取り、変更バッファ内のこのページに関連する操作を実行します。このようにして、データロジックの正確性を保証できます。
名前は変更バッファと呼ばれていますが、実際には永続化できるデータです。つまり、変更バッファのコピーはメモリ内にあり、ディスク (ibdata) にも書き込まれます。
変更バッファ内の操作を元のデータ ページにマージし、最新の結果を取得する処理をマージ といいます。次の状況でマージがトリガーされます:
このデータ ページにアクセスします;
バックグラウンド マスター スレッドは定期的にマージされます;
データベース バッファ プールが十分でない場合;
データベースが正常にシャットダウンされた場合;
REDO が実行された場合ログがいっぱいです;
変更バッファとは、非一意の通常のインデックス ページがバッファ プールになく、そのページで書き込み操作が実行されると、レコード変更バッファが最初にバッファリングされ、その後将来のデータが読み取られるときに変更バッファーが変更され、元のデータ ページにマージされる操作のテクノロジが使用されます。 MySQL 5.5 より前は挿入バッファと呼ばれ、挿入のみに最適化されていましたが、現在は削除と更新にも有効であり、書き込みバッファ (変更バッファ) と呼ばれています。
推奨学習: mysql ビデオ チュートリアル
以上がMySQL ストレージ エンジン InnoDB アーキテクチャの詳細な説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

MySQLはGPLライセンスを使用します。 1)GPLライセンスにより、MySQLの無料使用、変更、分布が可能になりますが、変更された分布はGPLに準拠する必要があります。 2)商業ライセンスは、公的な変更を回避でき、機密性を必要とする商用アプリケーションに適しています。

Myisamの代わりにInnoDBを選択する場合の状況には、次のものが含まれます。1)トランザクションサポート、2)高い並行性環境、3)高いデータの一貫性。逆に、Myisamを選択する際の状況には、1)主に操作を読む、2)トランザクションサポートは必要ありません。 INNODBは、eコマースプラットフォームなどの高いデータの一貫性とトランザクション処理を必要とするアプリケーションに適していますが、Myisamはブログシステムなどの読み取り集約型およびトランザクションのないアプリケーションに適しています。

MySQLでは、外部キーの機能は、テーブル間の関係を確立し、データの一貫性と整合性を確保することです。外部キーは、参照整合性チェックとカスケード操作を通じてデータの有効性を維持します。パフォーマンスの最適化に注意し、それらを使用するときに一般的なエラーを避けてください。

MySQLには、B-Treeインデックス、ハッシュインデックス、フルテキストインデックス、空間インデックスの4つのメインインデックスタイプがあります。 1.B-Treeインデックスは、範囲クエリ、ソート、グループ化に適しており、従業員テーブルの名前列の作成に適しています。 2。HASHインデックスは、同等のクエリに適しており、メモリストレージエンジンのHASH_TABLEテーブルのID列の作成に適しています。 3。フルテキストインデックスは、記事テーブルのコンテンツ列の作成に適したテキスト検索に使用されます。 4.空間インデックスは、地理空間クエリに使用され、場所テーブルのGEOM列での作成に適しています。

tocreateanindexinmysql、usethecreateindexstatement.1)forasinglecolumn、 "createdexidx_lastnameonemployees(lastname);" 2)foracompositeindexを使用して、 "createindexidx_nameonemployees(lastname、firstname);" 3); "3)、" 3)を使用します

MySQLとSQLiteの主な違いは、設計コンセプトと使用法のシナリオです。1。MySQLは、大規模なアプリケーションとエンタープライズレベルのソリューションに適しており、高性能と高い並行性をサポートしています。 2。SQLiteは、モバイルアプリケーションとデスクトップソフトウェアに適しており、軽量で埋め込みやすいです。

MySQLのインデックスは、データの取得をスピードアップするために使用されるデータベーステーブル内の1つ以上の列の順序付けられた構造です。 1)インデックスは、スキャンされたデータの量を減らすことにより、クエリ速度を改善します。 2)B-Tree Indexは、バランスの取れたツリー構造を使用します。これは、範囲クエリとソートに適しています。 3)CreateIndexステートメントを使用して、createIndexidx_customer_idonorders(customer_id)などのインデックスを作成します。 4)Composite Indexesは、createIndexIDX_CUSTOMER_ORDERONORDERS(Customer_Id、Order_date)などのマルチコラムクエリを最適化できます。 5)説明を使用してクエリ計画を分析し、回避します

MySQLでトランザクションを使用すると、データの一貫性が保証されます。 1)StartTransactionを介してトランザクションを開始し、SQL操作を実行して、コミットまたはロールバックで送信します。 2)SavePointを使用してSave Pointを設定して、部分的なロールバックを許可します。 3)パフォーマンスの最適化の提案には、トランザクション時間の短縮、大規模なクエリの回避、分離レベルの使用が合理的に含まれます。


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

SublimeText3 英語版
推奨: Win バージョン、コードプロンプトをサポート!

ZendStudio 13.5.1 Mac
強力な PHP 統合開発環境

MinGW - Minimalist GNU for Windows
このプロジェクトは osdn.net/projects/mingw に移行中です。引き続きそこでフォローしていただけます。 MinGW: GNU Compiler Collection (GCC) のネイティブ Windows ポートであり、ネイティブ Windows アプリケーションを構築するための自由に配布可能なインポート ライブラリとヘッダー ファイルであり、C99 機能をサポートする MSVC ランタイムの拡張機能が含まれています。すべての MinGW ソフトウェアは 64 ビット Windows プラットフォームで実行できます。

SAP NetWeaver Server Adapter for Eclipse
Eclipse を SAP NetWeaver アプリケーション サーバーと統合します。

AtomエディタMac版ダウンロード
最も人気のあるオープンソースエディター

ホットトピック









