多くの書き込み (1 秒あたり最大 100 回) を必要とするアプリを作成しています。また、この表から頻繁に読み取るつもりです。ただし、これから行う書き込みの大部分は、重複するキー インデックスが原因で実際には失敗します。これは意図されたものです。失敗した書き込みは MySQL テーブル リソースを消費しますか? これは悪い習慣ですか？
質問する
92 次
2 に答える
3
制約に違反しているかどうかを判断するためにテーブル インデックスを参照する必要があるため、失敗した書き込みはシステム リソースを消費します。それが悪い習慣であるかどうかについて言えば、失敗が予想される大量の書き込みを意図的にスローするのは少し珍しいように思えますが、一方で、RDBMS の仕事はデータを保存、整理、および取得することです。INSERT最初にクエリを実行して、アプリケーション コードでキーを挿入できるかどうかを確認してから挿入するよりも、データベースが一意の制約に違反して失敗する を試行する方が高速です(ただし、RDBMS の制約を確認する必要があります)。 ）。
于 2012-04-06T01:31:02.370 に答える
1
通常、アプリケーションには、整合性の問題が概念的に定義されているビジネス ルールの抽象化レイヤーがあります。もしそうなら、あなたの後に来るほとんどの開発者は、そこで検証が行われることを期待するでしょう. OTOH これが 1 回限りのユーティリティである場合、またはあなたが永遠に唯一の開発者になる場合は、機能します。ハックはおそらく、インデックス付きフィールドの読み取りと比較して効率の大幅な改善をもたらさず、一般的にエラートラップと移植に対処するのは不快な場所です-あなたを除いて、それはエラーではありません. (「これはバグではなく、機能です...」のようなものです)
于 2012-04-06T02:26:19.063 に答える