The following section is included to inform users about the potential risks,
whether known or unknown, of using this tool. The two main categories of risks
are those created by the nature of the tool (e.g. read-only tools vs. read-write
tools) and those created by bugs.

This tool is read-only unless you use --save-results-database. It reads a
log of queries and EXPLAIN them. It also gathers information about all tables
in all databases. It should be very low-risk.

At the time of this release, we know of no bugs that could cause serious harm to
users.

The authoritative source for updated information is always the online issue
tracking system. Issues that affect this tool will be marked as such. You can
see a list of such issues at the following URL:
http://www.maatkit.org/bugs/mk-index-usage.

This tool connects to a MySQL database server, reads through a query log, and
uses EXPLAIN to ask MySQL how it will use each query. When it is finished, it
prints out a report on indexes that the queries didn't use.

The query log needs to be in MySQL's slow query log format. If you need to
input a different format, you can use mk-query-digest to translate the
formats. If you don't specify a filename, the tool reads from STDIN.

The tool runs two stages. In the first stage, the tool takes inventory of all
the tables and indexes in your database, so it can compare the existing indexes
to those that were actually used by the queries in the log. In the second
stage, it runs EXPLAIN on each query in the query log. It uses separate
database connections to inventory the tables and run EXPLAIN, so it opens two
connections to the database.

If a query is not a SELECT, it tries to transform it to a roughly equivalent
SELECT query so it can be EXPLAINed. This is not a perfect process, but it is
good enough to be useful.

The tool skips the EXPLAIN step for queries that are exact duplicates of those
seen before. It assumes that the same query will generate the same EXPLAIN plan
as it did previously (usually a safe assumption, and generally good for
performance), and simply increments the count of times that the indexes were
used. However, queries that have the same fingerprint but different checksums
will be re-EXPLAINed. Queries that have different literal constants can have
different execution plans, and this is important to measure.

After EXPLAIN-ing the query, it is necessary to try to map aliases in the query
back to the original table names. For example, consider the EXPLAIN plan for
the following query:

SELECT * FROM tbl1 AS foo;

The EXPLAIN output will show access to table foo, and that must be translated
back to tbl1. This process involves complex parsing. It is generally very
accurate, but there is some chance that it might not work right. If you find
cases where it fails, submit a bug report and a reproducible test case.

Queries that cannot be EXPLAINed will cause all subsequent queries with the
same fingerprint to be blacklisted. This is to reduce the work they cause, and
prevent them from continuing to print error messages. However, at least in
this stage of the tool's development, it is my opinion that it's not a good
idea to preemptively silence these, or prevent them from being EXPLAINed at
all. I am looking for lots of feedback on how to improve things like the
query parsing. So please submit your test cases based on the errors the tool
prints!

After it reads all the events in the log, the tool prints out DROP statements
for every index that was not used. It skips indexes for tables that were never
accessed by any queries in the log, to avoid false-positive results.

If you don't specify --quiet, the tool also outputs warnings about
statements that cannot be EXPLAINed and similar. These go to standard error.

Progress reports are enabled by default (see --progress). These also go to
standard error.

Default character set. If the value is utf8, sets Perl's binmode on
STDOUT to utf8, passes the mysql_enable_utf8 option to DBD::mysql, and
runs SET NAMES UTF8 after connecting to MySQL. Any other value sets
binmode on STDOUT without the utf8 layer, and runs SET NAMES after
connecting to MySQL.

Several example queries are given for querying the tables in the
--save-results-database. These example queries are, by default, created
as views. Specifying --no-create-views prevents these views from being
created.

By default mk-index-usage will only suggest to drop unused secondary indexes,
not primary or unique indexes. You can specify which types of unused indexes
the tool suggests to drop: primary, unique, non-unique, all.

A separate ALTER TABLE statement for each type is printed. So if you
specify --drop all and there is a primary key and a non-unique index,
the ALTER TABLE ... DROP for each will be printed on separate lines.

