2012-01-12 3 views
0

私は、これらのフィールドになぜmysqlでNOT IN構文を使用するとDBサーバーがクラッシュするのですか?

テーブル名を持つ2つのMySQLテーブル1持っている - residential:主ListingID上のキーとListingStatus上のインデックスを持つ

ListingID varchar(12), 
ListingStatus varchar(15) 

を。

別のテーブル - mlscheck

mls varchar(12), 
status varchar(15) 

状態にMLSとインデスの同じプライマリキーを持ちます。でも

delete from residential 
where ListingStatus = "Active" and 
ListingID NOT IN(select mls from mlscheck where status = "Active") 

delete from residential 
where ListingStatus = "Active" 
    and LIstingID NOT IN(select mls from mlscheck) 

もない作品を、両方の私のデータベースをクラッシュし、私は再起動する必要が

は、私のような何かをしようとします。

ジョイン、ユニオンなどを使用する方法を学習する必要がありますか?私はまともなコマンドではないと思った。あなたの専門家の中からいくつかの情報を得ることはできますか?パフォーマンスで

+0

テーブルにはいくつのレコードがありますか? –

+0

一重引用符を使用しようとしましたか(「アクティブ」など)?また、原則として、列が95%ユニークでない限り、列を索引付けしないでください。オプティマイザはインデックスを無視し、不必要なオーバーヘッドが発生します。 –

+0

1.重くても重くてもクラッシュしてはいけません。これはDBです。 2.多分あなたは他のメモリ/ディスクスペースの問題を持っているかもしれません。それをチェックしてください。3. BASIC BASICのmysqlログをチェックしましたか? –

答えて

0

、このクエリはサーバの重量があり、常に優れているか、サブクエリ

よりも等しく、ウィッヒはmls上のすべての行を選択する必要があり参加して、行ごとに、このresidential

で、なぜデータベースことクラッシュ。使用して

は加入:

DELETE r FROM residential r 
LEFT JOIN mlscheck 
    ON mls = ListingID 
WHERE ListingStatus = "Active" 
    AND mls IS NULL 

のみresidential行が削除されます。 (r)に対応する行が見つからない場合には、

+0

ダング!あなたはすごく速いですよ、私はできます; 't – retsman

+0

残念ながら、居住用テーブル170,000行、行長3,209、行数3268の350フィールドについては、mlscheckテーブルには2フィールド、合計行、43,000程度しかありません。と私は95%ユニークではないもののインデックスを取って – retsman

0

NOT IN演算子は、大きなレコードを持つテーブルでは高価です。あなたのテーブル名で判断すると、大きなデータセットであるMLSリストで何かをしようとしています。

何ができることは、チャンクにより削除チャンクを行うスクリプトを記述することです。

は、( "= mlscheckどこ状況からMLSを選択する場所ListingStatus =「アクティブ」とListingID NOT IN住宅から削除アクティブアクティブ "とListingID どこListingStatus = "アクティブ" とListingID NOT IN(ステータス= mlscheckからMLSを選択し、 "アクティブ" LIMIT 101、200)」LIMIT 0、100)

は、住宅からどこListingStatusは=削除します"

は、住宅からどこListingStatusは= "アクティブ" とListingID どこListingStatus = "アクティブ" とListingID NOT IN(ステータス= "アクティブ" LIMIT 201、300 mlscheckからMLSを選択)

など削除します...

これは、BAKに記載されているJOINの方法を使用したくない場合です。

+0

ええ、住宅のテーブルにわずか114,000レコードがありますが、350フィールドのようなものがあります。ユニークでない場合にインデックスが見落とされることはわかりませんでした。ありがとうございました。大きな男の子にステップアップするかもしれない – retsman

+0

ちょっとちょっと、私はちょっと気分が悪いと感じました。新しく作成されたテーブルmlscheckが、スウェーデンのラテンのsomethiingやその他のキャラクターセットで作成されたことに気付きました。すべてがうまくいく。私はオーバーヘッドについて学びました。次回のために保存する参加に感謝します。みんなありがとう – retsman

関連する問題