MySQLギャップロック（ギャップロック）と遅いクエリ

前の記事-MySql-ロックと物事

ギャップロックと遅いクエリ

ギャップロック

実際、mysqlでは、繰り返し可能な読み取りにより、ギャップロックの助けを借りてファントム読み取りの問題が解決されました。

実験1：

select @@tx_isolation; 
create table t_lock_1 (a int primary key);
insert into t_lock_1 values(10),(11),(13),(20),(40);
begin select * from t_lock_1 where a <= 13 for update; 
  

別のセッションでinsert into t_lock_1 values(21)正常にinsert into t_lock_1 values(19)ブロックされました

rr分離レベルでは、そのうちの1つが現在の値（13）の次の値（20）までスキャンし、これらすべてのデータをロックします

実験：2

create table t_lock_2 (a int primary key,b int, key (b)); 
insert into t_lock_2 values(1,1),(3,1),(5,3),(8,6),(10,8);

会话1は、
BEGIN
更新用t_lock_2ここで、b = 3 SELECT * FROM。

1 3 5 8 10
1 1 3
68セッション2

select * from t_lock_2 where a = 5 lock in share mode; -- 不可执行，因为 a=5 上有一把记录锁 
insert into t_lock_2 values(4, 2); -- 不可以执行，因为 b=2 在(1, 3]内 
insert into t_lock_2 values(6, 5); -- 不可以执行，因为 b=5 在(3, 6)内 
insert into t_lock_2 values(2, 0); -- 可以执行，(2, 0)均不在锁住的范围内 
insert into t_lock_2 values(6, 7); -- 可以执行，(6, 7)均不在锁住的范围内 
insert into t_lock_2 values(9, 6); -- 可以执行 
insert into t_lock_2 values(7, 6); -- 不可以执行

セカンダリインデックスのロック範囲は（1、3]、（
3、6 ）です。プライマリキーインデックスは、a = 5のレコードのみをロックします[5]。

トランザクション文法

トランザクションを開く

1、開始
2、トランザクションの
開始（推荐）3、作業の開始

トランザクションのロールバック

ロールバック

トランザクションコミット

コミット

復元ポイント（デモ）

savepoint 
show variables like '%autocommit%'; 自动提交事务是开启的 
set autocommit=0; insert into testdemo values(5,5,5); 
savepoint s1; 
insert into testdemo values(6,6,6); 
savepoint s2; 
insert into testdemo values(7,7,7); 
savepoint s3; 
select * from testdemo 
rollback to savepoint s2 rollback

ビジネスデザイン

論理設計

パラダイムデザイン

データベース設計の最初のパラダイム。
データベーステーブルのすべてのフィールドには単一の属性しかありません
。単一の属性の列は基本的なデータタイプで構成されています。
設計されたテーブルは単純な2次元テーブルです。name

-age列には2つの属性があります。 。名前と年齢が最初のパラダイムに準拠していません。2つの列に分割してください

。データベース設計の2番目のパラダイムでは
、テーブルにビジネスプライマリキーが1つだけ必要です。つまり、2番目のパラダイムに準拠しているテーブルではできません。非プライマリキー列があります。プライマリキーの依存関係の一部
2つのテーブルがあります。注文テーブル、製品テーブル、


1つの注文には複数の製品があるため、注文のプライマリキーは、[注文ID]と[注文ID]で構成される結合されたプライマリキーです。 [製品ID]であるため、2つのコンポーネントは第2正規形に準拠しておらず、製品IDと注文IDは強く関連していないため、注文テーブルは注文テーブルと注文と商品の中間テーブルに分割されます。

データベース設計の3番目のパラダイム
は、すべての非プライマリ属性が部分的に依存しておらず、トランジットがビジネスプライマリキーに依存していないことを意味します。つまり、2番目のパラダイムに基づいて、非プライマリキーのトランジショナル依存に基づいて主キー。

顧客番号と注文番号は、
顧客名と注文番号に関連付けられています。顧客番号が変更さ
れると、顧客番号と顧客名が関連付けられ
ます。、ユーザーの名前も変更されますが、 3番目のパラダイム、顧客名列を削除する必要があります

クエリテスト

各ユーザーの注文の合計金額（ユーザー名、合計注文金額）

を照会するSQLを記述します。ユーザーと注文の詳細（注文番号、ユーザー名、携帯電話番号、製品名、製品数量、
製品価格）を照会するSQLを記述します

。多数のテーブルの関連付けは、クエリのパフォーマンスに大きく影響します。正規化された設計に
完全に準拠しています。SQLクエリの良好なパフォーマンスが得られない場合があります。

