タグ付けされた質問 「delete」

データベース構造化照会言語(SQL)では、DELETEステートメントはテーブルから1つ以上のレコードを削除します。

1
削除ステートメントで使用されないクラスター化インデックス
次のように定義されたSQL Serverテーブルがあります CREATE TABLE [dbo].[Production_Detail] ( [Id] [bigint] NOT NULL DEFAULT (NEXT VALUE FOR [dbo].[Production_Detail_Seq]), [Meta_Data_ID] INT NOT NULL , [Production_Detail_Time] DATETIME NOT NULL, [Production_Detail_Time_Local] DATETIME NOT NULL, [Production_Detail_Value] FLOAT NULL, [IntegratedDM] BIT NOT NULL DEFAULT 0, [DailyIntegratedDM] BIT NOT NULL DEFAULT 0, [InsertedDate] DateTime NOT NULL, [ModifiedDate] DateTime NOT …

1
削除とバキュームのディスクファイル効果
私は、2億4000万行の非常に頻繁に更新されるテーブルを持っています(そして成長しています)。3時間ごとに150万行が挿入され、150万行が削除されます。クラスターをSSDに移動すると、この一括挿入(コピーを使用)時間は22分から2.3分に短縮されました。削除時間も改善されました。この一括更新は2時間ごとまたは1時間ごとに行う予定です。 現在のパフォーマンス(SSD後)は、より頻繁な更新と互換性がありますが、書き込みの増幅と組み合わされたNANDの耐久性の限界によるSSDの死に関するいくつかの恐ろしい話を読みました。SSDは高価なので、可能な限り将来的にその死を押し上げたいと思います。したがって、私の質問:削除とその後のバキュームでディスクファイルは実際にどうなりますか?私は2つのディスク書き込みがあると思います。1つは行を削除済みとしてマークし、もう1つはバキュームして上書き可能としてマークします。削除とバキュームを行う代わりに、一括挿入/削除のたびにテーブルを作成および削除するテーブルをパーティション分割すると、SSDの摩耗を最小限に抑えることができますか?

1
DELETEがSELECTよりもはるかに遅いのに、IDでDELETEするのはなぜですか?
私はかなり忙しいInnoDBテーブルを持っています(200,000行、1秒あたり数十のクエリのようなものだと思います)。バグが原因で、(同じ)無効なメールアドレスが含まれる14行を取得し、それらを削除したいと考えました。 私は単純にしようとしたDELETE FROM table WHERE email='invalid address'と、約50秒後に「ロック待ちタイムアウトを超えて」しまいました。行の列にはインデックスが付けられていないため、これは驚くべきことではありません。 しかし、私はそうしSELECT id FROM table WHERE email='invalid address'、それは1.25秒かかりました。実行DELETE FROM table WHERE id in (...)、コピー、貼り付けSELECTの結果から、IDSは、0.02秒を要しました。 何が起こっている?条件付きのDELETEが非常に遅いためタイムアウトする理由を誰かが説明できますか? ありがとう。 編集:リクエストに応じて、テーブル構造といくつかのexplain結果を投稿しました。また、このテーブルを参照する外部キーがないことにも注意してください。 しかし、状況は私には簡単に思えます。私が選択しているインデックスのないフィールドがあります。これにはテーブル全体をスキャンする必要がありますが、それほど大きくありません。idは主キーであるため、IDによる削除は非常に高速です。 mysql> show create table ThreadNotification2 \G *************************** 1. row *************************** Table: ThreadNotification2 Create Table: CREATE TABLE `ThreadNotification2` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `alertId` bigint(20) DEFAULT …

2
MySQL-それ自体を参照する外部キー制約を持つ行を削除します
ユーザーが私のウェブサイトに投稿したすべてのフォーラムメッセージを保存するテーブルがあります。メッセージ階層構造は、入れ子集合モデルを使用して実装されます。 以下は、テーブルの単純化された構造です。 Id(主キー) Owner_Id(IDへの外部キー参照) Parent_Id(IDへの外部キー参照) nleft そろそろ nlevel これで、テーブルは次のようになります。 + ------- + ------------- + -------------- + ---------- + ----------- + ----------- + | Id | Owner_Id | Parent_Id | nleft | nright | nlevel | + ------- + ------------- + -------------- + ---------- + ----------- + ----------- + | 1 …

3
カスケード削除を避けるべき時期はありますか?
SQL Server 2008には、1対多の関係で他の3つの子テーブルにリンクされているプラ​​イマリテーブルがあります。したがって、プライマリテーブルでカスケード削除を使用して、プライマリテーブルのレコードが削除されると子テーブルのすべてのレコードが削除されるようにすることを検討しています。 では、カスケードは正しい選択をここで削除しますか? カスケードdeteleを使用しない場合

3
データベースを安全に完全に削除するためのベストプラクティスは何ですか?
私たちは「有機的な」環境を持っています。つまり、人々は最小限の監視またはドキュメント化でコードにコードを10年間積み上げてきました。私が使用しているサーバーには、もう使用されていないと思われるいくつかのデータベースがあります。それらを削除して、実際に使用している3つだけを残したいです。 無謀な極端では、これらのデータベースを無効にして、誰かが悲鳴を上げるのを待つことができました。もう一方では、「念のため」、それらを永久に実行したままにすることができます。サーバーが使用されているかどうか、およびその方法を特定する上で、どのような手順が重要であると思いましたか? また、システムを無効にすることで前進するときに、一定期間便利に元に戻せるようにするためにどのような手順を推奨しますか(オブジェクトを完全に削除するのではなく、名前を変更するなど)? ありがとう!

2
大規模な削除クエリがフリーズしているようです
18億行のデータベースで削除クエリを実行しました。この削除により、12億行が削除されます。 後から考えて、このクエリを一度に100mに分割したはずですが、24時間実行されていて、ログファイルがログファイルに許可されている最大サイズである2Tbの位置にいます。 データベースは単純復旧モードです。 このクエリを保存するものはありますか?または、SQL Serverを再起動して何が起こるかを確認する必要がありますか?データベースは使用できなくなりますか?これをできるだけきれいに殺すために私たちにできることはありますか?

4
DELETEステートメントがREFERENCE制約と競合しています
私の状況は次のようになります: テーブルSTOCK_ARTICLES: ID *[PK]* OTHER_DB_ID ITEM_NAME テーブルの場所: ID *[PK]* LOCATION_NAME テーブルWORK_PLACE: ID *[PK]* WORKPLACE_NAME テーブルINVENTORY_ITEMS: ID *[PK]* ITEM_NAME STOCK_ARTICLE *[FK]* LOCATION *[FK]* WORK_PLACE *[FK]* INVENTORY_ITEMSの3つのFKは、明らかに、他のそれぞれのテーブルの「ID」列を参照しています。 ここに関連するテーブルは、STOCK_ARTICLEとINVENTORY_ITEMSです。 これで、上記のデータベースを別のデータベース(OTHER_DB)と「同期」するいくつかの手順(SQLスクリプト)で構成されるSQLジョブがあります。このジョブ内のステップの1つは「クリーンアップ」です。同じIDを持つ他のデータベースに対応するレコードがないSTOCK_ITEMSからすべてのレコードを削除します。次のようになります。 DELETE FROM STOCK_ARTICLES WHERE NOT EXISTS (SELECT OTHER_DB_ID FROM [OTHER_DB].[dbo].[OtherTable] AS other WHERE other.ObjectID = STOCK_ARTICLES.OTHER_DB_ID) しかし、このステップは常に失敗します: DELETEステートメントは、REFERENCE制約「FK_INVENTORY_ITEMS_STOCK_ARTICLES」と競合しました。データベース「FIRST_DB」、テーブル「dbo.INVENTORY_ITEMS」、列「STOCK_ARTICLES」で競合が発生しました。[SQLSTATE 23000](エラー547)ステートメントは終了しました。[SQLSTATE 01000](エラー3621)。ステップは失敗しました。 したがって、問題は、レコードがINVENTORY_ITEMSによって参照されている場合、STOCK_ARTICLESからレコードを削除できないことです。しかし、このクリーンアップは機能する必要があります。つまり、クリーンアップスクリプトを拡張して、最初にSTOCK_ITEMSから削除する必要のあるレコードを特定する必要がありますが、対応するIDがINVENTORY_ITEMS内から参照されているため、できません。次に、最初にINVENTORY_ITEMS内のレコードを削除してから、STOCK_ARTICLES内のレコードを削除します。私は正しいですか?SQLコードはそのときどのように見えますか? ありがとうございました。

3
一括削除後にmysqlテーブルのインデックスを再作成する必要がありますか?
MySQLに、毎秒多くのINSERTとSELECTを実行するテーブルがあります。そして、1日に1回、古いデータの一括削除があります。削除後にテーブルのインデックスを再作成する必要がありますか?性能を上げたい。誰かがいくつかのヒントを提案できますか?ストレージエンジンとして「innodb」を使用する。変更する必要がありますか?同時挿入と選択の方が良いと思います。あなたの提案をお願いします。インデックスの再作成を行う必要がありますか? 前もって感謝します..

3
SQLテーブルから数百万行を削除する
2億2000万以上の行テーブルから1600万以上のレコードを削除する必要がありますが、非常に遅いです。 以下のコードをより速くするための提案を共有していただければ幸いです。 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; DECLARE @BATCHSIZE INT, @ITERATION INT, @TOTALROWS INT, @MSG VARCHAR(500); SET DEADLOCK_PRIORITY LOW; SET @BATCHSIZE = 4500; SET @ITERATION = 0; SET @TOTALROWS = 0; BEGIN TRY BEGIN TRANSACTION; WHILE @BATCHSIZE > 0 BEGIN DELETE TOP (@BATCHSIZE) FROM MySourceTable OUTPUT DELETED.* INTO MyBackupTable …

2
MySQL:delete…where..in()対delete..from..join、およびサブセレクトを使用した削除時にロックされたテーブル
免責事項:データベースの内部に関する知識が不足していることをお許しください。ここに行く: データベースの定期的なクリーンアップジョブで大きなパフォーマンスの問題があるアプリケーション(私たちが作成したものではありません)を実行します。クエリは次のようになります。 delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in ( select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1"); わかりやすく、読みやすく、標準SQL。しかし、残念ながら非常に遅いです。クエリを説明すると、既存のインデックスVARIABLE_SUBSTITUTION.BUILDRESULTSUMMARY_IDが使用されていないことがわかります。 mysql> explain delete from VARIABLE_SUBSTITUTION where BUILDRESULTSUMMARY_ID in ( -> select BUILDRESULTSUMMARY_ID from BUILDRESULTSUMMARY -> where BUILDRESULTSUMMARY.BUILD_KEY = "BAM-1"); | id | select_type | table | type | possible_keys | key | …

4
InnoDB DELETEのパフォーマンスを向上させる方法は?
だから私はこの監査テーブルを持っています(私のデータベース内の任意のテーブルでのアクションを追跡します): CREATE TABLE `track_table` ( `id` int(16) unsigned NOT NULL, `userID` smallint(16) unsigned NOT NULL, `tableName` varchar(255) NOT NULL DEFAULT '', `tupleID` int(16) unsigned NOT NULL, `date_insert` datetime NOT NULL, `action` char(12) NOT NULL DEFAULT '', `className` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `userID` (`userID`), KEY `tableID` (`tableName`,`tupleID`,`date_insert`), KEY …

3
MySQLの大きなテーブルの一括削除
通知テーブルには、Amazon IODSに1000 IOPSのホストである約1億行が含まれており、1か月より古い行を削除したいと思います。 実行するとDELETE FROM NOTIFICATION WHERE CreatedAt < DATE_SUB(CURDATE(), INTERVAL 30 day);、すべてのIOPSが取得され、プロセスに数時間かかり、「ロック待機タイムアウトが超過しました。トランザクションを再起動してください」という理由で、多くの新しいエントリを挿入できません。 ここで説明する方法を実行しようとしました:http : //mysql.rjweb.org/doc.php/deletebig ただし、増分IDの代わりにUUIDを使用しています。 挿入/更新される新しいデータに影響を与えずにそれらの行を削除するための正しい効率的な方法は何ですか?

2
正しい方法でOracleインスタンスを削除する
AIX 6.0 OSで作成されたoracleインスタンス(oracle 10.2.0.4.0)を削除したい。ターミナルですべてのdbfファイルとctlファイルを削除できることはわかっていますが、これは最善の方法ではないと思います。私はそれを行うためのよりクリーンな方法である必要があると思います。 前もって感謝します。

3
すべての重複を削除する
すべての重複を削除しようとしていますが、単一のレコードのみ(短いID)を保持しています。次のクエリは重複を削除しますが、すべてのコピーを削除して元のコピーを維持するには、多くの繰り返しを必要とします。 DELETE FROM emailTable WHERE id IN ( SELECT * FROM ( SELECT id FROM emailTable GROUP BY email HAVING ( COUNT(email) > 1 ) ) AS q ) そのMySQL。 Edit#1 DDL CREATE TABLE `emailTable` ( `id` mediumint(9) NOT NULL auto_increment, `email` varchar(200) NOT NULL default '', PRIMARY KEY (`id`) …
8 mysql  query  delete 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.