I think the biggest problem here is the representation of created_time
.
Looks like that is not a MySQL DATETIME
or TIMESTAMP
column, but is a character datatype.
And the date portion is not represented in a canonical year-month-day format, such that a string comparison is equivalent to a date range comparison.
Doing a comparison of 'dd-mm-yyyy' >= '20-03-2018', we're going to get the 21st, 22nd, ... 28th, 29th, 30th of every month, of every year.
e.g. for a string comparison,
'22-01-2018' > '20-03-2018'
even though January 1 is not after March 20. In comparing the strings, we're comparing character by character, not looking at a "date" comparison.
Without changing the data structure... if the created_time
column is stored as a character string in 'dd-mm-yyyy hh:mi'
format, then in the query, we can convert the strings to DATETIME
datatypes using the STR_TO_DATE
function...
Or, maybe I'm barking up the wrong tree.
References:
https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_str-to-date
https://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_date-format
As a demonstration:
SELECT STR_TO_DATE('20-03-2018 20:13','%d-%m-%Y %H:%i')
As an example of how to retrieve 5pm Tuesday up to 5pm Friday:
SELECT ...
FROM fb
WHERE STR_TO_DATE( fb.created_time ,'%d-%m-%Y %H:%i') >= '2018-03-20 17:00'
AND STR_TO_DATE( fb.created_time ,'%d-%m-%Y %H:%i') < '2018-03-23 17:00'
performance note: this query pattern is forcing MySQL to evaluate the STR_TO_DATE
function on every row in fb
(a full scan). If created_time
were a DATETIME
datatype, we could avoid the wrapper function, and we could have a query that allows MySQL to use a range scan operation on an index with created_time
as a leading column.