アンチパラダイムデザイン

アンチパラダイムデザインとは

• 反パラダイム化はパラダイム化を目的としています。データベース設計パラダイムは前のセクションで紹介されました。
• いわゆる非正規化は、パフォーマンスと読み取り効率の考慮事項に関するデータベース設計パラダイムの要件に違反することです。
• 少量の冗長性が許可されます。言い換えると、非正規化は時間と引き換えにスペースを使用することです。

総括する

要件パラダイムに従って完全に設計することはできません。
検討後のテーブルの使用方法でした。

パラダイム設計の長所と短所

長所：
データの冗長性を可能な限り減らすことができます。
正規化された更新操作は非正規化された
テーブルよりも高速です。正規化されたテーブルは通常、非正規化されたテーブルよりも小さくなります。
短所：
クエリの場合、複数のテーブルを関連付ける必要があります。
より困難です。インデックスの最適化を実行します。

アンチパラダイム設計の長所と短所

長所：
テーブルの関連付けを減らし、
インデックス作成をより適切に最適化できます。
短所：
データの冗長性と異常なデータのメンテナンス。
データの変更にはより多くのコストが必要です。

物理的設計

命名規則

データベース、テーブル、およびフィールドの名前は、読みやすさの原則に従う必要があります

読みやすさを向上させるためにライブラリオブジェクト名をフォーマットするユースケース。たとえば、読みやすさを向上させるために、custaddressの代わりにcustAddressを使用します。
データベース、テーブル、およびフィールド
の名前は、イデオグラフィックの原則に準拠している必要があります。オブジェクトの名前は、それが表すオブジェクトを説明できる必要があります。
例：テーブルの場合、テーブルの名前は、テーブルに格納されたデータ。
ストアドプロシージャの場合、ストアドプロシージャはストレージを反映できる必要があります。プロセスの機能。
データベース、テーブル、およびフィールドの名前付けは、長い名前の原則に準拠する必要があります
。データ型の選択を選択するために、省略形の
ストレージエンジンをできるだけ使用しないか、使用しないでください。列が複数のデータ型を選択できる場合数値型が優先されます次は日付と時刻の型最後に文字型です同じレベルのデータ型の場合、小さなスペースを占めるデータ型を優先する必要があります。浮動小数点型の日付型。インタビューでは、タイムスタンプ型と日時。5.6では日時タイプは5バイトです。日時タイプは5.5です。フィールド長は8バイトです。タイムスタンプはタイムゾーンに関連していますが、日時は関係ありません。

遅いクエリ

遅いクエリとは

低速クエリログは、その名前が示すように、低速クエリログです。これは、mysqlがlong_query_timeパラメーターで設定された時間しきい値を超えて実行されるすべてのSQLステートメントを記録することを意味します。このログは、SQLステートメントの最適化に大いに役立ちます。デフォルトでは、スロークエリログはオフになっています。スロークエリログ機能を使用するには、最初にスロークエリログ機能を有効にする必要があります。

遅いクエリ構成

遅いクエリの基本構成

• slow_query_logスタートストップテクノロジースロークエリログ
• slow_query_log_fileは、低速クエリログのストレージパスとファイルを指定します（デフォルトでは、データファイルと一緒に配置されます）
• long_query_time遅いクエリログのSQL実行時間を記録するように指定します（単位：秒、デフォルトは10秒）
• log_queries_not_using_indexesインデックスを使用しないSQLをログに記録するかどうか
• log_outputログが保存される場所[TABLE] [FILE] [FILE、TABLE]
  低速クエリが構成された後、次のような修飾SQLが記録されます
  。
• フレーズを確認する
• データ変更ステートメント
• SQLプラクティスがロールバックされました
  ：
  次のコマンドで上記の構成を確認してください。

 show VARIABLES like '%slow_query_log%' 
 show VARIABLES like '%slow_query_log_file%' 
 show VARIABLES like '%long_query_time%' 
 show VARIABLES like '%log_queries_not_using_indexes%' 
 show VARIABLES like 'log_output' 
 set global long_query_time=0; ---默认 10 秒，这里为了演示方便设置为 0 
 set GLOBAL slow_query_log = 1; --开启慢查询日志 
 set global log_output='FILE,TABLE' --项目开发中日志只能记录在日志文件中，不能记表中 

設定が完了したら、いくつかのリストをクエリして、低速クエリログファイルにデータがあることを確認します。
cat /usr/local/mysql/data/mysql-slow.log

