2009-07-23 11 views
2

EDIT: Il semble que j'obtiens l'erreur listée ci-dessous sur chaque insertion, peu importe les données que j'essaie d'insérer. Alors peut-être que ma table était corrompue ou quelque chose? Quoi qu'il en soit, voici ma question:Erreur d'entrée en double MySQL lorsqu'il n'y a pas de doublon

J'ai une table MySQL

CREATE TABLE `AcpConfig` (
    `ndss_id` int(11) NOT NULL default '0', 
    `acp_id` int(11) NOT NULL default '0', 
    `run_date` date NOT NULL default '0000-00-00', 
    `hw_5_threshold` tinyint(1) NOT NULL default '0', 
    `stp_on` tinyint(1) NOT NULL default '0', 
    `sort_on` tinyint(1) NOT NULL default '0', 
    `afcs_ocr_message_format` tinyint(1) NOT NULL default '0', 
    `use_hw` tinyint(1) NOT NULL default '0', 
    `test_mode` tinyint(1) NOT NULL default '0', 
    `afcs_version` varchar(255) NOT NULL default '', 
    `acp_build` varchar(255) NOT NULL default '', 
    `id` int(11) NOT NULL auto_increment, 
    `swstp_in_acp_rack` int(11) NOT NULL default '0', 
    `acplookup_id` int(11) NOT NULL default '0', 
    `bfind_cksum` varchar(255) NOT NULL default '', 
    `tz_cksum` varchar(255) NOT NULL default '', 
    `fetched` varchar(4) NOT NULL default '"NO"', 
    PRIMARY KEY (`id`), 
    UNIQUE KEY `ndss_id` (`ndss_id`,`acp_id`,`run_date`), 
    KEY `ndss_acp` (`ndss_id`,`acp_id`), 
    KEY `ndss_acp_rundate` (`ndss_id`,`acp_id`,`run_date`), 
    KEY `run_date` (`run_date`), 
    KEY `acplookup_rundate` (`acplookup_id`,`run_date`) 
) ENGINE=MyISAM DEFAULT CHARSET=latin1 

Et il a obtenu environ un demi-million de lignes. Je suis en train d'effectuer une insertion simple

INSERT INTO AcpConfig (ndss_id, acp_id, run_date, hw_5_threshold, stp_on, sort_on, afcs_ocr_message_format, use_hw, test_mode, afcs_version, acp_build, swstp_in_acp_rack, acplookup_id, bfind_cksum, tz_cksum) VALUES ('75', '5', '2009-07-22', '75', '1', '1', '0', '1', '0', '1.5.2', '041709', '2', '269', '0', '1950359846'); 

et il me donne l'erreur

ERROR 1062 (23000): Duplicate entry '502831' for key 1 

ce qui implique que je ne respecte pas mon UNIQUE sur les trois champs ndss_id, acp_id et run_date. (L'id 502831 n'est pas une ligne dans ma table et semble être le prochain id qui serait utilisé si la ligne avait été insérée.) Le problème est, si je sélectionne contre les champs avec les mêmes valeurs

select * from AcpConfig where ndss_id=75 and acp_id=5 and run_date='2009-07-22'; 

alors il ne retourne aucun résultat. Donc, je ne duplique rien. Mes autres clés ne sont que des index et non des contraintes uniques; J'ai aussi la contrainte UNIQUE comme vous pouvez le voir à partir de mon instruction CREATE TABLE. Alors pourquoi me dit-il que j'ai un duplicata?

Répondre

2

Apparemment, la table était corrompue. J'ai couru CHECK TABLE et a vu quelques erreurs de corruption, puis couru REPAIR TABLE et il a semblé fonctionner; ensuite mes INSERTS ont recommencé à travailler.

mysql> check table AcpConfig; 
+---------------+-------+----------+----------------------------------------------------------+ 
| Table   | Op | Msg_type | Msg_text             | 
+---------------+-------+----------+----------------------------------------------------------+ 
| acp.AcpConfig | check | warning | 8 clients are using or havent closed the table properly | 
| acp.AcpConfig | check | warning | Size of datafile is: 32079848  Should be: 32079784 | 
| acp.AcpConfig | check | error | Found 495762 keys of 495761        | 
| acp.AcpConfig | check | error | Corrupt             | 
+---------------+-------+----------+----------------------------------------------------------+ 
4 rows in set (3.50 sec) 

mysql> repair table AcpConfig; 
+---------------+--------+----------+----------------------------------------------+ 
| Table   | Op  | Msg_type | Msg_text          | 
+---------------+--------+----------+----------------------------------------------+ 
| acp.AcpConfig | repair | warning | Number of rows changed from 495761 to 495762 | 
| acp.AcpConfig | repair | status | OK           | 
+---------------+--------+----------+----------------------------------------------+ 
2 rows in set (13.14 sec) 
+1

Je suppose que REPAIR TABLE a également corrigé vos numéros de séquence – northpole

3

Serait-il possible que vos numéros de séquence soient désactivés par rapport à auto_increment sur id? Essayez de régler la touche plus haut et réessayez l'insertion. Apparemment, cela réinitialisera le prochain auto_increment pour qu'il soit la prochaine valeur disponible la plus élevée.

+0

Suggestion géniale; Je me demandais comment faire exactement cela, donc c'est une bonne référence. Cependant, comme je l'ai dit dans ma réponse ci-dessous, le problème a été résolu par une déclaration REPAIR TABLE, donc je ne suis pas sûr que cela aurait arrangé les choses. Merci quand même. –