Avem un site care după câțiva ani a acumulat 10 milioane de înregistrări în tabelul paragraphs_item. Acesta este rezultatul multor migrări de date (unde sunt implicate paragrafe) și acum sunt mulți orfani (probabil 90% din asta).
Entity Reference Revisions este livrat cu o comandă Drush acum pentru a „purge” entitățile orfane. Acest lucru pare să funcționeze - dar cu atât de multe pentru a le examina, se pare că va dura foarte mult timp pentru a le parcurge pe toate. Trebuie remarcat că sunt nu a rămas orfan ca urmare a ștergerii entității gazdă. Datorită modului în care datele sunt migrate, paragrafele sunt reconstruite și înlocuite datorită definiției de migrare. Nu putem schimba acest lucru acum, nu până când nu există un fel de hash pe subsetul de date pentru a indica dacă ar trebui să importăm sau să omitem.
Am o suspiciune că acest lucru face ca interogarea pe formularele de editare la editarea unui Paragraf să devină mai lentă în timp, ceea ce duce acum la imposibilitatea de a se executa (MariaDB nu mai răspunde). Chiar dacă toate câmpurile sunt indexate pe schema Paragrafelor, eficiența este în scădere.
Dacă șterg și îl las să ștergă 200.000 de articole, de exemplu - rularea unui sql OPTIMIZE pe tabelul paragraphs_item pare să susțină această teorie. Prima editare durează 8 secunde pentru a încărca un paragraf, după care este aproape instantanee. Deci, ștergerea tuturor paragrafelor nefolosite este ceea ce cred că ar trebui să facem. Îmi dau seama că OPTIMIZE pe InnoDB are ca rezultat reconstruirea indexului, dar în cazurile în care actualizați versiuni ale bazei de date, aceste date sunt atât de mari încât cred că nu se pot reconstrui la un anumit prag.
Există o modalitate mai rapidă de a interoga și de a șterge paragrafele orfane dincolo de curățare?