クエリの解釈が遅い

低速クエリログの抜粋、低速クエリログ

解釈内からの次の構成データ、低速クエリ形式

1行目：ユーザー名、ユーザーのIP情報
、2行目のスレッドID番号：実行に費やされた時間[単位：
3行のms] ：ロックを取得するための実行時間
。4行
目：取得した結果行の数。5行目：スキャンされたデータ行の数
。6行目：SQL実行の特定の時間。7行
目行：特定のSQLステートメント。

遅いクエリ分析

遅いクエリログレコードがたくさんあります。そこから遅いクエリログを見つけるのは簡単ではありません。一般的に、最適化する必要のあるSQLステートメントをすばやく見つけるにはいくつかのツールが必要です。2つの遅いクエリ補助ツールを次に示します。

Mysqldumpslow

一般的に使用される低速クエリログ分析ツールは、クエリ条件を除いて同じSQLを要約し、パラメータで指定された順序で分析結果を出力します。
構文：
mysqldumpslow -sr -t 10 slow-mysql.log
-s order（c、t、l、r、at、al、ar）
    c：合計回数
    t：合計時間
    l：ロック時間
    r：合計データ行
    at、al、ar：t、l、r平均数[例：at =合計時間/合計回数]
-t topは、結果出力として前の日を指定します

mysqldumpslow -s t -t 10 /usr/local/mysql/data/mysql-slow.log

pt_query_digest

mysqlの遅いクエリを分析するためのツールです。mysqldumpshowツールと比較して、py-query_digestツールの分析結果はより具体的で完全です。
権限が不十分な場合など、何らかの理由でクエリをサーバーに記録できない場合があります。
私たちはしばしばそのような制限に遭遇します。抽出コード
を共有する次のコマンドパッケージを最初に見てください
：s0tl

yum -y install 'perl(Data::Dumper)'; 
yum -y install perl-Digest-MD5 
yum -y install perl-DBI
yum -y install perl-DBD-MySQL

perl ./pt-query-digest --explain h=127.0.0.1,u=root,p=root1234% /usr/local/mysql/data/mysql-slow.log

要約情報[合計クエリ時間]、[合計ロック時間]、[合計取得データ量]、[スキャンデータ量]、[クエリサイズ]
応答：合計応答時間。
時間：この分析におけるクエリの合計時間の割合。
呼び出し：実行の数、つまり、この分析にこのタイプのクエリがいくつあるか。
R / Call：実行ごとの平均応答時間。
アイテム：クエリオブジェクト

拡張読書：

構文と重要なオプション
pt-query-digest [OPTIONS] [FILES] [DSN]

• --Create-review-table --reviewパラメーターを使用して分析結果をテーブルに出力する場合、テーブルがない場合は自動的に作成されます。
• –create-history-table –historyパラメーターを使用して分析結果をテーブルに出力する場合、テーブルがない場合は自動的に作成されます。
• --Filter入力の遅いクエリは、分析前に指定された文字列に従って照合およびフィルタリングされます
• --Limitは、出力結果のパーセンテージまたは数を制限します。デフォルト値は20です。つまり、最も遅い20文が出力されます。50％の場合、合計応答時間は大きいものから小さいものへと並べ替えられ、出力されます。合計が50％に達した位置で停止します。
• -ホストmysqlサーバーアドレス--usermysqlユーザー名
• --Password mysqluserpassword--history分析結果をテーブルに保存します。同じステートメントがあり、クエリの時間間隔が履歴と異なる場合は、次に--historyを使用するときに、分析結果がより詳細になります。次に、データテーブルに記録され、同じCHECKSUMをクエリすることで、特定のタイプのクエリの履歴変更を比較できます。
• -レビュー分析結果をテーブルに保存します。この分析は、クエリ条件をパラメータ化するためだけのものです。タイプごとに1つのレコードをクエリするのは比較的簡単です。次回-reviewを使用する場合、同じセンテンス分析が存在する場合、データテーブルには記録されません。
• -出力分析結果の出力タイプ。値はレポート（標準分析レポート）、slowlog（Mysqlスローログ）、json、json-anonで、通常は読みやすいようにレポートを使用します。
• –分析を開始するときから、値は文字列であり、「yyyy-mm-dd [hh：mm：ss]」の形式で指定した時点、または単純な時間値：s（seconds）、 h（時間）、m（分）、d（日）。たとえば、12hは、統計が12時間前に開始されることを意味します。
• -期限まで、-を使用すると、一定期間内に遅いクエリを分析できます。

