mysqlテーブルと削除戦略

Question

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

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

ROWSTATUSを変更された時刻を含む日付フィールド - - レコードが

UPDATEDを作成された時刻を含む日付フィールド

• CREATEDを - レコードがActive、Inactive、またはDeleted（値 'A'、I、およびDをそれぞれ使用する）であるかどうかを示す単一文字フラグを含むCHAR（1）フィールド。

PHPラッパークラスを使用して、すべてのSELECTクエリにROWSTATUSが含まれていることを確認し、UPDATEクエリもUPDATED列を更新し、INSERTクエリはCREATED列を更新します。

実際にレコードを削除しないで、そのレコードのROWSTATUSフィールドをDに更新することを選択して、削除されたことを示します（つまり、ソフト削除）。

10日後に削除されたデータを物理的に削除するSQLプロシージャがあります。

しかし、私はthis articleに行きました。これは、ロックオーバーヘッドのために物理的に削除する必要はないと主張しています。むしろ、作者はこの方式を使うことを提案：

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を使用している場合、UPDATEによってクエリが実行されている間にテーブル全体がロックされるという問題があります。一度に1つのレコードしか更新または削除できないため、ボトルネックが発生します。

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

Answer 2

私がここに見る唯一の問題は、その記事と比較して、DELETE呼び出しのロックのみを処理していることです。

UPDATEおよびDELETEステートメントは、常にMyISAMテーブルに排他ロックを発行する必要があることを知っておくべきです。

この記事では、UPDATE rowstatusの代わりにINSERTを使用することを推奨しています。あなたは記事が言うように行ってください。削除されたIDを格納するための専用テーブルを作成し、削除されていないレコードを取得するための選択に対して推奨された結合を使用します。このようにエンドユーザーの削除操作では、テーブルに挿入するだけで、テーブルに対してUPDATEロックは発生しません。両方のテーブルに適切なキーを追加すると、インデックスでのみ結合が行われます.SELECTでは高速になります。

アップデートの時間を保存する場合は、オーバーヘッドも導入されます。あなたはそのアイデアを使わなくて済むようにしなければなりません。あなたはレコードがいつ更新されたかを伝えるのに使いません。