タグ付けされた質問 「auto-increment」

自動キー作成のための数値シーケンス生成

2
MySqlのLAST_INSERT_ID()関数は正しいことが保証されていますか?
列INSERTを持つテーブルに単一の行を作成するAUTO_INCREMENT場合、LAST_INSERT_ID()関数を使用して、AUTO_INCREMENTその行に格納されている新しい'ed値を返します。 多くのMicrosoft SQL Server開発者と管理者がSQL Server(SCOPE_IDENTITYおよび@@IDENTITY)の同等の機能に問題がないことに気付いていないことは間違いない。 MySQLドキュメントの状態を知っています: 生成されたIDは、接続ごとにサーバーで維持されます。これは、関数によって特定のクライアントに返される値が、そのクライアントによって列にAUTO_INCREMENT影響を与える最新のステートメントに対して生成される最初の値であることを意味します。他のクライアントが独自の値を生成しても、この値は他のクライアントの影響を受けません。この動作により、各クライアントは、他のクライアントのアクティビティを気にすることなく、ロックやトランザクションを必要とせずに独自のIDを取得できます。AUTO_INCREMENTAUTO_INCREMENT (ソース) さらに言えば: 複数のクライアントからLAST_INSERT_ID()and AUTO_INCREMENT列を同時に使用することは完全に有効です。 (ソース) LAST_INSERT_ID()正しい値を返さない原因となる既知のリスクやシナリオはありますか? CentOS 5.5 x64およびFedora 16 x64およびInnoDBエンジンでMySQL 5.5を使用しています。

3
phpMyAdminでmysqlテーブルの自動インクリメントを1にリセットするにはどうすればよいですか?
MySQLのコマンドラインで、これを使用してテーブルの自動インクリメントフィールドを1にリセットできることを知っています。 ALTER TABLE tablename AUTO_INCREMENT = 1 phpMyAdmin内からこれを行う方法があるかどうか興味があります。これらの行に沿って自動インクリメントまたは他の何かをリセットするチェックボックスのようなものはありますか? コマンドラインアプローチに問題があるわけではありません。私が考え続けている好奇心のもっと多くのもの...事前に感謝します!

8
大きなID値を避ける理由
私たちは、ユーザーがまだアクセスできないWebアプリケーションに取り組んでいます。上司は、テーブルに100未満のレコードしかないにもかかわらず、新しく作成されたレコードが10000を超えるIDを取得することに気付きました。彼女は、何らかの理由でWebインターフェースが実際のレコードよりも100倍以上の一時的なレコードを作成(および削除)し、これによりリリース後数か月以内に範囲外になる可能性があると考えました。 彼女はIDインフレーションの原因について正しいとは思わない(これに答えることができる同僚は休暇中なので、私たちは確実に知らない)が、彼女がそうであると仮定しよう。彼女は、bigintカラムを使用するのは嫌いで、IDカラムの自動インクリメントを停止し、最初の「未使用」整数を選択してそれをIDとして使用するサーバー側コードを記述してほしいと言いました。 私はコンピューターサイエンスの大学院生であり、実務経験がほとんどなく、開発者の若手として働いています。彼女は、当社のすべてのデータベースを管理し、それらのほとんどを設計した長年の経験を持っています。私が考える BIGINT IDがの恐れることは何もない、とDBMSの機能を模倣することはアンチパターンの匂いということを、彼女はこの場合には正しくないということ。しかし、私はまだ自分の判断を信用していません。 各ポジションの賛否両論は何ですか?bigintを使用すると、どのような悪いことが起こる可能性がありますか?ホイールの自動インクリメント機能を再発明することの危険性は何ですか?どちらよりも優れた3番目のソリューションはありますか?IDの額面価格の上昇を避けたい理由は何でしょうか?私は実用的な理由についても興味があります-bigint IDは理論的には機能するかもしれませんが、実際には頭痛の種になりますか? アプリケーションが非常に大量のデータを処理することは想定されていません。今後数年以内に実際の記録が10,000件に達するとは思わない。 違いがある場合は、Microsoft SQLサーバーを使用しています。アプリケーションはC#で記述され、Linq to SQLを使用します。 更新 ありがとう、私は既存の答えとコメントがおもしろいと思った。しかし、あなたは私の質問を誤解したのではないかと思うので、彼らは私が知りたいことを含んでいます。 高いIDの本当の理由についてはあまり心配していません。自分で見つけられない場合は、別の質問をすることができます。私が興味を持っているのは、この場合の決定プロセスを理解することです。このため、アプリケーションが1日あたり1000レコードを書き込み、そのうちの9999レコードを削除すると想定してください。これは事実ではないと確信していますが、これは上司が要求したときに信じていたものです。したがって、これらの仮想的な状況では、bigintを使用するか、IDを割り当てる独自のコードを作成することの長所と短所は何ですか(すでに削除されたレコードのIDを再利用し、ギャップがないようにする)? 実際の理由については、別のデータベースからデータをインポートするコードを書いたことが、後の移行がある程度できるという概念の証明として、私が強く疑っています。私の同僚は、実際にインポート中に数千のレコードを作成し、後でそれらを削除したと思います。これが実際にそうだったかどうかを確認する必要がありますが、もしそうなら、アクションの必要さえありません。

