いくつかのMySQL更新操作のケース分析

ケーススタディ

データベースを作成するための DDL:

テーブル `hw_account` を作成します (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(20) デフォルト NULL,
  `balance` int(11) デフォルト NULL,
  `status` varchar(20) デフォルト NULL,
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP、
  `update_time` タイムスタンプ NULL デフォルト CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP、
  主キー (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 デフォルト CHARSET=utf8mb4;

アカウント残高を更新する

直接更新

解決策1: クエリ後に更新する

# データクエリ select * from hw_account where id = 1;

# データを更新します update hw_account set balance = 5 where id = 1;

問題は、操作を 2 つの部分に分割して同時に実行すると、更新が失われる可能性があることです。

楽観的ロック方式

バージョン番号操作を使用します。つまり、データベースに楽観的ロックを追加します。

# データクエリ select * from hw_account where id = 1;

# データを更新 update hw_account set balance = 5 、version = version + 1 
  ここで、id = 1、version = n;
  
# 行 < 1 の場合に成功かどうかを判断します {
   ロールバック}

既存の問題は、このデータが同時に操作されると、他のリクエストが失敗することです。このリクエストのフロントエンドリンクが比較的長い場合、ロールバックコストは比較的高くなります。

ロックフリーソリューション

クエリは必要なく、データベース計算が使用され、バージョン番号操作は必要ありません。有効性はドメイン値を通じて直接判断されます。具体的なSQLは次のとおりです。

# データを更新 update hw_account set balance = balance + @change_num 、version = version + 1 
  ここで、id = 1、version = n;
  
# 行 < 1 の場合に成功かどうかを判断します {
   ロールバック}

このソリューションは変更が比較的簡単ですが、データ計算に依存しており、特にユーザーフレンドリーとは言えません。

キューイング操作

データ要求は、Redis または ZK の分散ロックを通じてキューに入れられます。次にデータを更新します。

# 疑似コード if (分散ロックを取得) {
  hw_account を更新し、balance を @balance に設定し、id を 1 に設定します。
} それ以外 {
  # 待機状態に入るか、スピンしてロックを取得します}

よくある質問

データに update_time フィールドが存在する場合、影響を受ける行数はいくつですか?

update_timeフィールドは次のように定義されます。データがid = 1、status = 1で、データを更新するためのSQL文が

hw_account を更新し、`status` = 1 を設定します (id = 1)。

返される影響を受ける行の数は 0 です。

更新が実行されたが、影響を受ける行数が 0 の場合、行ロックが追加されますか?

はい、すべての更新ステートメントは行ロックを追加します (前提条件、トランザクション内)

参考文献

ウェブ

これで、いくつかの MySQL 更新操作のケース分析に関するこの記事は終了です。より関連性の高い MySQL 更新操作コンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: