0

次のようなテーブルがあります。

  `id` int(11) NOT NULL AUTO_INCREMENT,
  `torderid` int(11) DEFAULT NULL,
  `tuid` int(11) DEFAULT NULL,
  `tcontid` int(11) DEFAULT NULL,
  `tstatus` varchar(10) DEFAULT 'pending',

ここでのルールは、同じユーザー UID が同じ contid を持つ保留中の注文を複数持つことはできないということです。

最初にできることは、次のような保留中の注文があるかどうかを確認することです。

select count(id) into @cnt from tblorders where tuid = 1 and tcontid=5 and tstatus like 'pending';

> 0 の場合は挿入できません。

または、3 つの列に一意のインデックスを作成するだけで、テーブルが重複の新しいレコードを受け入れなくなります。

問題は次のとおりです。どの方法が速いですか? それは大規模なデータベースになるからです...

4

3 に答える 3

1

いくつかの提案。

tstatus = 'pending';の代わりに使用tstatus like 'pending';

「保留中」ステータスのみを検討している場合、複合主キーの作成tid, tcontid, tstatusが機能しない場合があります。他のステータスはどうですか？

列にインデックスを付ける場合は、別のテーブルを作成して、tstatusここで外部キー参照を使用することをお勧めします。したがって、インデックス付きの列のスペースが節約され、クエリは常にインデックス付きのフィールドで実行されます。

于 2013-02-25T19:41:22.183 に答える
1

インデックスはそのユースケース向けに設計されているため、明らかに高速です。探しているタプルの検索が速くなり、制約が満たされない場合はエラーが送信されるため、処理スクリプトでは、結果をフェッチするよりも簡単に (そして速く) 処理できます。

于 2013-02-25T19:23:04.333 に答える
1

ユーザーが競合するレコードを有効なレコードよりも少ない頻度で追加しようとすると、複合インデックスの方が高速になります。SQL エンジンはインデックスを維持し、インデックスの制約違反があるとエラーをスローします。

select メソッドを選択した場合でも、インデックスを維持する必要があります。それとは別に、select から結果セットをアプリケーションのメモリ空間にずっと引き戻して結果をチェックするのは、インデックスの制約を適用するよりもはるかに時間がかかります。

詳細については、https ://dev.mysql.com/doc/refman/5.5/en/multiple-column-indexes.html を参照してください。

于 2013-02-25T19:26:04.953 に答える