I have a query like
SELECT * FROM Table_name WHERE column1 = '1' AND column2 IN ('1','2','3');
And index exists on (column1, column2, column3). Is my above query used index I have created or not? Basically I am confused with the IN keyword, without this it is using, but with IN I am not sure. Please explain me.
MySQL can use indexes with IN conditions. If you only have an index on column2, it will most likely be used. If you have indexes on each of column1 and column2, only one of them can be used, and the query planner will have to decide which one seems better for a particular query. If you have a composite index on (column1, column2) then it should be able to use that index to match both columns in the WHERE clause.
MySQL is capable of using indices with IN .. now, is MySQL using indices in the particular query? Well, ask the query planner!
In this case an index over (column1, column2, ..) could be used - because all the leftward components have been satisfied. That is, an index seek could be done on column1 (for =), and then column2 (for IN). But again, ask the query planner as unexpected plans are not unheard of; just because the query planner could choose an index doesn't mean that it will.
See EXPLAIN, for how to ask:
When EXPLAIN is used with an explainable statement, MySQL displays information from the optimizer about the statement execution plan. That is, MySQL explains how it would process the statement, including information [like index usage] about how tables are joined and in which order ..
.. With the help of EXPLAIN, you can see where you should add indexes to tables so that the statement executes faster by using indexes to find rows.
Related
I create a table which entried over 60milion rows.Everytime i query one row,it cost me 2minutes.how to speed up query these data.dudes.enter image description here
if you haven't done Indexing on Phone column then please do it, it make faster
like
CREATE INDEX info_phone_index ON Info (phone);
Syntax
CREATE INDEX index_name ON table_name (column1, column2, ...);
Then run your query,you will get faster results.
I am working with mysql dbs. There are two columns in a particular table (column1 and column2) and 10000000+ rows. I want to get all entries where column1 is one of a list of 50000 no.s. I am using this query currently:
Select * from db.table where column1 in (list of 50000 no.s)
Is there a faster query than this?
I can not talk about MySQL - only SQL Server - but the same principle may apply.
On SQL Server an IN has a serious problem of no statistics. Which means that with a non trivial number, the query plan is a table scan.
It is better to make a temporary table and load the ID's (AND put in a unique index on it which puts up statistics) and then JOIN between the two tables. More for the query analyzer to work with.
INDEX(column1)
Are there only 2 columns in the table? If not, then don't use SELECT *, but spell out the column names.
Please provide EXPLAIN SELECT ...
I am struggling to work out which columns are best to put my indexes on, when it seems adding additional indexes can have a detrimental effect on the query performance.
For example, I have the following query on a table with around 5m rows;
SELECT col1, col2 FROM table WHERE col1 = 'a' AND col2 = 'b' AND col3 = 'c';
Running this with no indexes takes 12 seconds!
I add a compound index on all 3 columns - table_col1_col2_col3_index;
My query now drops down to 2 seconds - great!
I now have another query on the same table (with no indexes on any column):
SELECT col1, col2 FROM table WHERE col1 = 'a';
Running this on its own and the query takes 4 seconds - still pretty slow!
So now I add a single column index to col1 table_col1_index
My query reduces down to 0.2 seconds. This is great, however I now run the original query again and notice that it is using this index opposed to the one I specified earlier. The original query is now back up at 6 seconds.
I am unsure how to go about ensuring that both queries can be optimised at the same time.
You can create indexes taking care to leave the most used or selective column on the left and then organizing the indexes if you can so you can use the same index in more queries ..
Furthermore you can always print the index you think is best adapted using FORCE (or IGNORE) https://dev.mysql.com/doc/refman/8.0/en/index-hints.html
SELECT * FROM table1 FORCE INDEX (col3_index)
WHERE col1=1 AND col2=2 AND col3=3;
Turn off the query cache, or use SELECT SQL_NO_CACHE ... when doing timing.
Run each timing test twice. The first may spend extra time fetching data and/or index blocks from disk. The second timing is better for comparisons. (And is closer to the way it would be in a "production" server.)
How many rows are being returned? That could have an impact. The 2nd query may be returning many times as many rows.
Please provide SHOW CREATE TABLE -- there could be subtle issues. (datatypes, column sizes, collations, who-knows-what)
Please provide EXPLAIN SELECT ... -- As written, each of your examples should say "Using index", meaning that the index "covers" the query, which means that all the columns in the SELECT exist in the INDEX being used.
Do not use "index hints" -- while it may help a query today, it may hurt it more tomorrow.
All of your examples would ('should') benefit from INDEX(col1, col2, col3), in that order; I would not add any others.
Currently I am creating indexes as I need them for a particular sql query.
But they are starting to overlap each other.
Is there any rule to define them effectively?
For example:
If I have two indexes for column1 and column2, does the composite index by column1, column2 improve select by both columns?
What is there any difference between an index by column1 and column2 over index by column2 and column1?
Q: If I have two indexes for column1 and column2, does the composite index by column1, column2 improve select by both columns?
Yes then composite Index is better.
From Mysql
"mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;
If a multiple-column index exists on col1 and col2, the appropriate rows can be fetched directly. If separate single-column indexes exist on col1 and col2, the optimizer attempts to use the Index Merge optimization (see Section 8.3.1.4, “Index Merge Optimization”), or attempts to find the most restrictive index by deciding which index excludes more rows and using that index to fetch the rows."
Q: What is there any difference between an index by column1 and column2 over index by column2 and column1?
Yes it will make difference. It depends on how you form your query.
From the Mysql docs:
Example If you have index like below on table :
INDEX name (last_name,first_name)
"The name index is an index over the last_name and first_name columns. The index can be used for lookups in queries that specify values in a known range for combinations of last_name and first_name values. It can also be used for queries that specify just a last_name value because that column is a leftmost prefix of the index."
You will get advantage of index for below query:
SELECT * FROM test WHERE last_name='Widenius';
But index is not used for lookups in the following queries:
SELECT * FROM test WHERE first_name='Michael';
Hope this will help !!
An index over two columns A and B is working as an index for column A also, but not as an index for column B.
I don't know if there is an simple rule for indexes, maybe just look for the columns involved in where clauses and order by statements in your queries and evaluate which to use.
Keep in mind that an index makes sense for a large number of rows where you search for a small subset. Indexes also slow down insertion and updates, so use them wisely. It is often enough to simply index all rows that are used to JOIN and add further ones if you run into performance issues.
If I have two indexes for column1 and column2, does the composite index by column1, column2 improve select by both columns?
Yes, it does. Separate indexes have to get merged first or just one index is used.
What is there any difference between an index by column1 and column2 over index by column2 and column1?
In a compound index the order of the columns matters, yes. If your query has only column2 in the WHERE clause, a compound index over (column1, column2) will not be used.
If you have a compound index over (column1, column2) it can also be used if your query only has column1 in WHERE clause.
For additional information see other answers I gave to questions about indexing:
MYSQL Long super-keys
MySQL query optimization of LIKE term% ORDER BY int
Q)If I have two indexes for column1 (A) and column2 (B), does the composite index by column1, column2 improve select by both columns?
yes if you have a just two indices A and B, SELECT something from table where A = 1 and B =2 will be using just one of two indices, but if you have compound index A,B it will use it, which should be faster
Q) What is there any difference between an index by column1 and column2 over index by column2 and column1?
sequence do matters in compound indices. Suppose you have the same query as above, and your table is 1 mln entries and only 50 of them match A=1 and 10000 match B=1, than compound index A,B will perform much better than B,A. So you need to choose first element of the index with the smallest cardinality.
This might be usefull
http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
http://stackoverflow.com/questions/1823685/when-should-i-use-a-composite-index
I have a table with 3 columns. This table contains many raws (millions). When I select rows from the table I frequently use the following where clauses:
where column2=value1 and column3=value2
where column1=value
To speed up the select query I want to declare column1 and column2 as indexes. My questions is if declaring the second column as an index will not reduce the positive effect of declaring the first column as index.
I also would like to ask if declaring the second column as index will speed up the queries of this type: where column2=value1 and column3=value2.
ADDED
The column1, column2, and column3 are entity, attribute, value. It's very general. As entities I use person, movies, cities, countries and so on. Attributes are things like: "located in", "date of birth", "produced by".
You should create indexes that support your queries. In this case you want to create an index on column2,column3 together (not two separate indexes, but one index for the combination of columns) to support the first query, and another on column1 to support the second query. More generally, if a query uses a set of columns, adding an index for all those columns will speed it up (although there are many exceptions, of course).
An index on column2 would speed up the query column2=value1 and column1=value2, and so would an index on column2,column3 (the important thing is that column2 is the first column in the index).
When working with indexes the EXPLAIN keyword is very useful. Prefix your queries with EXPLAIN (e.g. EXPLAIN SELECT * FROM table) to get a description of how the database is going to perform your query. It will tell you if it's going to use an index, and in that case which.
Seems like neither of your plans are going to work. Based on both of the where clauses I would suggest having the primary key on column1 and a second index column2,column3. This would speed up both of your queries.