Print progress reports to STDERR. The value is a comma-separated list with two
parts. The first part can be percentage, time, or iterations; the second part
specifies how often an update should be printed, in percentage, seconds, or
number of iterations.

Save results to tables in this database. Information about indexes, queries,
tables and their usage is stored in several tables in the specified database.
The tables are auto-created if they do not exist. If the database doesn't
exist, it can be auto-created with --create-save-results-database. In this
case the connection is initially created with no default database, then after
the database is created, it is USE'ed.

mk-index-usage executes INSERT statements to save the results. Therefore, you
should be careful if you use this feature on a production server. It might
increase load, or cause trouble if you don't want the server to be written to,
or so on.

This is a new feature. It may change in future releases.

After a run, you can query the usage tables to answer various questions about
index usage. The tables have the following CREATE TABLE definitions:

The following are some queries you can run against these tables to answer common
questions you might have. Each query is also created as a view (with MySQL
v5.0 and newer) if --[no]create-views is true (it is by default).
The view names are the strings after the MAGIC_view_ prefix.

Question: which queries sometimes use different indexes, and what fraction of
the time is each index chosen? MAGIC_view_query_uses_several_indexes:

Question: given a table, which indexes were used, by how many queries, with how
many distinct fingerprints? Were there alternatives? Which indexes were not
used? You can edit the following query's SELECT list to also see the query IDs
in question. MAGIC_view_index_usage:

SELECT i.idx, iu.usage_cnt, iu.usage_total,
ia.alt_cnt, ia.alt_total
FROM indexes AS i
LEFT OUTER JOIN (
SELECT db, tbl, idx, COUNT(*) AS usage_cnt,
SUM(cnt) AS usage_total, GROUP_CONCAT(query_id) AS used_by
FROM index_usage
GROUP BY db, tbl, idx
) AS iu ON i.db=iu.db AND i.tbl=iu.tbl AND i.idx = iu.idx
LEFT OUTER JOIN (
SELECT db, tbl, idx, COUNT(*) AS alt_cnt,
SUM(cnt) AS alt_total,
GROUP_CONCAT(query_id) AS alt_queries
FROM index_alternatives
GROUP BY db, tbl, idx
) AS ia ON i.db=ia.db AND i.tbl=ia.tbl AND i.idx = ia.idx;

Question: which indexes on a given table are vital for at least one query (there
is no alternative)? MAGIC_view_required_indexes:

These DSN options are used to create a DSN. Each option is given like
option=value. The options are case-sensitive, so P and p are not the
same option. There cannot be whitespace before or after the = and
if the value contains whitespace it must be quoted. DSN options are
comma-separated. See the maatkit manpage for full details.

Where toolname can be replaced with the name (or fragment of a name) of any
of the Maatkit tools. Once downloaded, they're ready to run; no installation is
needed. The first URL gets the latest released version of the tool, and the
second gets the latest trunk code from Subversion.

Please use Google Code Issues and Groups to report bugs or request support:
http://code.google.com/p/maatkit/. You can also join #maatkit on Freenode to
discuss Maatkit.

Please include the complete command-line used to reproduce the problem you are
seeing, the version of all MySQL servers involved, the complete output of the
tool when run with --version, and if possible, debugging output produced by
running with the MKDEBUG=1 environment variable.

This program is copyright 2010-2011 Baron Schwartz.
Feedback and improvements are welcome.

THIS PROGRAM IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation, version 2; OR the Perl Artistic License. On UNIX and similar
systems, you can issue `man perlgpl' or `man perlartistic' to read these
licenses.

You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 59 Temple
Place, Suite 330, Boston, MA 02111-1307 USA.

This tool is part of Maatkit, a toolkit for power users of MySQL. Maatkit
was created by Baron Schwartz; Baron and Daniel Nichter are the primary
code contributors. Both are employed by Percona. Financial support for
Maatkit development is primarily provided by Percona and its clients.