I have a large table with millions of records.
Table `price`
------------
id
product
site
value
The table is brand new, and there are no indexes created.
I then issued a request for new index creation with the following query:
CREATE INDEX ix_price_site_product_value_id ON price (site, product, value, id);
This took long long time, last time I was checking ran for 5000+ seconds, because of the machine.
I am wondering if I issue another index creation, will it use the existing index in the process calculation? If so in what form?
Next to run query 1:
CREATE INDEX ix_price_product_value_id ON price (product, value, id);
Next to run query 2:
CREATE INDEX ix_price_value_id ON price (value, id);
No, it won't.
Theoretically, an index on
(site, product, value, id)
has everything required to build an index on any subset of these fields (including the indices on(product, value, id)
and(value, id)
).However, building an index from a secondary index is not supported.
First,
MySQL
does not support fast full index scan (that is scanning an index in physical order rather than logical), thus making an index access path more expensive than the table read. This is not a problem forInnoDB
, since the table itself is always clustered.Second, the record orders in these indexes are completely different so the records need to be sorted anyway.
However, the main problem with the index creation speed in
MySQL
is that it generates the order on site (just inserting the records one by one into aB-Tree
) instead of using a presorted source. As @Daniel mentioned, fast index creation solves this problem. It is available as a plugin for5.1
and comes preinstalled in5.5
.If you're using MySQL version 5.1, and the InnoDB storage engine, you may want to use the InnoDB Plugin 1.0, which supports a new feature called Fast Index Creation. This allows the storage engine to create indexes without copying the contents of the entire table.
Overview of the InnoDB Plugin:
Overview of Fast Index Creation: