MySQLテーブルと戦略の削除

Question

Facebookのサブセットのように、ソーシャルネットワークに取り組んでいます。これは、アプリケーションが書き込みが多いよりも読み上げられることを意味すると思います（つまり、挿入、更新、または削除よりも選択）

Myisamを使用して、データベースにMySQLを使用する予定です。データベース内の各テーブルには、次の3つのフィールドが含まれます。

• CREATED - レコードが作成された時間を含む日付フィールド
• UPDATED - レコードが変更された時間を含む日付フィールド
• ROWSTATUS - レコードがアクティブ、非アクティブ、または削除されているかどうかを表示するための単一の文字フラグを含むChar（1）フィールド（値 'a'を使用して、 I, 、 と D, 、 それぞれ）。

PHPラッパークラスを通じて、すべての選択クエリにRowStatusが含まれるようにし、更新された列を更新し、作成した列を挿入するクエリも更新します。

私は実際にレコードを削除しないことを計画しています。代わりにそのレコードRowStatusフィールドを更新することを選択します D 削除されていることを表示するには（つまり、ソフト削除）。

10日後に削除されたデータを物理的に削除するSQL手順があります。

しかし、私は経験していました この記事, 、オーバーヘッドをロックするために物理的に削除する必要はないと主張しています。むしろ、著者はこのスキームを使用することを提案しました。

SELECT e.eventid,e.title
    FROM events e
   WHERE NOT EXISTS
    (SELECT * FROM event_deletes ed WHERE ed.eventid = e.eventid);

私のスキームがこの提案されたメカニズムとどのように比較され、どちらが優れているのか疑問に思っていますか？私は自分で決定的な答えに手を伸ばすことができませんでした。

Answer 1

@Pentium10が言っているように、あなたの計画に本質的に間違っていることはありません。実際にはかなり標準的なアプローチです。

問題は、MyISAMを使用している場合、更新により、クエリが実行されている間にテーブル全体がロックされることです。一度に1つのレコードを更新または削除できるため、ボトルネックが導入されます。

MyISAMを使用する理由がない限り、データベースエンジンとしてInnoDBに切り替えることをお勧めします。 INNODBは行レベルのロックを使用するため、更新クエリは他の更新をブロックしません。また、トランザクションのサポートや参照整合性の制約など、他の素晴らしい機能もいくつかあります。

Answer 2

その記事と比較して、ここで私がここで見た唯一の問題は、削除コールのロックのみを処理していることです。

知っている必要があります ステートメントを更新および削除するには、常にmyisamテーブルに独占ロックを発行する必要があります。

そのため、この記事では、更新rowstatusの代わりに挿入物を使用することをお勧めします。記事が言っているように行くべきです。削除されたIDを保存する専用のテーブルを作成し、削除されていないレコードを取得するために[選択]結合を使用します。これにより、エンドユーザーの削除アクションでは、テーブルに挿入するだけで、テーブルに更新ロックが発生することはありません。両方のテーブルに適切なキーを追加すると、結合はインデックスでのみ実行されます。Siは選択で高速になります。

更新時間を保存すると、オーバーヘッドを導入しています。役に立たないように、そのアイデアをドロップする必要があり、レコードがいつ更新されたかを知るために使用しません。