Pe măsură ce restaurați baza de date dintr-un dump MySQL, vă puteți rezolva problema și, de asemenea, vă protejați baza de date pentru viitor, schimbând setul de caractere și colaționările pentru tabelele, funcțiile și procedurile dvs. Există o serie de modificări între MySQL 5.7 și 8.x, așa că acesta este într-adevăr cel mai bun moment pentru a face acest lucru.
Iată ce poți face cu fiecare CREA afirmație:
Inlocuieste CHARSET IMPLICIT la utf8mb4
Inlocuieste COLATEAZĂ la utf8mb4_unicode_ci
(Pentru tabele) Asigurați-vă că MOTOR este setat sa InnoDB
Notă: Nu mai doriți să utilizați MyISAM și nici nu doriți să amestecați MOTOR tipurile cu interogări, deoarece aceasta este o performanță destul de semnificativă.
Faceți toate acestea cu editorul de text preferat, apoi rulați procesul de import într-o bază de date MySQL proaspătă. Asigurați-vă că setați baza de date CHARSET IMPLICIT și COLATEAZĂ valorile la aceleași cu cele pe care le aveți pentru tabele, funcții și proceduri.
Motivul sugestiilor:
MySQL 8.0 este o abatere semnificativă de la linia 5.x, cu o mare parte de elemente care au fost depreciate înainte de 5.2 fiind complet eliminate. Aceasta include anumite tipuri de coloane, precum și colaționări. Procesul de import va încerca să adapteze automat elementele depreciate la echivalentele lor moderne, dar adesea face o mizerie de seturi de caractere și colaționări.
The utf8mb4_unicode_ci s-a dovedit a fi cea mai fiabilă collare atunci când lucrați cu caractere pe mai mulți octeți, cum ar fi emoji și cele utilizate în limbi non-engleze.Deși va folosi puțin mai mult spațiu pe disc, acest lucru se va asigura că aplicațiile dvs. pot gestiona orice caracter aruncat în ea. The _ci bit la sfârșit asigură că valorile sunt tratate ca insensibile la majuscule și minuscule atunci când se alătură și se efectuează căutări.
Înlocuirea tuturor CHARSET și COLATEAZĂ valorile vă vor asigura că nu primiți Combinație ilegală de colaționări eroare din nou... cu excepția cazului în care...
Lucruri de luat în considerare cu procedurile stocate și declanșatoarele
MySQL 8.0 pare să se aștepte la ceva mai multă specificitate atunci când creează tabele temporare în procedurile stocate. Dacă utilizați tabele temporare, asigurați-vă că le predefiniți în cod, așa cum ați face cu un tabel normal. Sintaxa este aproape aceeași, cu excepția faptului că adăugați un cuvânt suplimentar:
RIDĂȚI TABELUL TEMPORAR DACĂ EXISTĂ `Sume anuale`;
CREAȚI TABEL TEMPORAR DACĂ NU EXISTĂ `YearlySums` (
...
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Acest lucru vă va asigura că nu veți întâlni Combinație ilegală de colaționări eroare atunci când lucrați cu proceduri stocate.
Dacă mesele dumneavoastră au ÎNAINTE DE INSERE sau ÎNAINTE DE ACTUALIZARE declanșatoarele și acele tabele sunt populate prin proceduri stocate, veți dori să faceți o mulțime de teste înainte de a pune baza de date într-o setare de producție. Oracle a introdus o eroare destul de serioasă în 8.0.25, care poate duce la blocarea motorului MySQL Server în anumite cazuri când un INAINTE DE declanșatorul procesează rândurile ca parte a validării datelor, dar numai atunci când acele date sunt furnizate de o procedură stocată. Problema există de peste un an și Oracle pare să nu-i pese.
Nu lăsați acest bug să vă strice vacanța de Anul Nou, așa cum a făcut-o pe a mea anul trecut
