Question

I have a query which is returning the below explain:

id  select_type  table  type         possible_keys                                                                                        key                                                      key_len  ref  rows  Extra                                                                                  
1   SIMPLE       this_  index_merge  CategoryId,Deleted,PublishedOn,_ComputedDeletedValue,_Temporary_Flag,Published,_TestItemSessionGuid  Deleted,_ComputedDeletedValue,_Temporary_Flag,Published  1,1,1,1       6203  Using intersect(Deleted,_ComputedDeletedValue,_Temporary_Flag,Published); Using where  

Does this show that the query is using indexes everywhere, or can it be improved by adding other indexes? Based on this: http://dev.mysql.com/doc/refman/5.1/en/explain-output.html, it mentions that the key column shows the indexes actually used. I have an index on every column.

The query in question is the below:

SELECT SQL_NO_CACHE count(*) FROM 

article this_ 


WHERE 


(this_._Temporary_Flag = 0 OR this_._Temporary_Flag = NULL) AND 
this_.Published = 1 AND 
(this_.PublishedOn IS NULL OR this_.PublishedOn <= '2012-10-30 18:46:18 ') AND 
(this_.Deleted = 0 OR this_.Deleted = NULL) AND 
(this_._ComputedDeletedValue = 0 OR this_._ComputedDeletedValue = NULL) AND
((this_._TestItemSessionGuid IS NULL OR this_._TestItemSessionGuid = ''))

 AND NOT (this_.CategoryId IS NULL) 

Table has approximately 140,000 records. This query is taking 3 seconds to execute, and returning 135,725 as result.

Answer 1

The explain shows that MySQL is using an index merged from 4 separate indexes with key length 1,1,1,1 which means all of the four columns are used for traversing the search tree.

However having separate index on all the columns are usually not the most efficient way. Especially in your case merging four index can take a lot of time. The actual execution might be faster but building the index may take 1-2 seconds.

I would suggest to build a composite index on those columns. The order of those matters. Get the ones with equal conditions and put them in order of cardinality (greater cardinality goes first). The last column will be the range query (in your case the PublishedOn).

For example:

create index my_query_IDX on article (Deleted, _Temporary_Flag, _ComputedDeletedValue, PublishedOn)

Another thing I would suggest is to change the _Temporary_Flag, Deleted, _ComputedDeletedValue, _ Published etc columns to be NOT NULL DEFAULT ‘0’. Indexes on nullable columns and null values are less effective than not null columns and as I saw according to the key_length these columns are BOOLEANS or TINYINT (which are the same by the way).