September 12, 2008

Unused indexes by single query

Posted by Vadim |

Usually unused indexes are devil, they waste diskspace, cache, they make INSERT / DELETE / UPDATE operations slower and what makes them worse - it is hard to find them.

But now ( with userstatsV2.patch) you can find all unused indexes (since last restart of mysqld) by single query

SQL:
  1. SELECT DISTINCT s.TABLE_SCHEMA, s.TABLE_NAME, s.INDEX_NAME
  2. FROM information_schema.statistics `s` LEFT JOIN information_schema.index_statistics INDXS
  3. ON (s.TABLE_SCHEMA = INDXS.TABLE_SCHEMA AND
  4. s.TABLE_NAME=INDXS.TABLE_NAME AND
  5. s.INDEX_NAME=INDXS.INDEX_NAME)
  6. WHERE INDXS.TABLE_SCHEMA IS NULL;

SQL:
  1. +--------------+---------------------------+-----------------+
  2. | TABLE_SCHEMA | TABLE_NAME                | INDEX_NAME      |
  3. +--------------+---------------------------+-----------------+
  4. | art100       | article100                | ext_key         |
  5. | art100       | article100                | site_id         |
  6. | art100       | article100                | hash            |
  7. | art100       | article100                | forum_id_2      |
  8. | art100       | article100                | published       |
  9. | art100       | article100                | inserted        |
  10. | art100       | article100                | site_id_2       |
  11. | art100       | author100                 | PRIMARY         |
  12. | art100       | author100                 | site_id         |
  13. ...
  14. +--------------+---------------------------+-----------------+
  15. 1150 rows IN SET (1 min 44.23 sec)

As you see query is not fast, mainly because information_schema.statistics is slow by itself, but in any case very helpful.

For some versions of the patch, where the table has only the INDEX_NAME and the ROWS_READ columns, you can use this query:

SQL:
  1. SELECT DISTINCT s.TABLE_SCHEMA, s.TABLE_NAME, s.INDEX_NAME
  2. FROM information_schema.statistics `s`
  3.    LEFT JOIN information_schema.index_statistics IST
  4.       ON CONCAT_WS('.', s.TABLE_SCHEMA, s.TABLE_NAME, s.INDEX_NAME) = IST.INDEX_NAME
  5. WHERE IST.INDEX_NAME IS NULL;

Google’s user_statistics V2 port and changes

Posted by Vadim |

Recently Google published V2 release of patches, one of them user_statistics we use in our releases.
New features are quite interesting so we decided to port it to fresh releases of MySQL. Features includes:

      New statistics per user (Cpu_time, Bytes_received, Bytes_sent, etc)
      New command SHOW CLIENT_STATISTICS, which shows statistics per client's hostname, not per user
      FLUSH USER_ and CLIENT_STATISTICS commands

Our port includes:

  • INFORMATION_SCHEMA tables - USER_STATISTICS, CLIENT_STATISTICS, INDEX_STATISTICS, TABLE_STATISTICS
  • Access protection - USER_STATISTICS, CLIENT_STATISTICS available only for user with SUPER or PROCESS privileges. INDEX_STATISTICS, TABLE_STATISTICS shows only information of tables that current user has access to (SELECT privileges required). This is important for hosting providers

[read more...]

What Bugs makes you to recomend upgrade most frequently ?

Posted by peter |

What bug makes you to recommend upgrading most frequently ? For me it is this bug which makes it quite painful to automate various replication tasks.

It is not the most critical bug by far but this makes it worse - critical bugs would usually cause upgrades already or were worked around while such stuff as causing things like "sometimes my slave clone script does not work" may hang on for years.