Réinitialiser/réorganiser les publications dans la table MySQL wp_posts
J'ai un site Wordpress qui est considérablement populaire. Je suis en train d'optimiser le site avant d'ajouter d'autres plugins, tels que le plugin WPML, qui, je suppose, utilisera des types de publication personnalisés. Le site a déjà d’autres plugins que je ne soupçonne pas d’utiliser la table wp_posts pour les types de posts personnalisés, à l’exception de 1 ou 2, juste pour créer.
Est-il possible de reconstruire/mettre à jour/réorganiser la colonne ID dans la table wp_posts de manière à ce que les ID de publication commencent à 1 et augmentent sans interruption?
La table wp_posts contient 3 349 lignes. Le site contient environ 412 articles (type d’article) dans la table wordpress wp_posts. Le nombre le plus élevé dans la colonne ID est 7060 (ce qui est très volumineux) et toute nouvelle publication que j'ajoute augmentera le nombre à 7061. Le reste des lignes de la table sont d'autres types de publication, tels que des pièces jointes, certaines créées par d'anciens plugins. Il y a 2 786 lignes pour le type de pièce jointe, ce qui est un très grand nombre considérant que je n'utiliserai plus ces pièces jointes. Les 412 articles contiennent toutes les informations nécessaires pour le site. Je convertis les images en SVG et latex intégrés. La plupart des images étaient des nombres. Donc, après tout cela, j'aurai probablement 412 lignes dans la table wp_posts.
Je sais que je pourrais réinitialiser AUTO_INCREMENT à 1 en utilisant; ALTER TABLE nom_table AUTO_INCREMENT = valeur;
Mais je ne suis pas sûr de savoir comment réorganiser les identifiants de post. Je veux voir quelles précautions je devrais connaître avant de tenter cela. Je pense que ceci est important pour simplifier les identifiants de post car ils vont être utilisés dans tout le site multi. S'il existe une solution qui pourrait réorganiser et mettre à jour les références entières aux publications sur d'autres tables, ce serait génial !.
Je suis conscient que c'est une fonctionnalité de MySQL et je vais devoir travailler avec AUTO_INCREMENT.
Je suis conscient que d'autres types de publication, tels que les pièces jointes, peuvent contenir un identifiant parent qui renvoie aux publications d'origine. Je ne m'inquiète pas tant pour les pièces jointes parce que je veux quand même me débarrasser des 2 786 pièces jointes.
Je vais probablement perdre les balises et les catégories mais la simplification des identifiants de publication est essentielle. Je vais reconstruire les balises et les catégories de toute façon. Existe-t-il un moyen judicieux de garder ces clous.
Y a-t-il d'autres dangers dont je devrais m'inquiéter? Parce que de nombreux scripts/fonctionnalités vont être construits autour des publications du site principal, je souhaite rendre les identifiants de publication aussi uniques que possible à ce stade. Avoir un écart de 100 n'est pas unique pour moi.
J'espère que quelqu'un a la solution parfaite pour cela. Est-ce que je tente une idée très dangereuse?
Si vous souhaitez des numéros séquentiels pour vos publications, n'utilisez pas la colonne ID de publication.
AUTO_INCREMENT est destiné à fournir des numéros uniques (et des cerveaux divisés dans la réplication multi-maîtres), il ne sera jamais sans lacunes, en particulier dans WordPress (révisions, sauvegardes automatiques, pages, formulaires de contact, galeries et de nombreux autres plugins) et surtout pas avec InnoDB. Un simple échec/restauration d'une transaction peut entraîner l'incrémentation d'un milliard de fois des champs AUTO_INCREMENT sans insérer une seule ligne. C'est un comportement plutôt normal. Je citerai également Tamas de ce fil Stack Overflow:
Vous ne devriez jamais dépendre des fonctions numériques des clés générées automatiquement.
Du point de vue de la performance, peu importe. Un BIGINT détenant 412, un BIGINT détenant 7060 et un BIGINT détenant cinq milliards sont tous des entiers 64 bits.
Si vous voulez des identifiants véritablement séquentiels (pour votre UX ou autre), vous devez utiliser votre propre logique de numérotation beaucoup plus prévisible et isolée.
Cet identifiant de publication est utilisé par WordPress Core pour créer des liens croisés dans de nombreuses tables différentes, ainsi que par les plug-ins ou le thème. Il est également possible de rompre les liens si votre site a déjà utilisé des permaliens ?p=. Alors oui, c'est une idée très dangereuse.
Pour réinitialiser correctement vos identifiants de poste, vous allez faire beaucoup de travail, mais ce travail serait gaspillé. WordPress utilise un BIGINT non signé pour ce champ capable de une limite supérieure de 18 446 744 073 709 551 615 . Vous n'y arriverez jamais, avec ou sans les "lacunes" entre les publications.
De plus, chaque fois que WordPress crée une entrée dans la base de données, vous devrez refaire le travail, car WordPress ne fait aucun effort pour garder les ID en ordre, car vous semblez (à tort) penser nécessaire. Donc, chaque fois que WordPress modifie la base de données, vous allez devoir la nettoyer à nouveau. C’est beaucoup de code à écrire pour mettre le système en place et beaucoup de temps CPU pour l’exécuter.
Si vous ne vous souciez que des publications, vous pouvez les exporter et les importer dans une nouvelle base de données. Je ne sais pas si l'exportateur intégré stocke les identifiants de publication et les pièces jointes; vous risquez donc de devoir écrire les vôtres, ce qui ne devrait pas être trop difficile si vous tenez uniquement au contenu de la publication.
Le problème est que vous ne devriez pas vraiment utiliser un identifiant logiciel interne comme identifiant externe, c'est tout simplement mauvais pour votre santé. Si vous avez besoin d’un identifiant unique facile à retenir, créez simplement votre propre méta-champ et utilisez-le à cet effet.