3
IDENTITY値をリセット
IDENTITY列のあるテーブルがあります。開発中に、時々行を削除し、再度追加します。しかし、IDENTITY値は常に増加し続け、それらを再度追加したときに1から始まっていませんでした。私のIDは68から> 92になり、これによりコードがクラッシュします。 IDENTITY値をリセットするにはどうすればよいですか?

1
「エラー:重複キー値が一意制約に違反する」を回避するためにテーブル構造を修正する
この方法で作成されたテーブルがあります: -- -- Table: #__content -- CREATE TABLE "jos_content" ( "id" serial NOT NULL, "asset_id" bigint DEFAULT 0 NOT NULL, ... "xreference" varchar(50) DEFAULT '' NOT NULL, PRIMARY KEY ("id") ); その後、IDを指定していくつかの行が挿入されます。 INSERT INTO "jos_content" VALUES (1,36,'About',...) 後で、IDなしでいくつかのレコードが挿入され、エラーで失敗します: Error: duplicate key value violates unique constraint。 どうやらidはシーケンスとして定義されました: 挿入に失敗するたびに、存在しない値に増分し、クエリが成功するまで、シーケンス内のポインターが増加します。 SELECT nextval('jos_content_id_seq'::regclass) テーブル定義の何が問題になっていますか?これを修正するスマートな方法は何ですか?

2
pgAdminで列を自動インクリメントするように指定するにはどうすればよいですか?
PostgreSQLデータベースを管理するためにpgAdmin IIIを学び始めました。しかし、それは使いやすいアプリケーションではありませんでした。 pgAdmin IIIでテーブルを作成または作成した場合、整数型の列IDに「自動インクリメント」機能を追加するにはどうすればよいですか?

4
既存のPKに自動インクリメントを追加する
別のDBに既に存在するDBにテーブルを作成しました。最初は古いDBデータが入力されていました。テーブルのPKは、それらのレコードに既に存在する値を受信する必要があったため、自動インクリメントすることはできませんでした。 ここで、PKを自動インクリメントとして使用する新しいテーブルが必要です。しかし、PKが既に存在し、データを取得した後、どうすればそれができますか?

1
CREATE TABLE…AS SELECTの主キーの自動インクリメント
を介して複雑な選択クエリを使用してテーブルを作成しましたCREATE TABLE ... AS SELECT...。このクエリに自動インクリメントの主キーを追加するにはどうすればよいですか? 例えば: create table `user_mv` select `user`.`firstname` as `firstname`, `user`.`lastname` as `lastname`, `user`.`lang` as `lang`, `user`.`name` as `user_name`, `group`.`name` as `group_name` from `user` inner join `user_groups` on (`user`.`user_id`=`user_groups`.`user_id`) left join `group` on (`group`.`group_id`=`user_groups`.`group_id`) where `user`.`lang`=`group`.`lang` このクエリは、含まれているテーブルを作成しfirstname、lastname、lang、username、group_nameコラム。id自動インクリメントの主キーである列も必要です。 このクエリを変更してこれを行う方法はありますか?このクエリを実行した後にテーブルを変更することでそれができることはわかっていますが、create tableステートメントで直接これを行う方法がある場合は、その方法を知りたいです。

2
auto_incrementキーはINSERTでどのように処理されますか(SELECT * FROM…)
私が持っているtable1とtable2MySQLのインチ どちらにも主auto_incrementキーがありますid。 テーブルスキーマが一致していINSERT INTO table1 (SELECT * FROM table2)て、に挿入された新しい行に関してどうなりtable1ますか?id行の値table1が同じである場合、古い値を保持して競合を生成しidますか?auto_incrementによって新しい値が生成されますか?ストレージエンジンまたはロックに依存しますか?

