0::MySQLのIO操作 オペレーティングシステムのファイル読み取り処理では、ディスクIO操作がメモリ操作に比べて比較的遅いため、読み取り速度を向上させるためには、ディスクIO操作を減らすようにする必要があり、オペレーティングシステムは、一般的にデータページとして4KBでディスクデータを読み取りますが、mysqlは一般的にデータページとして16KBでデータを読み込み、読み取られたデータは、オペレーティングシステムのメモリのページキャッシュにキャッシュされ、他の隣接するデータページが順次読み取られ、ページキャッシュに保存されます。読み込まれたデータはオペレーティングシステムのメモリのページキャッシュにキャッシュされ、同時に隣接する他のデータページも順次読み込まれてページキャッシュに保存されるため、ファイルの読み込み速度を向上させることができます。
1トランザクションが失敗した場合、すぐにロールバックされるのか？
sql1 insert 成功
sql2 insert
commit sql1
begin sql1
start transaction sql1
"rollbacl" トランザクションのロールバック
トランザクションの実行プロセスでは、SQLの例外のために、自動的にトランザクションのロールバックを実行されていない場合は、"手動でロールバックを実行する必要がある",
さらに、トランザクションがコミットされるとき、begin,commit,startトランザクションの実行により、前のトランザクションがコミットされる。
このとき、トランザクションに間違ったデータがあっても、トランザクションは正常にコミットされる。
2binlog、redo log、undo logを書き込む順番。
1: undologバッファ
2データメモリ変更
3: リドログ
4: binlog
3トランザクション分離レベル
データが他のトランザクションによって変更されたが、まだトランザクションをコミットしていないが、また、まだ他のトランザクションによって変更されたデータの値を読み取ることができる場合、データの読み取りのための、コミットされていない読み取る
読み取りコミット、データの読み取りについては、データが他のトランザクションによって変更されているが、まだトランザクションに提出されていない場合は、この時間は、他のトランザクションによって変更されたデータ値を読み取ることはできませんが、トランザクションが提出されている場合は、他のトランザクションによって変更されたデータ値を読み取ることができる。
繰り返し読み出し（Repeatable Read）、データ読み出しの場合、データが他のトランザクションによって変更された場合、トランザクションがコミットされたかどうかに関係なく、データ値は複数回読み出され、最初の読み出しは一貫している。
シリアル、トランザクション間のシリアル実行
4: ACID
Aアトミシティ(Atomicity)とは、トランザクションがすべて実行されるか、まったく実行されないかのことである。
C整合性：データベースのデータの整合性と一貫性を保証する。
I分離（Isolation）：トランザクションとトランザクションは互いに分離され、トランザクションとトランザクションの間のデータは互いに影響しない。
D永続性：トランザクションがコミットされると、データベースへのデータ変更は永久にデータベースに保存される。
5MVCC：マルチバージョン同時実行制御プロトコル
読み出しコミットと繰り返し読み出し
一貫性ビューを通して+トランザクションIDは、データバージョンの可視性を確認し、MVCCを実装する。
読み出しコミットと繰り返し読み出しの違い：
ビューの作成時間。
rrは、トランザクションが作成された時点、またはトランザクション作成が最初のステートメントを実行した時点で、トランザクション全体に対して統一された一貫性ビューを作成する。
rcは、トランザクションで各ステートメントが実行される前に一貫性ビューを作成することである。
繰り返し読み取りでは、トランザクションが開始される前にコミットされ完了したデータのみをクエリが確認する。
読み取りコミットでは、クエリは、クエリ文が実行される前に完了コミットされたデータのみを確認する。
（トランザクションが開始されると、トランザクションデータが見えるか見えないかを判断するために、一貫性ビューとトランザクションのハイIDとローIDを通して、実行されているすべてのトランザクションIDを記録するために配列が使用される)。
6binlogの特徴
binlog はサーバー層であり、論理ログであり、バイナリログであり、3つのデータ形式がある，row,statement,row+statement，
statementSQL文の具体的な変更を記録する。
利点：マスターで実行されたステートメントの詳細と、それらが実行されたコンテキストだけを記録すればよい。これにより、binlogファイルのサイズが小さくなり、ディスクIOが減り、パフォーマンスが向上する。
''' 欠点：マスタ-スレーブレプリケーションでは、ストアドプロシージャの特定の場合、または関数やトリガの呼び出しとトリガは、一貫性のないマスタ-スレーブレプリケーションの問題につながる。
rowはSQLのコンテキスト情報を記録せず、どのデータが変更され、それが何に変更されたかを記録するだけである。
利点：ストアドプロシージャや関数、トリガーコールやトリガーが特定の状況で正しくコピーされないという問題がない。
''' 欠点：ビンログのデータ量は比較的大きくなり、たとえばテーブルを変更するとログが急増する。テーブルを変更するため、この種のテーブル構造の変更ステートメントの処理方法は、レコードのすべての行を変更する必要があるテーブル全体であるため、実際には、テーブル全体を再構築することです、その後、データの変更のすべての行は、ビンログに記録される。
row+statementMySQLは、一般的なレプリケーションではSTATEMENTモードを使用してビンログを保存し、STATEMENTモードではレプリケーションできない操作ではROWモードを使用してビンログを保存し、MySQLは実行されたSQL文に応じてビンログの保存方法を選択する。
7undologとは
undologは主にトランザクションのロールバックとMVCCに使用され、論理ログであり、レコードは、SQLの操作文である。
トランザクション・ロールバックとは、トランザクション操作のデータをトランザクション実行前の状態に戻すことである。
MVCCはマルチバージョン同時実行制御プロトコルで、一貫性ビューとトランザクションIDを通してデータバージョンの可視性を得る。
undologオペレーティングシステムは、一般にディスクデータを4KBのページで読み込み、mは対応するredologを書き込み、undologの挿入を記録する。
undologが共有テーブルスペースのロールバックセグメントに格納されている場合、ウンドロ グログを定期的にクリーンアップするバックグラウンドスレッドが存在するが、クリーンアップする 際には、ウンドロログが他のトランザクションによって使用されていないことを判断する必要がある。
例えば、あるデータを更新する場合、まずundologバッファを書き込み、次にメモリのデータページのデータを更新し、次にredologバッファを書き込み、undologの挿入データと、変更されたデータのデータページの内容を記録する。
書き込み効率はWALメカニズムによって改善される。
undologオペレーションはなぜredologに書き込む必要があるのか。
MySQLデータ復旧を実行する場合、未コミットのトランザクションやロールバックされたトランザクショ ンを含め、すべてのトランザクションがやり直される。コミットされていないトランザクションは、undologを介してロールバックする必要がある。
''' 8REDOログとは
redologは物理ログであり、データページ内のデータの具体的な変更を記録する。
redologサイズは固定であり、例えば、4つのファイルのセットとして構成することができ、各ファイル1Gは、ファイルが先頭から書き込まれ、最後に書き込み、書き込みを続行するには、ヘッドに戻ってループする。
redologは、書き込み に後ろにシフトされた現在のレコードの位置であるwriteeposを持つ。
チェックポイントもあり、これは消去される現在位置であり、また後方で周期的であり、レコードを消去する前にデータファイルにレコードを更新する必要がある。
writeposがチェックポイントに追いついた場合、MySQLはサービスを一時停止し、データをフラッシュする必要がある。
redologを使用することで、InnoDBはデータベースが異常に再起動された場合でも、コミットされたレコードが失われないようにすることができる。
redo log
1バックグラウンド・スレッドは1秒間に1回書き込む
2他のトランザクションがコミットされると、他のトランザクションのREDOログもディスクにフラッシュされる。
3メモリ不足
'''9変更バッファ
"changhe bufferはプールバッファのメモリサイズであり、サイズ制限がある。%，メモリを置くことができない、またはチェックポイントのメカニズムを通じて、変更バッファは、ディスクをドロップする""
change buffer は主に、ディスクのランダム読み取り IO を減らすことによって MySQL のパフォーマンスを向上させる。
change buffer これもREDOログと同様、チェックポイントメカニズムによって処理される。
change buffer は主に、通常のセカンダリインデックス、更新、変更、挿入のパフォーマンスを最適化するために使用される。
データの変更については、新しい、最初にchangebufferに書き込み、次のクエリを待って、マージを介してデータページにデータを更新し、redologを書く。
mergeワードの流れは
1: ディスクからメモリにデータ・ページを読み込む。
2変更バッファによってメモリ上の更新データの内容を変更する。
3記録データの変更redolog、および変更バッファの変更操作。
mergeのトリガーとなる：
1データ・ページ・マージ
2バックグラウンド・スレッドは定期的に
3：データベースは通常のシャットダウン時にマージされる。
change bufferはシステムのテーブルスペースに永続化されて保存され、redologを書き込む。これは、システムがダウンしたときに、redologを通じて復旧できることを保証し、クラッシュセーフの役割を果たす。
''' 質問：セカンダリ・インデックスを通してデータを変更する場合、この時に変更バッファを使ってもいいのだろうか？結局のところ、この時間はデータベースに照会、主キー・インデックスからデータを取得するためにテーブルに戻っている。
10マスター・スレーブ同期メカニズム
{MasterA
{ start->undolog(memory)->data(memory)->redolog(prepare)->binlog->redolog(commit)->ack
{ |
{ v
{ dump_thread----|
{ bg_thread->undolog(disk)->data(disk) |
{ v
{slaveB data<-sql_thread<-relay log<-io_thread
{
"同期が行われるのは、バックアップリポジトリがアクティブに"
masterとスレーブがロングリンクを確立する場合、マスターにはロングリンク（ダンプ）に対応する特別なスレッドが存在する。_thread）
同期プロセス：「（2つのフェーズ1作成、-から>マスター 2 プロセス マスター・スレーブ)
"マスターとスレーブの同期を作成し始めると、スレーブ・ライブラリはプルする必要のある特定の場所を設定する "
1: スレーブは、ファイル名とログオフセットを含むchange masterコマンドを使用して、マスターのIP、ポート、ユーザー名、パスワード、およびbinlogの要求を開始する場所を設定する。
2スレーブはstart slaveコマンドを実行してioを開始する。_threadと sql_threadスレッド、ここで io_threadはマスター・ライブラリーとのロング・リンクの確立を担当する。
3マスターはユーザー名とパスワードをチェックした後、ローカルでbinlogの読み込みを開始し、スレーブから渡された場所に応じてスレーブに送信する。
4: スレーブはbinlogを取得した後、リレーログと呼ばれるローカルファイルを書き込む。
5:sql_threadリレーログを読み込み、ログ内のコマンドを解析して実行する。
"マスター・スレーブ同期が構築された後、"
1どのBinlogデータをスレーブに送信するかは、マスター次第である。
11
1: ラインロック：
行ロックには2段階のロック・プロトコルがある。，
'行ロックは必要なときに追加され、トランザクションのコミット後に解放される。
は読み出しロックsと書き込みロックxに分けられる。
行ロックと行ロックの間で競合が発生する可能性がある。
readは競合しない。
読み書きの競合
書き込み 読み取り競合
書き込み 書き込み競合
2: ギャップロック：
ギャップロックは互いに競合しない
ギャップ・ロックは、このギャップを新しいデータの挿入から守るためのものだからである。
"同じトランザクションにおいて、このトランザクションのギャップロックと行数は互いに影響し合わず、このトランザクションの行ロックに影響するのは他のトランザクションのギャップロックである。
3次キーロック
"は再現性分離レベルにおいてのみ有効である。"
ギャップ・ロックと行ロックの組み合わせはネクスト・キー・ロックと呼ばれ、フロント・オープンでバック・クローズドなロックである（x,y]
1ロックの最小単位はネクスト・キー・ロックである。
2クエリでアクセスされるオブジェクトだけがロックされる。
3インデックスの等価クエリ、ユニークインデックスクエリ、行ロックへのデグレード
4: インデックスに対する等値クエリでは、右へトラバースして最後の値が等値条件を満たさない場合、ネクスト・キー・ロックはギャップ・ロックに縮退する。
5一意インデックスに対する範囲クエリは、以下の条件を満たさない最初の値までアクセスする。
4: "ギャップロックとギャップロックがデッドロックを引き起こすケース"
sessionA sessionB
T1 ロックギャップ A
T2 ロックギャップ A
T3 ギャップAにデータを書き込む
T4 ギャップAにデータを書き込む
分析：セッションAとセッションBは、T2の瞬間までの実行はまだ何の問題もないため、ロック間のギャップは、ロックと競合しないため、T2の瞬間までの実行はまだ何の問題もない。
そして、T3の瞬間に、ギャップへのデータ書き込みは、セッションAのギャップロックによってブロックされ、ウェイトに入る。
そして、T4の瞬間に、ギャップへのデータ書き込みはセッションBのギャップロックによってブロックされ、2つのセッションは互いに待ち合い、デッドロックとなる。
しかし、"innoDBのデッドロック検出 "のため、sessionA のゲームは以下のようなエラーを返す。.
デッドロックが検出されると、"トランザクションの再開"、すなわち、トランザクションを最初から開始し、この行を開始し、他のトランザクションは実行を継続する。
この時点で、sessionBによってブロックされた操作が実行され、データが書き込まれ、sqlの実行は成功するが、まだコミットされていないことがわかる。
テーブルレベルのロック：
MDLメタデータロックは、ロックを表示する必要はありませんが、自動的に追加されます、限り、それはデータの読み取りと書き込みの正しさを確保するために、テーブルの変更を防ぐために使用される。
'MDLmDLの書き込みと読み出し、読み出しと書き込み、書き込みと書き込みは相互に排他的である。
トランザクションAは、テーブル構造に変更され、MDL書き込みロックに追加され、この時点で、他のトランザクションは、テーブルにデータを読み書きする方法がない。
MDL複数のトランザクションが実行されているとき、前のトランザクションがSQLの読み取り/書き込み操作を実行したが、まだコミットされていない場合、トランザクションがテーブル構造に対してalter tableのような操作を実行すると、新しい問題が発生する可能性がある。，
を使用すると、それに続くすべてのトランザクションがブロックされ、クライアントに再試行メカニズムがある場合、MySQL 接続プールがいっぱいになる可能性がある。
"1これは主に長いトランザクションが原因である。
2分身テーブルに待ち時間を設定し、タイムアウト後に分身テーブルの操作を 止する。
テーブルロック：テーブルをロックする ... 読み書きロック
unlock tables は積極的にロックを解放するか、クライアントが切断したときに自動的にロックを解放する。
"注：読み取り、すべてのトランザクションは、読み取りのみ、トランザクションを書き込むことができない場合、書き込み、このトランザクションは、読み取りと書き込みができ、他のトランザクションが動作することはできない""
12
B+
クラスタ化インデックスの場合、リーフノードはデータページである。
セカンダリインデックスの場合、リーフノードはプライマリキーインデックスのidである。
インデックスの最適化
1結合インデックス
MySQLindexは左端の接頭辞である。
2インデックスダウン
セカンダリ・インデックスのクエリでは、まず論理的なフィルタリングの一部を行ってインデックス上のデータを判断し、一致する主キーIDを取得した後、テーブルに戻って特定のデータ行をクエリする。
3上書きインデックス
セカンダリ・インデックスのクエリでは、クエリする必要のあるデータはすでにインデックス上にあるため、テーブルに戻る操作を避け、セカンダリ・インデックスを通して直接必要なデータをすべて取得することができる。
"通常のインデックスのクエリは、条件を満たさない最初のレコード位置に出会うまでクエリを続ける。
一意インデックスのクエリは、条件を満たす最初のレコードを見つけた後、クエリの継続を停止する。"
13
'1行の内容が非常に大きい場合、これはソート_bufferはあまり多くの行を保存することができないため、複数の一時ファイルに分割する必要が生じ、パフォーマンスの低下につながることもある。
使用するアルゴリズムの選択：ソートされた行のサイズに依存する。
1フルフィールドソート
1初期化ソート_buffer，テーブルのカラムに入れられるフィールドを確認する。
2: インデックスから特定の主キーidを満たすレコードを検索する。
3主キーidを使用することで、フィールドの内容がソートに格納される。_buffer中
4すべてのクエリーが完了するまで、2,3の処理を繰り返す。
5ソート_bufferクイックソート」でソートする必要のあるフィールド。
6: ソート結果に応じて、必要な制限行数を返す。
'
1ソート_bufferメモリが使用されている場合、サイズの制限があり、ソートする内容が大きすぎる場合は、マージソート（複数のファイルのソート結果を本当に順序付けられた結果セットにする）のためにディスク一時ファイルを使用する必要がある。
2具体的には、mysql のソートによって_buffer_size
3一時ファイルがたくさんあると、パフォーマンスが非常に悪くなる。
2行IDソート
'1行の内容が非常に大きい場合、これはソート_bufferはあまり多くの行を保存することができないため、複数の一時ファイルに分割する必要が生じ、パフォーマンスの低下につながることもある。
0: mysql は、1 行の最大ソート長を制御することによって、rowid ソートを使用するかどうかを決定する。
プロセスは以下の通りである：
1初期化ソート_buffer，ソートが必要なフィールド、つまり主キーとソートが必要なフィールドを入れることを確認する。
2: インデックスから主キーidを満たすレコード行を探す。
3主キーIDによって特定のデータ行のレコードを取得し、ソートが必要なフィールドと主キーIDをソートに書き込む。_buffer中
4ステップ2と3を繰り返す
5ソート_buffer
6ソート結果を通じて、特定のソートされた主キーIDを取得し、すべてのデータを取得し、クライアントに返すためにテーブルクエリに戻る。
"ソートの最適化 "
並べ替えが必要なフィールドは、自然に並べ替えられるように、結合インデックスを付加することができる。
14ファントムリーディングとは何か、ファントムリーディングの問題点は何か？
rr分離レベルでは、同じ範囲に対する複数のクエリから出てくる行の数は、現在の読み取りでは同じではない。
1多重分離レベルでは、通常のクエリはスナップショット・リードであり、他のトランザクションによって挿入されたデータを見ることはない。従って、ファントム・リードはカレント・リードの下でのみ発生する。
2他のトランザクションによってデータが変更された後、変更されたデータが現在の読み取りを介して読み取られ、この時間はファントム読み取りとは呼ばれません、ファントム読み取りは、特に新しく挿入されたデータのためのものである。
ファントムリードが問題になっているようだ：
1セマンティクス トランザクションは本来、変更する必要のあるデータをすべてロックしたと考えていたが、他のトランザク ションが新しいデータを追加したため、ロックされていない余分な新しいデータのために、他のトランザク ションのセマンティクスが壊れてしまった。
2トランザクションがデータ変更を行った場合、変更する必要のあるデータをすべてロックしてしまうと考えられ、その後、他のトランザクションが新しいデータを書き込むため、元のトランザクションが他のトランザクションによって追加された新しいデータをさらに更新することになり、データの一貫性が失われる。
T1時間後，id=5 この行は、もちろん、この結果は最終的にT6タイムに正式に提出されたものである。 ;
T2モーメント後，id=0 この行は(0,5,5);
T4の後、表にはもう1行（1）がある。,5,5);
他の行はこの実行シーケンスとは関係なく、変更されない。
これは問題ないが、この時点でのbinlogの中身を見てみよう。
T2 瞬間、セッションBトランザクションはコミットされ、2つのステートメントが書き込まれる；
T4 の時点で、セッションCのトランザクションはコミットされ、2つのステートメントが書き込まれる；
T6 その時点で、セッションAのトランザクションはコミットし、更新tを書き込む。=100 where d=5 この文は
予備のライブラリを入手して実行する場合でも、binlogを使って後でライブラリをクローンする場合でも、この3行の結果は、 、 、 、となる。
はファントム・リードを解決する：
1:ギャップロック
ギャップ・ロックが問題となる：
は、ロック範囲がさらに大きくなるため、同時実行の度合いに影響する。ギャップ内のものはすべてロックされる。
2:行としてbinlogログフォーマットを使用することも可能である。+rcファントムリードを解決するための分離レベル。
15MySQL Dirty Page Brush Disk、4つのシナリオ
メモリには3種類のデータ・ページがある，
未使用データページ
クリーンページ、つまり読み込んだデータを格納する。
ダーティページでは、読み込んだデータページに対してデータの変更が行われる
1メモリ不足で、ダーティページのためにディスクをスワイプする必要がある。
ポリシーはLRU
2ディスクをフラッシュするために、チェックポイントを移動する必要がある。
redologライトフル状態では、MySQL のライトオペレーションが 0 に低下し、すべての更新オペレーションが停止する。
3ディスクをブラッシングしているとき、システムは mysql がアイドル状態であると考える。
4mysqlのシャットダウン、ディスクをフラッシュする必要がある。
16インデックスの選択
インデックスの選択は、オプティマイザである
影響因子：
1これはディスクIOの回数とCPUリソースの消費量に影響する。
2一時テーブルを使うかどうか
3ソートするかどうか
4: テーブルに戻るかどうか
判定基準
1走査線数の判定方法
ステートメントの実際の実行では、innodbはこの条件を満たすレコード数を正確に知ることができず、統計情報によってレコード数を推定することしかできない。
この統計量はインデックスの微分である。インデックスの値が異なれば異なるほど微分値は高くなる。
は、主に統計情報を使用して、N個のデータページのInnoDBのデフォルトの選択は、上記のさまざまな値の統計情報は、平均を取得し、インデックスページの数を平均値を乗算し、このベースである。
N とMは、メモリーをセーブするかどうか、フラットに永続化するかどうか、といった戦略の違いで異なる。"N/M => disk:20/10; memory:8/16"
'変更されたデータ行の数が1/Mを超えると、ベースが再カウントされるか、analyze table z コマンドによって再カウントされる。
17表データ削除、表領域回復
データ削除のプロセス：
削除されたレコードについては、innoDBは削除されたレコードとして「マーク」するだけである。新しいレコードが追加された場合、その場所は再利用されるかもしれない。しかし、ディスクファイルのサイズは小さくならない。
データページが削除された場合、データページ全体が再利用される。"データページは再利用可能としてマークされる"
'PSレコード多重化はデータページ多重化とは異なり、レコード多重化は範囲条件を満たすデータに限定される。
例えば、400~600の間に、500を削除し、その後500レコードを追加し、元の500を取ることができる、もし800を追加し、元の500の位置を取ることはない。
"ページ・マージ」：隣接する2つのデータ・ページの利用率が両方とも非常に小さい場合、システムはこれらの2つのデータ・ページを1つのデータ・ページにマージし、もう1つのデータ・ページは再利用可能としてマークされる。
したがって、delectコマンドはレコードの位置やデータ・ページを「再利用可能」とマークするだけで、ディスク・ファイルのサイズは変更しない。
'インデックスのランダム挿入は、インデックス上の値の更新に加え、データページの分割につながる可能性がある。これは、古い値を削除して新しい値を挿入すると理解できる。
"解決方法」：テーブルを再構築する。
alter table a engine=InnoDBmySQLは自動的にデータのダンプを終了し、テーブル名を交換し、古いテーブルを削除する。
しかし問題がある。主キーidが上書きされてしまうため、他のテーブルに間違った主キーidが格納されてしまうのだ。
18: count(*)動作フロー
1: MyISAMはテーブルの総行数をディスクに保存しているので、count(*)はこのデータを直接返すと非常に効率的である。
2: InnoDBはエンジンからデータを1行ずつ読み込んでカウントを蓄積する必要があるため、テーブルのデータ量が非常に大きい場合、カウントが非常に遅くなる。
"注：いずれも無条件フルテーブル数(*)たとえば、どこの条件を持ってくる必要がある場合、MyISAMは非常に高速に返されない"
'なぜInnoDBは行単位なのか？
同じ瞬間に複数のクエリを実行する場合、MVCCのため、InnoDBが返す必要がある行数も不確定になる。
複数のトランザクションにおける異なるバージョンのデータの可視性は同じではないため、計算される行数に違いが生じる。
"count最適化：論理的には、通常のインデックスのカウントと主キーインデックスのカウントの最終結果は同じである。，
一般的なインデックスは主キー・インデックスよりもはるかに小さいので、統計の数を最適化するには、より小さい一般的なインデックスを統計的にスキャンして、スキャンするデータ量を減らすことができる。"
'count(*)，mysqlは最適化されており、すべてのフィールドの値を取り出すわけではないが、値を取り出さないように特別に最適化されている。*)はNULLであってはならない。
19パフォーマンス分析の原則：
1サーバー層は、あなたが望むものを与えてくれる。
2InnoDB は必要なデータだけを与える。
20クラッシュ・セーフ
1: redologは書き込まれているがbinlogが書き込まれていない場合、クラッシュし、ランタイムが回復したときにトランザクション上でロールバックされ、この時点ではbinlogは書き込まれていないので、スレーブライブラリに影響を与えない。
2もしredologが書き込み、Binlogが書き込み、そしてクラッシュする。
1redologがすでにコミット状態にある場合、トランザクションは直接コミットされる。
2もしredologが準備状態であれば
1: binlogが完了したかどうか、完了したらトランザクションをコミットする。
2ビンログが不完全な場合、トランザクションはロールバックされる。
3: 'binlog 整合性判定'。
/~ トランザクションのビンログには整合性フォーマットがある。
"statementの最後にCOMMITがある。;
rowの最後にXIDイベントがある。;"
およびbinlog-checksumパラメータは、binlogの正しさをチェックするために使用できる。
21MySQLがこのように設計されている理由：準備段階のREDOログと完全なビンログは、再起動時にリカバリできる。?
Binlogが完全に書き込まれている場合、スレーブライブラリはマスターとスレーブの同期のためにBinlogを受け取るので、マスターライブラリもデータの一貫性を確保するためにこのトランザクションをコミットする必要がある。
22通常のインスタンスでは、データがディスクに書き込まれた後、REDOログから更新されるのか、それともバッファプールから更新されるのか？
redologは完全なデータ・ページの記録を持っていないので、ディスク・データ・ページを更新する機能を持っていない。
"1通常動作の場合、メモリのデータページがディスクのデータページと整合性がとれなくなった後、データページが変更される。最終的にデータがディスクに落ちる、ディスクにメモリのデータページを書き込むことです、全体のプロセスも、redologとは何の関係もない。
2クラッシュ・リカバリの場合、クラッシュ・リカバリ中にデータ・ページの更新が失われた可能性があると判断した場合、InnoDBはデータ・ページをメモリにロードし、redologによってメモリ・データ・ページを更新する。
更新が完了すると、最初のケースに戻るだけで、メモリのデータ・ページはダーティ・ページになる。"
23これらのSQL文のロジックは同じなのに、パフォーマンスに大きな違いがあるのはなぜだろう？
'
eg: select * from tableName where id + 1 = 1000;
eg: select * from tableName where convert(name using utf8) = "cxcz";
"フィールドには関数を使うことはできないが、検索条件の値には関数を使うことができる。
'
eg: select * from tableName where id = 1000 + 1;
g: select * from tableName where name = convert( "cxcz" using utf8);
1フィールドに対して関数操作を行うと、インデックス値の順序が崩れる可能性がある。
2暗黙の型変換
3暗黙の文字列エンコード変換
