トランザクションACIDとは
Mysqlトランザクションの主な特徴は以下の4つです。
Atomicity（原子性）：トランザクションは最小の不可分の作業単位であり、操作全体はすべて成功するか、すべて失敗するかのどちらかであり、一般的にコミットとロールバックによって制御されます。
一貫性:データベースは常に一貫性のある状態から別の状態に遷移し、どちらか一方で例外が発生する限り、トランザクションは正常にコミットされません。
分離：あるトランザクションは他のトランザクションに対して相対的に分離され、あるトランザクションによる変更は最終コミットまで他のトランザクションからは見えません。
永続性：いったんトランザクションがコミットされると、そのトランザクションが行った変更は永続的にデータベースに保存されます。この時点で、システムがクラッシュしても、変更されたデータが失われることはありません。
ダーティ・リード、再現不可能なリード、ファントム・リードの解析
ダーティリード：トランザクションのデータがコミットされていなくても変更され、他のトランザクションが見ることができ、トランザクションは、コミットされていないデータを読み取ることができますダーティリードと呼ばれています。
非再現読み取り：同じトランザクションの前と後の複数の読み取りは、別のトランザクションの途中でも同じデータを操作して、同じデータの内容を読み取ることはできません。
ファントムリード：あるトランザクションがある範囲のレコードを読み取っているときに、別のトランザクションがその範囲に新しいレコードを挿入し、そのトランザクションが再びその範囲のレコードを読み取ると、2つの時間が同じでないことがわかり、ファントムリードが発生します。
ファントム・リードと再現性のないリードの違いは、前者は範囲、後者はそれ自体であり、全体的な結果という点では、どちらも2つのリードの間に矛盾が見られます。
トランザクションの分離レベルは低いものから高いものへと表示されます。
トランザクションの分離レベルが高ければ高いほど、トランザクションの安全性は高まりますが、同時実行性は悪くなります。
リード・アンコミット（リード・アンコミット、リード・アンコミット）
トランザクション内の変更は、コミットされていない場合でも、他のトランザクションを見ることができる、トランザクションがコミットされていないデータを読み取ることができますダーティリードと呼ばれ、また、非再現リード、ファントムリードの問題があります。
リード・コミット（リード・コミット、リード・コミット）
トランザクションの開始後にのみトランザクションに提出されている変更を行うには、トランザクション内で同じクエリを2回実行すると、また、非再現リードとして知られている同じ結果を得ることができない場合があります見ることができる、また、ファントムリード問題に存在します。
Repeatable Read(繰り返し読み取り、mysqlデフォルトのトランザクション分離レベル)
ダーティ・リードと反復不可能なリードの問題を解決するために、MMVCメカニズムを使用して反復可能なリードを実現するファントム・リードの問題があります。ファントムリード: MySQLのInnoDBエンジンは、MVCC、すなわちマルチバージョン同時実行制御によって、この問題を自動的に解決します。
Serializable(シリアライズ可能)
ダーティリード、繰り返し不可能なリード、ファントムリードを解決し、トランザクションのセキュリティを保証することができますが、すべてのトランザクションがシリアルに実行されるため、同時実行効率は低くなります。
Mysql共通ストレージエンジン入門
一般的なストレージエンジン：InnoDB、MyISAM、MEMORY、MERGE、ARCHIVE、CSV...
一般的によく使われるのは、InnoDB、MyISAMです。
MySQL 5.5以上のデフォルトはInnoDBで、5.5のデフォルト・ストレージ・エンジンはMyISAMです。
MysqlのストレージエンジンInnoDBとMyISAMの違いと選択問題
| 事 | サポート | 非対応 |
| ロックの粒度 | 高い同時実行性のための行ロック | テーブルロック、高い同時実行性には不向き |
| デフォルト | デフォルト | デフォルト |
| 外部キーのサポート | 外部キーのサポート | 非対応 |
| シナリオ | リード・ライト・バランシング、ライト・オーバー・リード・シナリオ、必要なトランザクション | リード・マルチ・ライト・シナリオ、トランザクションなし |
| 全文索引 | サポートされていません。プラグインで実装可能です。 | フルテキストインデックスのサポート |
MySQL関数インデックス
| ユニークインデックス | 高速化されたクエリ、一意なカラム値、NULLの許容、組合せインデックス、カラム値の組合せは一意でなければなりません。 | CREATE UNIQUE INDEX idx_name ON table_name(filed_name_1,filed_name_2) |
| 主キーインデックス | 高速化されたクエリ、一意なカラム値、テーブルに対して1つだけ、NULL値の使用不可 | ALTER TABLE table_name ADD PRIMARY KEY |
| カバレッジ・インデックス | インデックスには必要な値が含まれており、"back-to-table "クエリ、例えば、たまたま結合されたインデックスの2つのフィールドに対するクエリは必要ありません。 |
比較指標のメリット・デメリットとノートの使い方
考慮すべき点：実際のビジネス・シナリオに即して、どのようなフィールドにインデックスを作成するか、どのようなタイプのインデックスを作成するか。
インデックスの利点
テーブルの場所を素早く特定し、サーバーがスキャンするデータ量を削減します。 インデックスには実際の値を格納するものもあり、特定のケースでインデックスを使用するだけでクエリを完了させることができます。
インデックスの欠点
インデックスが多すぎると、テーブルの変更時にインデックスの再構築のパフォーマンスが低下します。
インデックス最適化の実践
- プレフィックス・インデックス、特にTEXTとBLOGタイプのフィールドでは、検索速度を向上させるために最初の数文字のみを検索します。
- インデックスの値が長すぎると、クエリの速度に影響します。
- インデックス・カラムの正しい順序の選択
- コンテンツの変更やクエリの頻度が少ないため、より多くのインデックスを構築できます。
- コンテンツは頻繁に変更されるため、インデックスの作成は慎重に
- ビジネスに応じて適切なタイプのインデックスを作成します。例えば、あるフィールドがクエリ条件としてよく使用される場合、クエリ速度を向上させるためにこのフィールド用のインデックスを作成します。
- 結合インデックスは、ビジネスクエリに最も関連性の高いフィールドを選択します。
データベースクエリーコマンドの実行順序
- from どのテーブルから照会るか
- where 初期フィルター基準
- グループ分けのためのフィルターによるグループ分け[強調表示]。
- グループ化されたデータの二次フィルタリング [強調表示]。
- select どの結果フィールドを見るか
- 並べ替えはどのような順序で返されますか？
MySQLvarcharとcharの違い
| 長さの特徴 | 固定長、保存文字数 | 可変長、保存された文字 |
| 長さ不足 | 挿入された長さが定義された長さより短い場合は、空白でパディングされます。 | 定義された長さより小さい場合は、実際の挿入長に従って格納されます。 |
| パフォーマンス | varchar よりもはるかに高速なアクセス | アクセスはcharよりはるかに遅い |
| 使用例 | 携帯電話番号やMD5値など、非常に短い固定長の文字列の保存に適しています。 | 配送先住所や電子メールアドレスなど、長さが可変のシナリオでの使用に適しています。 |
MySQLdatetimeとtimestampの違い
| datetime | 8 バイト数 | 1000-01-01 00:00:00から 9999-12-31 23:59:59 | ストレージはタイムゾーンに依存せず、変化しません。 |
| timestamp | 4 バイト数 | 1970-01-01 00:00:01 から 2038-01-19 11:14:07 | 保存される時間はタイムゾーンに依存し、データベースのタイムゾーンによって変わります。 |
タイムスタンプが2038年までしかないのはなぜですか？
MySQLのタイムスタンプ型は4バイト、最大値は2の31乗マイナス1、結果は2147483647、東京時間に変換すると2038-01-19 11:14:07
大きなデータ量のSQLページングの最適化のアイデア
現象：1000万レベルのデータは、データフロー、ログレコードなど、データベースのページングの通常の深さは非常に遅くなります。遅くなる理由: select * from product limit N,M
MySQLがこのようなSQLを実行する場合、まずN行をスキャンし、次にM行をフェッチする必要があります。 Nが大きくなればなるほど、MySQLがスキャンするレコードの数が増え、SQLのパフォーマンスが低下します。
最適化の方法
1、バックエンドとフロントエンドのキャッシュ；
2、ElasticSearchのページング検索を使用します；
3、mysqlクエリキャッシュの合理的な使用、クエリページング用インデックスのカバー；
select title,cateory from product limit 1000000,100
4、idがセルフインクリメントであり、データの中間削除がない場合、idのオフセット位置を見つけるためにサブクエリの最適化を使用します；
select * from oper_log where type='BUY' limit 1000000,100;
select id from oper_log where type='BUY' limit 1000000,1; // 0.4秒
select * from oper_log where type='BUY' and id>= limit 100; // 0.8秒
