Mysql：インデックス付きカウントクエリとサマリーテーブルの保守

Question

私は利用可能な製品に関心を示すことができる電子商取引のWebサイトに取り組んでおり、私たちはmysqlテーブルの先頭にそれを保存します。このLeadsテーブルは、数百万のレコードで構成され、1秒あたり8レコード増加します。次のようにテーブルの構造は以下の通りである：

LeadId | ProductId | UserId | RequestDate(DateTime) 

テーブルスキーマ：

`id` int(11) NOT NULL AUTO_INCREMENT, 
`ProductId` int(11) DEFAULT NULL, 
`UserID` int(11) NOT NULL, 
`RequestDateTime` datetime(3) NOT NULL, 
PRIMARY KEY (`id`), 
KEY `ix_leads_requestdatetime` (`RequestDateTime`) USING BTREE, 
KEY `ix_leads_productid` (`ProductId`) USING BTREE, 
KEY `ix_leads_userid` (`UserID`) USING BTREE 

次に、要求が一人のユーザが一日に最大10点のリードを与えるようにすることです。 Leads表にその日のレコードの数をカウントし、< 20場合は、挿入する前にチェックするために

1. 選択クエリ：私はこれを実装するためのアプローチを以下しています。

2. の特定の日付のリード数を含むDailyLeadCountテーブルを維持します。テーブルの構造：

   UserId | Date | Count 
   

   テーブルスキーマ：私はLeadsテーブルに挿入する前に、この表の数をチェックし、それに応じて挿入した後、この数を更新します

   `RequestDate` date NOT NULL, 
   `UserId` int(11) NOT NULL, 
   `LeadCount` smallint(6) NOT NULL, 
   PRIMARY KEY (`RequestDate`,`UserId`) 
   

   。また、この表では1日のデータだけが有用なので、毎日アーカイブするジョブを作成します。

どのアプローチが良いですか？ Leadsテーブルで選択クエリを実行すると、挿入/更新より重くなり、DailyLeadCountテーブルのクエリを選択するよりも重いのですか？

毎日テーブルを管理し、アーカイブする価値はありますか？

これを処理する他の方法はありますか？

INDEX(UserID, RequestDateTime) 

へ

Answer 1

変更

KEY `ix_leads_userid` (`UserID`) USING BTREE 

その後、クエリをリアルタイムに行うのに十分に高速になりますとき

(SELECT COUNT(*) FROM Leads WHERE UserID = 1234 
     AND RequestDateTime > NOW() - INTERVAL 24 HOUR 
) >= 10 

ユーザーに唾を吐きます。

昨日と今の間にカウントされます。これはあなたが望むものと正確に異なる場合があります。 「真夜中昨日から」場合

 AND RequestDateTime > CURDATE() 

：

 AND RequestDateTime > CURDATE() - INTERVAL 1 DAY 

あなたは深夜のため彼タイムゾーンを使用したい場合は、それを取得、代わりに、あなたは時計が真夜中に今朝を開始する場合面倒だ。

潜在的な問題：何とかリードをバッチ処理できる場合、同じミリ秒で複数のリードを挿入できます。 （私が気づいているのはDATETIME(3)です）

「昨日」をチェックする必要がある場合は、サマリーテーブルの考え方が適していますが、「最後の86400000ミリ秒」ではあまり適していません。