InnoDB complaining about foreign key name in use when restoring database after dropping all tables

问题

I'm trying to use mysqldump to copy data from one server to another. The target server had a previous version of the same database installed, so all objects referenced already exist. I checked the output from mysqldump and it includes appropriate statements to (1) disable foreign key checks during the recreation and (2) drop the old tables. An edited excerpt looks like this:

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
...
DROP TABLE IF EXISTS `bins`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `bins` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `site` int(11) NOT NULL,
  `type` varchar(255) NOT NULL,
  `capacity` varchar(255) NOT NULL,
  `quantity` int(11) NOT NULL,
  `cost` decimal(9,2) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `sites_bins_idx` (`site`),
  CONSTRAINT `sites_bins` FOREIGN KEY (`site`) REFERENCES `sites` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=457 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

I understand the /*!nnnnn ... */ syntax to be a conditional syntax that only executes if the server version is higher than the included number (which mine is, being 5.0), so all the included SET statements should be executing.

I ran the script file generated by running mysql -p < dump.sql, but received the following error:

ERROR 1005 (HY000) at line 27: Can't create table './myschema/bins.frm' (errno: 121)

Running the query show innodb status gives the following additional information:

------------------------
LATEST FOREIGN KEY ERROR
------------------------
140420 13:15:07 Error in foreign key constraint creation for table `myschema/bins`.
A foreign key constraint of name `myschema/sites_bins` already exists.

However, how can the constraint exist when the table(s) it refers to have been dropped?

mysql> show tables;
Empty set (0.00 sec)

mysql> SELECT    constraint_name,   table_name FROM    information_schema.table_constraints  WHERE    constraint_type = 'FOREIGN KEY'    AND table_schema = DATABASE()  ORDER BY    constraint_name;
+--------------------------+------------------+
| constraint_name          | table_name       |
+--------------------------+------------------+
| clients_sites            | sites            |
| client_contacts          | contacts         |
| scheduledvisit_site      | scheduled_visits |
| sites_bins               | bins             |
| sites_visits             | site_visits      |
| sitevisit_sitevisitentry | site_visit_entry |
+--------------------------+------------------+
6 rows in set (0.00 sec)

I've even tried drop database myschema, but the constraints are still left behind even after this.

How have these constraints been left behind after their tables have been dropped? And how do I get rid of them so I can recreate their respective tables?

回答1:

InnoDB's handling of object names is case insensitive. MySQL's is dependent on the operating system's filename handling, which in my case was case sensitive. A previous version of the database had been created with the names capitalised at the start, so while MySQL was aware of a database myschema which was empty and MySchema which was not, InnoDB considered the two to be the same. Dropping the MySchema database allowed me to restore the dump from the remote system.

来源：https://stackoverflow.com/questions/23182969/innodb-complaining-about-foreign-key-name-in-use-when-restoring-database-after-d

标签

mysql

constraints

InnoDB