MySQL Index not working ( Use Case specific scenario) - mysql

Question

So far following is my scenario :
Parameters controlled by user: (These parameters are controlled by a dashboard but for testing purposes I have created sql parameters in order to change their values)
SET #device_param := "all devices";
SET #date_param_start_bar_chart := '2016-09-01';
SET #date_param_end_bar_chart := '2016-09-19';
SET #country_param := "US";
SET #channel_param := "all channels";
Query that runs at the back-end
SELECT
country_code,
channel_report_tag,
SUM(count_more_then_30_min_play) AS '>30 minutes',
SUM(count_15_30_min_play) AS '15-30 Minutes',
SUM(count_0_15_min_play) AS '0-15 Minutes'
FROM
channel_play_times_cleaned
WHERE IFNULL(country_code, '') =
CASE
WHEN #country_param = "all countries"
THEN IFNULL(country_code, '')
ELSE #country_param
END
AND IFNULL(channel_report_tag, '') =
CASE
WHEN #channel_param = "all channels"
THEN IFNULL(channel_report_tag, '')
ELSE #channel_param
END
AND iFnull(device_report_tag, '') =
CASE
WHEN #device_param = "all devices"
THEN iFnull(device_report_tag, '')
ELSE #device_param
END
AND playing_date BETWEEN #date_param_start_bar_chart
AND #date_param_end_bar_chart
GROUP BY channel_report_tag
ORDER BY SUM(count_more_then_30_min_play) DESC
limit 10 ;
The index that I have applied is
CREATE INDEX my_index
ON channel_play_times_cleaned (
country_code,
channel_report_tag,
device_report_tag,
playing_date,
channel_report_tag
)
I have followed this link : My SQL Index Cook-Book Guide to create my index.
However the EXPLAIN keyword while executing the above query tells me that there is no index used.
I want to what am I doing wrong over here ?

Answer 1

You use functions and case expression in the first 3 where condition. Simple field index cannot be used to speed up such look ups.
MySQL could potentially use an index for the playing_date criteria, but that field is not the leftmost in the cited index, therefore the cited index is not suitable for that either.
If I were you, I would remove the logic from the where criteria and moved that into the application layer by constructing such an sql statement that has the case conditions resolved and emits only the necessary sql.

Answer 2

Your CASE expressions in the WHERE clause are forcing full table scans. Clearly, they have to go... but how?
You have to think like the optimizer and remember that its job is to avoid as much work as possible.
Consider this query:
SELECT * FROM users
WHERE first_name LIKE '%a%';
Every row must be read to find all first_name values containing the letter 'a'. Very slow.
Now, this one:
SELECT * FROM users
WHERE first_name LIKE '%a%'
AND 2 < 1;
For each row, you're asking the server to check the first_name again and to include only rows where 2 is a smaller number than 1.
Is it slow, or fast?
It's very fast, because the optimizer detects an Impossible WHERE. There is no point in scanning the rows because 2 < 1 is always false.
Now, use this logic to tell the optimizer what you really want:
Not this:
WHERE IFNULL(country_code, '') =
CASE
WHEN #country_param = "all countries"
THEN IFNULL(country_code, '')
ELSE #country_param
END
AND
But this:
WHERE
(
(
#country_param = "all countries"
)
OR
(
#country_param != "all countries"
AND
country_code = #country_param
)
)
AND ...
The difference should be stark. If #country_param = "all countries" the second test is not needed, and otherwise, only the rows with the matching country are needed and this portion of the WHERE clause is false by definition for all other rows, allowing an index on country_param to be used.
One or the other of these OR'ed expressions is always false, and that one will be optimized away, early -- never evaluated for each row. The expression #country_param != "all countries" should be treated no differently than the expression 2 < 1 or 2 > 1. It is not going to change its truthiness based on the data in the rows, so it only needs to be evaluated once, at the beginning.
Repeat for the other CASE. You should almost never pass columns as arguments to functions in the WHERE clause because the optimizer can't "look backwards through" functions and form an intelligent query plan.

Answer 3

The other answers have explained why your query is slow. I will explain what you should do.
Write code to "construct" the query. It would either leave out the test for country_code if the user said "all countries", or it add in AND country_code = "US". No #variables, no CASE, etc.
Then, one 5-column index won't work except for a few cases. Instead, get a feel for what users are asking for, then build a few 2-column indexes to cover the popular cases.