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

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.

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 ^

#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.

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.

Hmmm. Strengt taget er det vel iøvrigt venstrehældende gnyffer. Jeg er træt idag.

takker for info - det er da også lettere at skrive `file` i stedet for at navngive det fil

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.

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?

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.