Mysql: indexed count query vs maintaining summary table - mysql

Question

I am working on an e-commerce website where user can show interest on available products and we store it as a lead in mysql table. This Leads table consists of millions of records and grows by 8 records per seconds. Table structure is as follows:
LeadId | ProductId | UserId | RequestDate(DateTime)
Table Schema:
`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
Now, the requirement is to allow one user to give maximum 10 leads in a day. I have following approaches to implement this:
Select query to count number of records for that day in Leads table and check if < 20 before insertion.
Maintain a DailyLeadCount table which contains count of leads for each userId for particular date. Table Structure:
UserId | Date | Count
Table Schema:
`RequestDate` date NOT NULL,
`UserId` int(11) NOT NULL,
`LeadCount` smallint(6) NOT NULL,
PRIMARY KEY (`RequestDate`,`UserId`)
I will check count in this table before inserting in Leads table and update this count after insertion accordingly. Also, as only one day data will be useful in this table, I will create a job to archive it daily.
Which approach is better? Is running select query on Leads table to get count more heavy than insert/update and select query on DailyLeadCount table?
Is it worth maintaining and archiving a table daily for it?
Is there any other way to handle this?

Answer 1

Change
KEY `ix_leads_userid` (`UserID`) USING BTREE
to
INDEX(UserID, RequestDateTime)
Then spit at the user when
( SELECT COUNT(*) FROM Leads WHERE UserID = 1234
AND RequestDateTime > NOW() - INTERVAL 24 HOUR
) >= 10
The query will be fast enough to do in real time.
The count is between this time yesterday and now -- this may not be exactly what you want. If, instead, you want the clock to start at midnight this morning:
AND RequestDateTime > CURDATE()
If "since midnight yesterday":
AND RequestDateTime > CURDATE() - INTERVAL 1 DAY
If you want to use his timezone for midnight, it gets messier.
Potential issue: If he can somehow batch his leads, he could insert multiple leads in the same millisecond. (I am noticing DATETIME(3).)
Your idea of a Summary Table works best if you need to check against "yesterday", not so well for "the last 86400000 milliseconds".