4
ID列の再シード:必要な場合
大学(私は学生です)での最後のレッスンの1つで、講師から、データベース(必要に応じてMySQLサーバー)と、データベースをデータソースとして使用する小さなクライアントアプリを開発するように依頼されました。 要件の1つは、ID列(すべてのテーブルのPK)が連続している必要があることです。つまり、テーブル行が削除された場合、そのPKは後続の挿入で再利用する必要があります。RDBMS、PK、およびID列に関する平均的な知識があります。私が理解していることから、そのID列は、行を挿入するときにDBがPKを自動生成できるようにするための手段にすぎません。また、ID列の値は、(自然キーではない限り)行属性とは一切関係しません。 この要件(厳密に連続したID列)は私には不審でした。IDがシーケンシャルでない(削除によるギャップがある)場合、何が悪いのかを講師に尋ねてみましたが、「ユーザーにとっては便利であり、データベースを保守するDB管理者にとっては便利」という非常に抽象的な回答を得ました。具体的な例はありません。「ユーザーにとって便利」という議論は、ビジネスドメインでは何の意味もないため、ばかげているように思われます。 したがって、これらの理由が本当かどうか知りたいのですが。ID列を再シードする必要がある場合、つまりIDスペースが使い果たされた場合の1つだけを考えることができます。ただし、これは、ID列のタイプが誤って選択された場合int、bigintつまりuniqueidentifierテーブルに10億行が含まれている代わりに、または単純である場合に、より設計上の問題になります。ID列がクラスター化インデックスであるとします。ID列のギャップがインデックスのパフォーマンスに影響を与える可能性はありますか?多分私が知らない削除ごとに自動ID列が再シードされる実際の理由は他にもありますか? 前もって感謝します!

1
なぜ自動インクリメントは、挿入された行数を超えてジャンプするのですか?
auto_incrementストアドプロシージャを使用して一括挿入を実行した後、BidsテーブルのbidIDに記録されている値に見られるこの奇妙な動作に非常に混乱しています。 INSERT INTO Bids (itemID, buyerID, bidPrice) SELECT itemID, rand_id(sellerID, user_last_id), FLOOR((1 + RAND())*askPrice) FROM Items WHERE closing BETWEEN NOW() AND NOW() + INTERVAL 1 WEEK ORDER BY RAND() LIMIT total_rows; たとえばauto_increment、開始時にbidID値が101であり、100行挿入した場合、終了値は201ではなく213になります。ただし、挿入された行のbidIDは、最大201まで順次実行されます。 以下を確認して、 SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 1 | | …

4
MySQL:auto_incrementが主キーだけに制限されているのはなぜですか?
MySQLがauto_incrementカラムを主キーに制限していることを知っています。どうしてこれなの?私の最初の考えは、この値を取得するためにロックする必要があるカウンターテーブルがどこかにある可能性があるため、これはパフォーマンスの制限だということです。 同じテーブルに複数のauto_increment列を含めることができないのはなぜですか? ありがとう。

2
主キーを持つ「INTO」テーブルを作成する
たぶんこのコミュニティにとって私の問題は簡単ですが、私(単純なJavaプログラマー)にとってはそれは大きな問題です。 ますます多くのデータを含むBig DBがあります。したがって、外部データベース管理者は、一時テーブルに必要なデータを表示するジョブを作成しました。しかし、彼は主キーなしでテーブルを作成していました。私のJavaプロジェクトでこのテーブルを読みに行くと、エラーが発生します。 主キーが存在しないため、このテーブルを読み取ることができません。 この複雑なプロシージャの構造を変更せずに、自動インクリメンタル主キーを作成する可能性をプロシージャに挿入できますか? これは、ストアドプロシージャコードの始まりです。 USE [MYDB] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER Procedure [dbo].[spSchedula_Scadenzario] as begin drop table MYDB.dbo.tmpTable select aa.* into MYDB.dbo.tmpTable from (...) 前もって感謝します

2
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'); 結果: …

2
MySQL Auto_incrementが2行2列に進む
先日、MySQL Workbenchをインストールし、会社のデータベースにアクセスして、自分で作業するためのテーブルを作成しました。ここまでは順調ですね。問題は、auto_incrementが2ずつ増加していることに気づいたことです。次に例を示します。 ID NAME 1 Paul 3 Jack 5 Louis 7 John ... 私がするとき、私はSHOW VARIABLES LIKE 'auto_inc%'これを手に入れます: 'auto_increment_increment', '2' 'auto_increment_offset', '1' だから私はauto_increment_increment1に設定してみました: SET @@auto_increment_increment=1 そして、もう一度SHOW VARIABLES LIKE 'auto_inc%'確認したところ、「動作する」という結果で確認されました。 'auto_increment_increment', '1' 'auto_increment_offset', '1' しかし、私のIDはまだ2ずつ増加しています。 最初にそれを実行したとき、それはうまくいき、それからMySQL Workbenchを閉じて、もう一度開いたときに、再び2auto_increment_incrementに設定されていることに気付きました。今、私はもう一度それをやろうとしていますが、それはもううまくいかないようです。 誰か助けてくれますか? みんなありがとう。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.