Consider the following two EXPLAINs:
EXPLAIN SELECT * FROM sales WHERE title != 'The'
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE sales ALL title NULL NULL NULL 41707 Using where
And -
EXPLAIN SELECT * FROM sales WHERE title = 'The'
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE sales ref title title 767 const 1 Using where
Why does the != query have a NULL key? Why doesn't it use title? What causes a = statement to be able to utilize an index but not a !=?
There is no point on using the index unless title is exactly 'The' very frequently.
Since almost every row needs to be selected you don't gain anything from using an index. It can actually be costly to use an index, which is probably what your MySQL engine is determining, so it is opting not to use the index.
Compare the amount of work done in these two situations:
Using the index:
1) Read the entire index tree into memory.
2) Search the index tree for the value 'The' and filter out those entries.
3) Read every row except for the few exceptions (which probably are in the same blocks on the disk as rows that do need to be read, so really the whole table is likely to be read in) from the table into memory.
Without the index:
1) Read every row into memory and while reading them filter out any where title = 'The' from the result set
Related
I have the following query:
SELECT *
FROM table
WHERE
structural_type=1
AND parent_id='167F2-F'
AND points_to_id=''
# AND match(search) against ('donotmatch124213123123')
The search takes about 10ms to run, running on the composite index (structural_type, parent_id, points_to_id). However, when I add in the fts index, the query balloons to taking ~1s, regardless of what is contained in the match criteria. Basically it seems like it 'skips the index' whenever I have a fts search applied.
What would be the best way to optimize this query?
Update: a few explains:
EXPLAIN SELECT... # without fts
id select_type table partitions type possible_keys key key_len ref rows filtered Extra
1 SIMPLE table NULL ref structural_type structural_type 209 const,const,const 2 100.00 NULL
With fts (also adding 'force index'):
explain SELECT ... force INDEX (structural_type) AND match...
id select_type table partitions type possible_keys key key_len ref rows filtered Extra
1 SIMPLE table NULL fulltext structural_type,search search 0 const 1 5.00 Using where; Ft_hints: sorted
The only thing I can think of which would be incredibly hack-ish, would be to add an additional term to the fts so it does the filter 'within' that. For example:
fts_term = fts_term += " StructuralType1ParentID167F2FPointsToID"
The MySQL optimizer can only use one index for your WHERE clause, so it has to choose between the composite one and the FULLTEXT one.
Since it can't run both queries to bench which one is faster, it will estimate how fast will different execution plans be.
To do so, MySQL uses some internal stats it keeps about each table. But those stats can be very different from the reality if they aren't updated and the data changes in the table.
Running a OPTIMIZE TABLE table query allows MySQL to refresh its table stats, so it will be able to perform better estimates and choose the better index.
Try expressing this without the full text logic, using like:
SELECT *
FROM table
WHERE structural_type = 1 AND
parent_id ='167F2-F' AND
points_to_id = '' AND
search not like '%donotmatch124213123123%';
The index should still be used for the first three columns. LIKE might be slow, but if not many rows match the first three, this might not be as bad as using the full text index.
I have the following MySQL query
explain select item_id from items use index(user_item_id) where user_id=9 and item_id=10000
the following is returned
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE items ref user_item_id user_item_id 8 const,const 1 Using index
How come the type is ref and not const?
user_item_id is a composite index of user_id and item_id.
High Performance MySql describes a ref type lookup as "This is an index access that returns rows that match a single value"
When the word const is added it is described as "optimize away parts of the query and turn it into a constant"
So it seems MySQL needs to be able to find the row from the index in the first place
The consts in the ref column mean that mysql could use previous values for looking up things in the index.
I have a relatively large table (5,208,387 rows, 400mb data/670mb index),
all columns i use to search with are indexes.
name and type are VARCHAR(255) BTREE INDEX
and sdate is an INTEGER column containing timestamps.
I fail to understand some issues,
first this query is very slow (5sec):
SELECT *
FROM `mytable`
WHERE `name` LIKE 'hello%my%big%text%thing%'
AND `type` LIKE '%'
ORDER BY `sdate` DESC LIMIT 3
EXPLAIN for the above:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE mytable range name name 257 NULL 5191 Using where
while this one is very fast (5msec):
SELECT *
FROM `mytable`
WHERE `name` LIKE 'hello.my%big%text%thing%'
AND `type` LIKE '%'
ORDER BY `sdate` DESC LIMIT 3
EXPLAIN for the above:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE mytable range name name 257 NULL 204 Using where
the amount of rows scanned different makes sense because of the indexes,
but having 5k of indexed rows take 5 seconds seems way too much.
also, ordering by name instead of sdate makes the queries very fast, but I need to order by the timestamp.
Second thing I do not understand is that before
adding the last column to the index,
the db had index of 1.4GB,
not after running an OPTIMIZE/REPAIR the size is just 670MB.
The problem is, only the portion before the first % can take advantage of the index, the rest of the like strings needs to process all rows which match hello% or hello.my% without the help of one. Also, ordering by another column then the index used, probably requires a second pass, or at least a scan rather then an already sorted index. Options to better performance (can be implemented independently from each other) are:
Using a full-text index on the name column and using a MATCH() AGAINST() search rather then LIKE with %'s.
Adding the sdate to in index combined (name,sdate) could very well speed up sorting.
EXPLAIN EXTENDED SELECT `member`.`id` , `member`.`name`
FROM `member`
WHERE `member`.`last_active` > '1289348406'
Shows the following output despite last_active having an index on it.... shouldn't it say index instead of where ?
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE member range last_active last_active 4 NULL 2 100.00 Using where
Using index means the query does not touch the table at all:
Using index
The column information is retrieved from the table using only information in the index tree without having to do an additional seek to read the actual row. This strategy can be used when the query uses only columns that are part of a single index.
Since not all fields are covered by your index, it's impossible.
The index itself is of course being used (since the access type is range), but it still needs to do the row lookup in the table to retrieve the values of name and id.
Create a covering index on (last_active, name, id) if you want to see Using index.
I'm quite new to setting indexes myself. I'm currently just experimenting with it to discover how it works and in what cases a database will make use of the index.
I've got a simple table with 3 columns; an id, a name and a status. I've set an index on the name which is a CHAR(30) column. Against my expectations, MySQL ignores this index in the following query:
SELECT * FROM people WHERE name = 'Peter'
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE people ref name name 90 const 1 Using where
However, when using the following query, the index is used:
SELECT COUNT(*) FROM people WHERE name = 'Peter'
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE people ref name name 90 const 1 Using where; Using index
Could anyone please explain this to me?
"Using index" means it's using the index as a "covering index". This happens when it only needs to access the index to satisfy the query.
If, on the other hand, "Using index" is absent, but in the "key" column, the index is named, then it's using that index in the way described in the "ref" column.
So in both cases it's using the index, but only the COUNT() uses it as a covering index.
For each query, the "key" columns indicates "name" -- so, I'd say your two queries both used the index called "name", which probably is on the "name" column -- and this is what you want (quoting the manual) :
The key column indicates the key
(index) that MySQL actually decided to
use. If MySQL decides to use one of
the possible_keys indexes to look up
rows, that index is listed as the key
value.
Also, you are only going through "1" row, which is good (no full-scan or anything like that).
The "type" says "ref", which seems to be a good thing :
All rows with matching index values
are read from this table for each
combination of rows from the previous
tables. ... If the key that is used
matches only a few rows, this is a
good join type.
ref can be used for indexed columns
that are compared using the = or <=>
operator.
And the "ref" column indicates "const" -- not sure what it means exactly, but as far as I know, it's a good thing.
What makes you think your index is not used for one column ?
Just as a reference, for more informations : 7.2.1. Optimizing Queries with EXPLAIN