I have a sql query on table with mobileno column mobileno contains "-" so in where clause i need to use replace(mobileno,"-","") function for comparision.
With explain function i checked that it doesn't use index if function is used on indexed column. So how can i force sql to used index or any other alternative to increase my query performance.
Are you sure the index is not used because of the REPLACE function? Maybe there's not enough rows to make using an index worthwhile. Or some other reason.
I ran a test with 4256 rows and to my surprise, an index was used, even with REPLACE:
EXPLAIN EXTENDED SELECT mobileno FROM test WHERE REPLACE(mobileno, '(', '') = '123) 456-789'
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE test index NULL mobileno 768 NULL 4256 100 "Using where; Using index"
Related
As mention in the title, I would like to know any solution for this by not using store prodecure, temporarily table etc.
Compare Query#1 and Query#3, Query#3 get worst performance result. Does it have any workaround to put in variable but without impact the performance result.
Schema (MySQL v5.7)
create table `order`(
id BIGINT(20) not null auto_increment,
transaction_no varchar(20) not null,
primary key (`id`),
unique key uk_transaction_no (`transaction_no`)
);
insert into `order` (`id`,`transaction_no`)
value (1,'10001'),(2,'10002'),(3,'10003'),(4,'10004');
Query #1
explain select * from `order` where transaction_no in ('10001','10004');
id
select_type
table
partitions
type
possible_keys
key
key_len
ref
rows
filtered
Extra
1
SIMPLE
order
range
uk_transaction_no
uk_transaction_no
22
2
100
Using where; Using index
Query #2
set #transactionNos = "10001,10004";
There are no results to be displayed.
Query #3
explain select * from `order` where find_in_set(transaction_no, #transactionNos);
id
select_type
table
partitions
type
possible_keys
key
key_len
ref
rows
filtered
Extra
1
SIMPLE
order
index
uk_transaction_no
22
4
100
Using where; Using index
Short Answer: See Sargeability
Long Answer:
MySQL makes no attempt to optimize an expression when an indexed column when it is hidden inside a function call such as FIND_IN_SET(), DATE(), etc. Your Query 3 will always be performed as a full table scan or a full index scan.
So the only way to optimize what you are doing is to construct
IN ('10001','10004')
That is often difficult to achieve when "binding" a list of values. IN(?) will not work in most APIs to MySQL.
In the extra field of the explain in mysql you can get:
Using index
Using where; Using index
What's the difference between the two?
To explain my question better I'm going to use the following table:
CREATE TABLE `test` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`another_field` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8;
INSERT INTO test() VALUES(),(),(),(),();
Which ends up with the content like:
SELECT * FROM `test`;
id another_field
1 0
2 0
3 0
4 0
5 0
On my research I found
Why is this query using where instead of index?
The output of EXPLAIN can sometimes be misleading.
For instance, filesort has nothing to do with files, using where
does not mean you are using a WHERE clause, and using index can
show up on the tables without a single index defined.
Using where just means there is some restricting clause on the table
(WHERE or ON), and not all record will be returned. Note that
LIMIT does not count as a restricting clause (though it can be).
Using index means that all information is returned from the index,
without seeking the records in the table. This is only possible if all
fields required by the query are covered by the index.
Since you are selecting *, this is impossible. Fields other than
category_id, board_id, display and order are not covered by
the index and should be looked up.
and I also found
https://dev.mysql.com/doc/refman/5.1/en/explain-output.html#explain-extra-information
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.
If the Extra column also says Using where, it means the index is being
used to perform lookups of key values. Without Using where, the
optimizer may be reading the index to avoid reading data rows but not
using it for lookups. For example, if the index is a covering index
for the query, the optimizer may scan it without using it for lookups.
For InnoDB tables that have a user-defined clustered index, that index
can be used even when Using index is absent from the Extra column.
This is the case if type is index and key is PRIMARY.
(Look at the second paragraph)
My problem with this:
First: I didn't understand the second paragraph the way it's written.
Second:
The following query returns
EXPLAIN SELECT id FROM test WHERE id = 5;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE test const PRIMARY PRIMARY 8 const 1 Using index
(Scroll to the right)
And this other query returns:
EXPLAIN SELECT id FROM test WHERE id > 5;
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE test range PRIMARY PRIMARY 8 NULL 1 Using where; Using index
(Scroll to the right)
Other than the fact that one query uses a range search and another uses the constant search, both queries are using some restricting clause on the table (WHERE or ON), and not all record will be returned.
What does the Using where; mean on the second query mean? and what does the fact that it's not on the first query mean?
EXTRA
What is the difference with Using index condition; Using where?
(I'm not adding an example of this because I have not been able to reproduce it in a small self contained piece os code)
When you see Using Index in the Extra part of an explain it means that the (covering) index is adequate for the query.
In your example: SELECT id FROM test WHERE id = 5; the server doesn't need to access the actual table as it can satisfy the query (you only access id) only using the index (as the explain says). In case you are not aware the PK is implemented via a unique index.
When you see Using Index; Using where it means that first the index is used to retrieve the records (an actual access to the table is not needed) and then on top of this result set the filtering of the where clause is done.
In this example: SELECT id FROM test WHERE id > 5; you still fetch for id from the index and then apply the greater than condition to filter out the records non matching the condition
I'm getting pretty slow performance for a pretty simple statement (3-4 seconds):
SELECT col1,col2,col3 FROM table WHERE fname LIKE '%D%' OR fname LIKE '%S%' ORDER BY DATE(bday) DESC LIMIT 0,100
I have index on fname, another on bday and even a joint index on fname & bday. Here's my explain:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE table ALL NULL NULL NULL NULL 95856 Using where; Using filesort
No index will help you here.
When you're using LIKE '%something% it's going to have to look at every row and do the string matching.
As stated no index will help. Personally I'd consider full text search overkill for this and add an other column to the table, fill it in on insert update and index that.
Like is for one offs.
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