MySQL innodb の自己インクリメント ID バグの影響をご存知ですか?

これまでの MySQL はすべて無駄に使われてきました。 。 。 MySQL innodb ID の自動インクリメントのバグが既存のシステムの 99% に影響を与えることをご存知ですか。 。 。

まず、この魔法の問題を再現しましょう:

自動インクリメント ID を持つテスト テーブルを作成し、3 つの部分を挿入します。のデータを削除し、ID = 3 のデータを削除します。

DROP TABLE IF EXISTS `test`;
CREATE TABLE `test`  (
  `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;
 
insert into test values ();
select LAST_INSERT_ID();
insert into test values ();
select LAST_INSERT_ID();
insert into test values ();
select LAST_INSERT_ID();
delete from test where id = 3;

次に、MySQL サービスを再起動しましょう。

レコードを再度挿入し、最後に挿入された ID を確認します。 。 。

insert into test values ();
select LAST_INSERT_ID();
select * from test;

結果は、再起動してレコードを再度挿入した後でも、ID は 3 のままです。 ！ ！

元の innodb 自動インクリメント ID は、サービスの再起動後にレコード内の最大 ID 1 に自動的に設定されます。

この問題は、物理的に削除されたシステムでは 100% の確率で再現されます。

あるテーブルの自動インクリメント ID が他のレコードにも関連付けられると仮定します。

極端な場合には、サービスを再起動する前に最大の ID を持つレコードが削除され、サービスが復元された後にそのレコードが挿入されて関連付けられます。 。 。

データの混乱の問題は想像できません。

幸いなことに、この問題は MySQL 8.0 で修正されました。

MySQL 5.7 以前のバージョンのユーザーであれば、心配する必要はありません。さまざまな解決策は次のとおりです:

* システム内のすべての物理的な削除を論理的な削除に変更します。通常、フレームワークにはこの機能が組み込まれており、修正や再構築に非常に便利です。

## innodb_autoinc_persistent 設定を有効にすると、1% のパフォーマンス損失が発生しますが、無視できます。

innodb_autoinc_persistent=on
innodb_autoinc_persistent_interval=1

推奨学習: 「

MySQL ビデオ チュートリアル 」

以上がMySQL innodb の自己インクリメント ID バグの影響をご存知ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。