MySQL-最後の行が削除された場合、自動インクリメントは連続してインクリメントしません

自動インクリメントされた主キーIDを含むテーブルがあります。最後の行（たとえば、最高のID、たとえばid = 6）を削除して新しい行を挿入すると、新しいIDは7から始まります。主キーが6から始まることを変更する必要があるパラメーターはどれですか。

CREATE TABLE animals (
 id MEDIUMINT NOT NULL AUTO_INCREMENT,
 name CHAR(30) NOT NULL,
 PRIMARY KEY (id)
) ENGINE=MyISAM;

INSERT INTO animals (name) VALUES
('dog'),('cat'),('penguin'),
('lax'),('whale'),('ostrich');

結果：
ID名
1犬
2猫
3ペンギン
4亜麻
5クジラ
6ダチョウ

DELETE FROM animals WHERE id = 6;
INSERT INTO animals (name) VALUES
('x');

結果：
ID名
1犬
2猫
3ペンギン
4緩い
5クジラ
7 x

アドバイスをありがとう。

これは設計によるものです。すべてのDBMSは、これを自動インクリメント列で実行していました。

それらを行わなかった場合、外部参照整合性が損傷する可能性があります。この簡単な例として、自動インクリメント列をキーとして使用して、短縮サービスのURLを保存しているとします。短縮URLがまだ誰にも配布されていないかどうかはわかりませんし、データベースも確かに配布されていないため、ID 1234を再利用すると、http：/ /shortthi.ng/1234は、「申し訳ありませんが、このリンクはレコードに存在しません」というメッセージを代わりに、古いメールにれています。

また、最後のアイテムを削除した後に増分をリセットすると、5番目のアイテムが削除されたときに、500万の5番目のアイテム以降のすべての番号を付け直すすべての作業（またはデータベースが期待すること）も実行されますか？インクリメント列を指す外部キー制約である他のテーブルへの変更を完了しましたか？そのような余分な作業は、IOに関しては非常に高価になる可能性があります。

あなたがするなら最後の項目を削除した後インクリメントポイントをリセットし、あなたのトランザクション分離レベルの非常に非常に気をつけてください：あなたは別のトランザクションがエラー（または悪化し、サイレント障害）につながる、値を使用すると同じように、それをリセットするかもしれない、しない限り、アクションが完全に分離されていることを確認します。

私は通常、データベースで作業している人に、この問題に関する「疑似キーニートフリークス」という章がある「SQLアンチパターン」を読むことをお勧めします（章のタイトルが示唆しているよりもわかりやすい方法で問題をカバーしています！）。基本的に、値がキー（またはせいぜい挿入順序情報）を超える意味を持つ場合、おそらく自動インクリメント列であってはならず、キー（またはせいぜい挿入順序情報）以外の意味がない場合情報）ギャップは重要ではありません。

以下を使用してauto_increment値をリセットできます。

ALTER TABLE MyTable AUTO_INCREMENT = 1234;

上記のステートメントで使用するには、テーブルに存在する最大値を決定し、その値に1を追加する必要があります。