Duplicate index checker version 1.9 released

I’ve made more improvements to the duplicate index checker. I addressed a MySQL bug Roland Bouman mentioned to me, added more tests to the suite, and made changes so it considers more types of indexes now (HASH, BTREE, SPATIAL). I made no changes to the foreign key checking.

The bug Roland mentioned is a problem with SHOW CREATE TABLE that causes MySQL to show an index as type HASH when it’s really a BTREE. I found a pretty easy workaround.

In the meantime, Roland has released a SQL-only method to find duplicate indexes in newer versions of MySQL. It’s an excellent use of the INFORMATION_SCHEMA. He also wrote an article on finding duplicate indexes for O’Reilly Database, and for his own blog too.

Daniel Schneller has also continued to work on a Java implementation of a GUI tool to find duplicate and redundant indexes.

Technorati Tags:No Tags

You might also like:

  1. Introducing MySQL Duplicate Key Checker
  2. Duplicate index checker improved
  3. Duplicate index checker version 1.8 released
  4. MySQL Toolkit version 848 released
  5. MySQL Query Profiler, Checksum, Index Checker updated to version 1.0.1

5 Responses to “Duplicate index checker version 1.9 released”


  1. 1 Roland Bouman

    Hi Baron,

    great to hear you got round the bug…let’s hope it gets fixed anyway :)

    By the way, what’s your take on the column prefixes? I bumped into that when I was well into writing my article and at that point I just felt like “…oh no, not another complicating factor…”. For example, we could have:

    table (col1 varchar(1000), col2 char(1))
    
    index1 (col1(100))
    index2 (col1(1),col2)

    And if it get’s as insane as this it is likely that index1 is more selective than index2. In the end, that’s what determines the performance, and the ‘left-prefix’ criterion is just a simple and mostly effective measure for the selectivity.

  2. 2 Xaprb

    I thought about prefixes but decided not to go there. I could, though. I guess it wouldn’t be too hard to take out the parenthesized prefix notation and leave just the column names.

    Now that I think about it, I bet my regular expression breaks and doesn’t get all the column names when there’s a parenthesized prefix. I should look into this.

  3. 3 Xaprb

    Yes, prefixes made it break silently. I fixed that, and in the process made it ignore column prefixes entirely. Now these key definitions end up being exactly the same, so they will be reported as duplicates:

      PRIMARY KEY  (`day`,`account`),
      KEY `day` (`day`(12),`account`),
      KEY `day` (`day`,`account`(5)),

    Of course, they’re not really duplicates, or might not be anyway, but my whole philosophy with this tool is “catch enough problems to be helpful, then report them and let the DBA figure it out.”

  4. 4 john

    Yeah, well this whole idea isn’t very helpful to me. I need the thing to make it not do that stuff. If you could fix that it will help my employees be much more efficient. See, I run a large enterprise company that deals in interactive software that uses databases. We have a large Access database that we administrate. Let me know if you want to work for us, we could make a good offer.

  5. 5 Xaprb

    Hello my brother, I love you too :-)

    [Note: “john” above really is my brother, whose name isn’t John.]

Leave a Reply

Please do not use this blog to get help with problems or bugs in Maatkit or innotop: use the Sourceforge forums, mailing list, or bug trackers. If you're asking for help with MySQL, please use the MySQL mailing list instead.