SQLSTATE[23000] : Integrity constraint violation en pleine réindexation du catalogue

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '4821-eur' for key 'lookup_table.unique_sku_currency' — ce message, apparu au milieu d’une réindexation massive relançée après une migration de catalogue, arrête net le traitement. Une seule ligne en conflit suffit à interrompre l’ensemble du processus, sans que le reste du catalogue, parfaitement valide, ne soit jamais atteint.

Ce type d’erreur survient typiquement après une migration de catalogue volumineuse, quand une réindexation est relancée pour reconstruire les tables de correspondance utilisées par les fonctionnalités de recherche et de filtrage produit. Le diagnostic suit une méthode précise : identifier le symptôme exact, comprendre la cause réelle, corriger la donnée en amont, puis prévenir la récidive.

Symptôme : une réindexation qui s’arrête toujours au même point

Le signe distinctif de ce problème n’est pas l’erreur elle-même, mais sa reproductibilité : relancer la réindexation depuis le début produit systématiquement le même échec, au même point, sur la même ligne. Ce comportement écarte d’emblée l’hypothèse d’un problème transitoire de charge serveur ou de verrou temporaire, et oriente directement vers un problème de données.

Le message d’erreur lui-même contient l’information clé : le code 1062 signale une violation de clé unique, pas une violation de clé étrangère (qui produirait un code 1452). Cette distinction change complètement la piste de diagnostic à suivre.

Diagnostic : isoler la ligne en conflit

Une fois le nom de la contrainte identifié dans le message d’erreur — ici unique_sku_currency, qui suppose l’unicité d’une combinaison référence produit et devise — la requête suivante permet d’isoler précisément les doublons responsables :

SELECT sku, devise, COUNT(*) AS occurrences
FROM wp_wc_product_lookup_table
GROUP BY sku, devise
HAVING COUNT(*) > 1
ORDER BY occurrences DESC;

Sur le projet à l’origine de ce diagnostic, cette requête a révélé une ligne dupliquée pour la référence 4821 en euros, provenant de deux imports partiels effectués à des moments différents de la migration, sans qu’une purge complète des tables de correspondance n’ait été faite entre les deux tentatives.

Comprendre pourquoi la contrainte existe

Il est tentant, face à ce blocage, de vouloir simplement supprimer la contrainte d’unicité pour laisser la réindexation se terminer. C’est une fausse bonne idée : cette contrainte existe précisément pour empêcher qu’un même produit, dans une même devise, ne soit référencé deux fois dans les tables de recherche, ce qui produirait des résultats de recherche dupliqués ou incohérents côté vitrine.

Correctif : nettoyer la donnée, pas la contrainte

Le correctif consiste à supprimer la ligne obsolète issue de l’import partiel incomplet, en identifiant laquelle des deux lignes correspond à l’état le plus récent et cohérent du produit :

DELETE FROM wp_wc_product_lookup_table
WHERE sku = '4821' AND devise = 'eur' AND date_maj < '2026-01-30 00:00:00';

Cette suppression ciblée, vérifiée ligne par ligne avant exécution, évite de perdre la version correcte du produit tout en libérant la contrainte d’unicité pour la relance de la réindexation.

Vérifier l’absence d’autres doublons avant de relancer

Corriger un seul doublon ne garantit pas qu’il n’en existe pas d’autres plus loin dans le catalogue. Relancer la requête de diagnostic après chaque correction, jusqu’à ce qu’elle ne retourne plus aucune ligne, évite de relancer une réindexation longue pour découvrir un nouveau blocage quelques minutes plus tard.

• Relancer la requête de détection des doublons après chaque correction
• Ne jamais supprimer la contrainte d’unicité elle-même comme solution de contournement
• Conserver une trace des lignes supprimées, en cas de besoin de vérification ultérieure

Une contrainte d’intégrité qui bloque un traitement n’est jamais l’obstacle à supprimer : c’est le signal que la donnée elle-même contient une incohérence à corriger en amont.

Prévention : éviter la récidive lors de futures migrations

Pour éviter que ce type d’incident ne se reproduise lors d’une prochaine migration, une purge complète des tables de correspondance avant chaque nouvelle tentative d’import, plutôt qu’un import incrémental sur des données potentiellement déjà présentes, élimine la cause structurelle de ces doublons.

Ce que ce diagnostic ne couvre pas

Ce debug concerne exclusivement la violation de contrainte d’unicité rencontrée pendant la réindexation. Il ne traite pas de la reconstruction des index de recherche eux-mêmes, ni des choix de moteur de recherche produit, sujets distincts déjà couverts par ailleurs.

En résumé

Une erreur SQLSTATE[23000] pendant une réindexation massive de catalogue signale presque toujours une violation de clé unique provoquée par un import partiel non purgé avant une nouvelle tentative. Le réflexe à éviter est de supprimer la contrainte ; le réflexe à adopter est d’isoler la donnée dupliquée, de la corriger à la source, et de purger systématiquement les tables de correspondance avant toute nouvelle migration.