Avatar billede AnyFellow Seniormester
21. juni 2023 - 17:00 Der er 8 kommentarer og
1 løsning

Skift fra MySql 5.7.42 til 8.0.33 har forøget svartiden voldsomt

Jeg har en server, der kører Mysql 5.7.42. Jeg har installeret en ny server med Mysql 8.0.33, men svartiden er steget voldsomt efterfølgende.

Jeg har en simpel tabel med knap 7.000 poster, hvor jeg forespørger med denne select (returnerer 68 rækker):
SELECT `file`, `child`
FROM `test_table`
WHERE `parent` = '01'
ORDER BY `child_sort_order`

På den oprindelige server tager forespørgslen 0,0008 sekunder, på den nye server tager forespørgslen 0,0303 sekunder.

Den gamle server kører 32 bit, den nye server kører 64 bit og har 8 x så meget ram samt dobbelt op på cpu.

Jeg har et php-script, der alene henter data i den nævnte tabel og load af denne side tager 9 sekunder på den nye server, mod 1 sekunder på den gamle server.

Jeg har ingen idé om hvad jeg skal kigge efter, for at identificere hvad der gør så stor en forskel.

Nogle bud?
Avatar billede arne_v Ekspert
21. juni 2023 - 17:20 #1
Normalt ville man starte med at checke om database struktur og MySQL konfiguration er ens.

Men med så få rækker er det svært at se hvilken ændring i konfiguration som kunne ændre det.

Men jeg er også mere bekymret over forskellen for det PHP script. 30 millisekunder er ikke meget. Men 8 sekunder er meget.

Så du skal nok sammenligne PHP og Apache konfiguration.

En kendt performance dræber er brug af reverse DNS lookup med en langsom eller ikke tilgængelig DNS server.
Avatar billede claes57 Ekspert
21. juni 2023 - 19:39 #2
det har sikkert intet at gøre mht performance, men hvorfor
SELECT `file`
når det vitterligt burde være
SELECT 'file'

´ og ` er til franske ord og systemet sidder måske og prøver om file´ er ment som filé
Til ordafgrænsninger er " (over 2) og ' (til højre for ø) dem, der bruges.
Når du bruger ´ og `  så ser det lige så dumt ud som at bruge ~ og ^
Avatar billede arne_v Ekspert
21. juni 2023 - 19:52 #3
#2

SELECT file FROM ...

vil give en fejl fordi FILE er et reserveret ord.

SELECT 'file' FROM ...

(lodrette gnyffer)

vil udskrive strengen file fordi single quotes bruges i SQL som streng separator.

SELECT `file` FROM ...

(højrelænende gnyffer)

vil udskrive værdier fra feltet file fordi højrelænende gnyffer bruges af MySQL til at markere at noget er et brugervalgt navn.
Avatar billede arne_v Ekspert
21. juni 2023 - 19:57 #4
Jeg anbefaler normalt at undlade at bruge navne som er reserverede ord og undlade bruge af højrelænende gnyffer, men det er best practice ikke MySQL syntax regler.
Avatar billede arne_v Ekspert
21. juni 2023 - 20:07 #5
Hmmm. Strengt taget er det vel iøvrigt venstrehældende gnyffer. Jeg er træt idag.
Avatar billede claes57 Ekspert
21. juni 2023 - 20:16 #6
takker for info - det er da også lettere at skrive `file` i stedet for at navngive det fil
Avatar billede AnyFellow Seniormester
22. juni 2023 - 07:33 #7
Kommentar til #1:
Jeg er ikke nervøs for php-scriptet. Scriptet er noget jeg har overtaget fra et gammelt system. Det er meget uhensigtmæssigt opbygget og laver derfor 288 kald til databasen, hvilket altså gøres på 1 sekunder på den ene server og 9 sekunder på den anden server. Jeg har isoleret den længere svartid direkte til databasekaldene.

På den ene server tager kaldene knap 0,3 sekunder i alt, på den anden server ca. 8,7 sekunder.

Jeg har testet kaldene dirkte i sql-konsollen lokalt på serveren og det er den nye version af Mysql, der giver den længere svartid.

Kommentar til #1-#6:
I en meget stor del af den tid jeg har arbejdet med Mysql, har jeg anvendt Jeg har Jeg bruger de venstrelænede phpmyadmin. Jeg arbejder meget med tabel- og rækkenavne, som er forholdsvis låst pga. data kommer fra gamle systemer og man ikke ønsker at bruge ressourcer på at gennemgå alt kode og "død" dokumentation, for at ændre på disse navne. Det har derfor altid været en vane at bruge den form for gnyffer, så jeg dermed ikke behøvede forholde mig til om navnene kunne komme i konflikt med reserverede ord osv.
Avatar billede arne_v Ekspert
22. juni 2023 - 14:56 #8
Er alle 288 kald ligesom det viste SQL.

For det er altså et mysterie hvorfor den skulle være så langsom.

SELECT `file`, `child`
FROM `test_table`

er jo givet

WHERE `parent` = '01'

kunne være en dræber med 7 millioner rækker hvis der manglede index på parent feltet, men med kun 7 tusind rækker, så synes jeg ikke at der skulle kunne være noget.

Men for en god ordens skyld - er der index på parent?

ORDER BY `child_sort_order`

sortere 68 rækker bør heller ikke være noget problem - selv bobble sortering burde være god nok.

Viser EXPLAIN på den query på den gamle og den nye server nogen forskel?
Avatar billede AnyFellow Seniormester
22. juni 2023 - 15:37 #9
Jeg har rodet med det hele dagen.

En sletning af index på parent og tilføjelse af dette igen har løst problemet.

Der må være gået et eller andet galt under import, selvom jeg synes det lyder underligt.
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester