I have two queries that are as follows:
SELECT * FROM table WHERE asset_type=%s AND country=%s AND series=%s
SELECT * FROM table WHERE asset_type=%s AND country=%s AND episode=%s
Should I add one composite index, including all four fields? Or two composite indexes, one for each query?
ALTER TABLE table ADD INDEX (asset_type, country, series)
ALTER TABLE table ADD INDEX (asset_type, country, episode)
-- or --
ALTER TABLE table ADD INDEX (asset_type, country, series, episode)
Why should I choose one over the other?
If you want to maximally optimize both queries, then use two indexes.
If the asset_type and country fields are highly selective -- meaning that they select very few of the rows in the original table -- then the one index will work. Note that for the second query, the first two keys will be used to find a position in the index to start scanning.
Related
I would like to know if it is necessary to create an index for all fields within a table if one of your queries will use SELECT *.
To explain, if we had a table that 10M records and we did a SELECT * query on it would the query run faster if we have created an index for all fields within the table or does MySQL handle SELECT * in a different way to SELECT first_field, a_field, last_field.
To my understanding, if I had a query that did SELECT first_field, a_field FROM table then it would bring performance benefits if we created an index on first_field, a_field but if we use SELECT * is there even a benefit from creating an index for all fields?
Performing a SELECT * FROM mytable query would have to read all the data from the table. This could, theoretically, be done from an index if you have an index on all the columns, but it would be just faster for the database to read the table itself.
If you have a where clause, having an index on (some of) the columns you have conditions on may dramatically improve the query's performance. It's a gross simplification, but what basically happens is the following:
The appropriate rows are filtered according to the where clause. It's much faster to search for these rows in an index (which is, essentially, a sorted tree) than a table (which is an unordered set of rows).
For the columns that where in the index used in the previous step the values are returned.
For the columns that aren't, the table is accessed (according to a pointer kept in the index).
indexing a mysql table for a column improves performance when there is a need to search or edit a row/record based on that column of that table.
for example, if there is an 'id' column and if it is a primary key; And in that case if you want to search a record using where clause on that 'id' column then you don't need to create index for the 'id' column because primary key column will act as an indexed column.
In another case, if there is an 'pid' column in the table and if it is not a primary key; Then in order to search based on 'pid' column then to improve performance it is better to create an index for the 'pid' column. That will make query fast to search the expected record.
I have 2 queries
SELECT * FROM table WHERE store_id=1 && album_id=1 && delete=0
UPDATE table SET delete=0 WHERE store_id=1 && album_id=1
I create an index store_id, album_id, delete
my question is can these 2 queries share this index?
or I have to create another index (store_id, album_id) for 2nd one
If you are creating one index that is a composite index as table(store_id, album_id, delete), then both queries should be able to use this index.
THe first will use all three fields in the index because they match the where clause exactly.
The second query will use the first two columns in the index for its where clause.
I have query that uses order-by group-by
select count(*),filed2
from table1 where field1>x group by filed2 order by count(*) desc
what are the best indexes for this query.
sholud I index filed1,field2 seprate or together?
You should create the index with both columns in two different orders
ALTER TABLE table1 ADD INDEX field1_field2_ndx (field1,field2);
ALTER TABLE table1 ADD INDEX field2_field1_ndx (field2,field1);
You should not create individual indexes because making the index with both columns will cause the query to pass through the index only to satisfy the query. It would never need to touch the table.
Even if you made individual indexes, the Query Optimizer would choose the two column index anyway.
Now that you have the two indexes, just trust the Query Optimizer to select the correct index. Based on the query, the EXPLAIN plan would choose the field2_field1_ndx index.
I've noticed that in PHPMyAdmin I can individually index columns or I can use checkboxes to select fields and then click index and they're indexed in a different way. Does this mean that if for a given table I have 2 columns of that table that define each row as unique (instead of just a simple single column id`) I should index those together to increase performance?
A multiple-column index can be considered a sorted array containing values that are created by concatenating the values of the indexed columns.
MySQL uses multiple-column indexes in such a way that queries are fast when you specify a known quantity for the first column of the index in a WHERE clause, even if you do not specify values for the other columns.
If you have two columns named last_name and first_name and you create an index INDEX name (last_name,first_name), The index can be used for queries that specify values in a known range for last_name, or for both last_name and first_name.
Source: http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
So, it may not be helpful in your particular case. Becuase if you want to query on the later columns (for example: SELECT * FROM test WHERE first_name='Michael' or SELECT * FROM test WHERE last_name='Widenius' OR first_name='Michael), the index will not be used and the queries will be slower.
I'm creating tables using phpMyAdmin and want to define two different columns as indices. I'm not trying to create a multi-column index but phpMyAdmin creates them as such. Are there any possible issues with that? The fields don't relate to each other directly and both fields will not be used in WHERE clauses simultaneously.
Consider:
ALTER TABLE `documents` ADD INDEX (`offer_number`, `contract_number`);
And:
ALTER TABLE `documents` ADD INDEX (`offer_number`);
ALTER TABLE `documents` ADD INDEX (`contract_number`);
What's the difference?
MySQL can only make use of an index if the first column(s) of the index match the columns used in the query. In other words, if you perform a query where an index on contract_number could be used, the composite index won't be used since contract_number is not the first column in that key. The composite index could be used for a query where offer_number is used, however.
http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html
Given what you say about these fields, they should not be a part of one multi column index.
If you want to create single column indexes on PhpMyAdmin, you need to create them one at a time.