SELECT * FROM information_schema.statistics WHERE table_schema = ‘?’ GROUP BY table_schema, table_name, column_name HAVING count(column_name) > 1;

In the above query bind the ‘database name’ parameter.

-Bog

Hi Roland, that’s a very good point. I should clarify something. The script compares prefixes on indexes, but for foreign keys it compares the entire definition (excluding the name) so it won’t think FKs to (col1) and (col1, col2) are duplicates of each other. This is as it should be, as you point out.

See, my Advanced Patented Algorithm ™ for detecting foreign keys is different from indexes! Tricky! ;-)

But your second point is true, too. A FK on multiple columns is functionally the same regardless of column order. String comparison can’t catch those. My first thought was “well, I’m going to have to parse out column names and do a bunch of fancy stuff…” but there’s an easier way that occurs to me now.

I’ll make these improvements and write another article about them in a bit.

Great tool. I have a question though. I was wondering why the project appears as “Duplicate index/foreign key finder” on MySQLForge.

I really know next to nothing about perl so I might miss an important point by not understanding the code, but it seems to me that if this script really compares the strings from the SHOW CREATE TABLE output like described above, it can in no way spot all duplicate or redundant foreign key definitions.

It depends on what you call a duplicate foreign key of course. I mean, suppose the (innoDB) parent table would have an index on (col1,col2) then I can create two foreign key constraints in the child table, one that references just (col1), and one that references (col1,col2). I suppose the script would catch these cases. However, I would not call those ‘duplicate’ foreign keys. I would prefer ’spurious’ or ‘redundant’. Take a look at this example:

CREATE TABLE `c` (
  `name` varchar(10) DEFAULT NULL,
  `seq` int(11) DEFAULT NULL,
  KEY `name` (`name`,`seq`),
  KEY `seq` (`seq`,`name`),
  CONSTRAINT `c_ibfk_1` FOREIGN KEY (`name`, `seq`) REFERENCES `p` (`name`, `seq`),
  CONSTRAINT `c_ibfk_2` FOREIGN KEY (`seq`, `name`) REFERENCES `p` (`seq`, `name`)
) ENGINE=InnoDB

(You can get this situation only if you create corresponding indexes (name,seq) and (seq,name) on the parent table as well of course. I used a primary key for (name,seq) and a unique constraint for (seq,name) to get this effect.)

Now that’s what I would call duplicate foreign keys - there really is no functional difference between these foreign key definitions (but there is for the aforementioned cases): they impose identical restrictions on the allowed input in the (name,seq) columns.

Of course, the involved indexes are not equivalent, and arguably not duplicates (because they potentially lead to different query execution plans).

A little touch: it makes sense to process different types of indexes, full-text indexes in particular, separately.

For example, a complex full-text index cannot replace a simple index:

create table user
(
  user_id    bigint(20) not null auto_increment
, first_name    varchar(32) not null default ''
, last_name    varchar(32) not null default ''
, email    varchar(64) not null default ''
...
, primary key user_pk (user_id)
, key user_last_name_i (last_name)
, fulltext key user_name_email_ft (last_name, first_name, email)
...
)

Script output:

Table test.user has possible duplicate indexes:
        `last_name`,`first_name',`email`
        `last_name`

Great work man. Keep it up ;)

Frank