When it comes to querying, indexing of a table should never be your first concern.
The queries you plan to use should dictate the indexes you need.
Based on the queries, some columns can be individually indexed. Other queries require compound indexes. The ORDER BY
and GROUP BY
clauses should provide immediate hints for indexes to make. Not using such hints may result in temp table sorting rather than using the indexes for data in the desired order needed.
Low cardinality of column values should eliminate the need for an index.
Even with these things taken into consideration, you may find that query may need some adjustment (a.k.a. refactoring) for performance gains.
When you reach the point of having the right indexes, not you have to worry about the size of those indexes. For a MyISAM table, this would mean that the .MYI file may grow significantly.
The size of the index file as well as the number of indexes should now be weighed against the performance of your queries, especially if the indexes provide the proper ordering of data and fastest retrieval.
Explain plans for queries may change over time depending on the number of rows, cardinality of columns, number of DELETEs and UPDATEs. Once a query's explain plan changes from what it looked like months ago, you should explore the need to add or remove indexes.
My rules of thumb for indexing are to
- first, read the execution plan,
then think about adding (or verifying) an index on
- every column used in a WHERE clause,
- every column used in a JOIN condition,
- every column used in an ORDER BY.
In some cases, one multi-column index will be faster in SELECT statements than several single-column indexes.
Then, make sure your WHERE clauses are sargable. Expressions like LIKE '%user: john.doe@example.com%'
are not sargable. Unless you extract the user information and store it elsewhere, full table scans are in your future.
When MySQL has to use a filesort, it writes rows to the sort buffer using a fixed-width format. The wider your columns, the longer it's liable to take to sort.
Filesort uses a fixed-length row-storage format similar to that used
by the MEMORY storage engine. Variable-length types such as VARCHAR
are stored using a fixed length.
The fixed length for columns of type text defaults to 1024 bytes. MySQL will use a slower algorithm for sorts that include text columns.
[MySQL] normally uses the modified algorithm except when BLOB or TEXT
columns are involved, in which case it uses the original algorithm.
[snip]
One problem with this approach is that it reads rows twice: One time
when evaluating the WHERE clause, and again after sorting the pair
values. And even if the rows were accessed successively the first time
(for example, if a table scan is done), the second time they are
accessed randomly. (The sort keys are ordered, but the row positions
are not.)
Best Answer
You can retrieve the complete DDL statement for each index from the Postgres system catalogs.
The following will retrieve all
CREATE
index statements for a single table:You can spool the output into a script and run it after you have copied the data and swapped the table names.