pt-query-digestの出力を分析します

パート1：全体的な統計

• 全体：クエリは合計でいくつありますか
• 時間範囲：クエリ実行時間範囲
• 一意：一意のクエリの数、つまり、クエリ条件をパラメータ化した後に存在するさまざまなクエリの数
• 合計：合計最小：最小最大：最大平均：平均
• 95％：すべての値を小さいものから大きいものまで配置します。数値は95％にあり、この数値は通常、最も参照値が高くなります。
• 中央値：中央値、すべての値を小さいものから大きいものまで、中央の数値に配置します

# 该工具执行日志分析的用户时间，系统时间，物理内存占用大小，虚拟内存占用大小 
# 340ms user time, 140ms system time, 23.99M rss, 203.11M vsz 
# 工具执行时间 # Current date: Fri Nov 25 02:37:18 2016 # 运行分析工具的主机名 
# Hostname: localhost.localdomain 
# 被分析的文件名 # Files: slow.log 
# 语句总数量，唯一的语句数量，QPS，并发数 
# Overall: 2 total, 2 unique, 0.01 QPS, 0.01x concurrency 
# 日志记录的时间范围 # Time range: 2016-11-22 06:06:18 to 06:11:40 
# 属性 总计 最小 最大 平均 95% 标准 中等 
# Attribute total min max avg 95% stddev median 
# ============ ======= ======= ======= ======= ======= ======= ======= 
# 语句执行时间 
# Exec time 3s 640ms 2s 1s 2s 999ms 1s 
# 锁占用时间 
# Lock time 1ms 0 1ms 723us 1ms 1ms 723us 
# 发送到客户端的行数 
# Rows sent 5 1 4 2.50 4 2.12 2.50 
# select 语句扫描行数 
# Rows examine 186.17k 0 186.17k 93.09k 186.17k 131.64k 93.09k 
# 查询的字符数 
# Query size 455 15 440 227.50 440 300.52 227.50

パート2：グループ統計結果のクエリ

• ランク：すべての文のランキング。デフォルトでは、クエリ時間の降順で、-order-byで指定されます。
• クエリID：ステートメントのID（余分なスペースとテキスト文字を削除し、ハッシュ値を計算します）
• 応答：合計応答時間
• 時間：この分析におけるクエリの合計時間
• 呼び出し：実行の数、つまり、この分析にはこのタイプのクエリステートメントがいくつあるか
• R / Call：実行ごとの平均応答時間
• V / M：応答時間の分散対平均比
• アイテム：クエリオブジェクト

# Profile # Rank Query ID Response time Calls R/Call V/M Item
# ==== ================== ============= ===== ====== ===== ===============
# 1 0xF9A57DD5A41825CA 2.0529 76.2% 1 2.0529 0.00 SELECT 
# 2 0x4194D8F83F4F9365 0.6401 23.8% 1 0.6401 0.00 SELECT wx_member_base

3番目の部分：各クエリの詳細な統計結果
以下のクエリの詳細な統計結果から、上の表に実行時間、最大、最小、平均、95％およびその他の統計が一覧表示されます。

• ID：クエリのID番号。上の図のクエリIDに対応します。
• データベース：データベース名ユーザー：各ユーザーの実行回数（割合）
• Query_time分布：クエリ時間分布。長さは間隔の比率を反映します。この例では、1秒から10秒の間のクエリ数は10秒の2倍以上です。
• テーブル：クエリに関係するテーブル
• 説明：SQLステートメント

# Query 1: 0 QPS, 0x concurrency, ID 0xF9A57DD5A41825CA at byte 802 
# This item is included in the report because it matches --limit. # Scores: V/M = 0.00 
# Time range: all events occurred at 2016-11-22 06:11:40 
# Attribute pct total min max avg 95% stddev median 
# ============ === ======= ======= ======= ======= ======= ======= ======= 
# Count 50 1 # Exec time 76 2s 2s 2s 2s 2s 0 2s 
# Lock time 0 0 0 0 0 0 0 0 # Rows sent 20 1 1 1 1 1 0 1 
# Rows examine 0 0 0 0 0 0 0 0 # Query size 3 15 15 15 15 15 0 15 # String: 
# Databases test # Hosts 192.168.8.1 # Users mysql # Query_time distribution 
# 1us 
# 10us 
# 100us 
# 1ms 
# 10ms 
# 100ms 
# 1s ################################################################ 
# 10s+ 
# EXPLAIN /*!50100 PARTITIONS*/ 
select sleep(2)\G