7 miljoen rows in mysql

hoe tel je?

SELECT * FROM tabel
en dan met num_rows() ?

of

SELECT COUNT(1) AS aantal FROM tabel

?

En hoe steken je indices en queries in elkaar? Met een goede opzet moet 7 miljoen geen probleem zijn voor MySQL/MariaDB.

select met count geeft resultaat, mar erg lang.

Daarnaast gewoon een select * from tabel, duurt eeuwen zelfs in de cli.

De internetverbinding is waar ik nu be wel erg langzaam, maar goed zo lang hoeft het ook weer niet te duren.



[size=xsmall]Toevoeging op 12/06/2019 04:47:12:[/size]

ook gewoon gaan naar www.domein.nl/phpmyadmin laad uren, gebeurd niks. En niks staat in de wachtrij met mysql queries

daarnast gewoon een create index op deze tabel komt geen einde aan. Snap niet waarom, ook geen foutmeldingen. Hoe debug ik dit?

Stel je bent vakkenvuller bij de AH.
De vraag van je chef is: hoeveel cola ligt er in de winkel?

optie 1: haal alle flessen op de 2 pallets naar kantoor en tel daar hoeveel het er waren. En doe vervolgens niets met de flessen in kwestie.

optie 2: loop de winkel in, tel de flessen en loop met het papiertje met 114 erop terug naar kantoor.

Dit is te vergelijken met SELECT * en met SELECT COUNT()

Als je alleen maar wilt tellen, dan is SELECT COUNT() de manier.
Zit er nog een WHERE aan die query?

Puur SELECT COUNT(1) FROM tabelnaam zou eventueel enkele seconden mogen duren, maar niet meer dan dat.
Heb het net getest met enkele tabellen met tussen 3.4 en 5 miljoen records: circa 2 tellen met een uitschieter naar 8.

En afhankelijk van je MySQL client API kan dit ook nog allerlei consequenties hebben voor geheugengebruik. Ik kan mij zo voorstellen dat als je heel erg inefficiënte of gewoon lompe queries uitvoert dat zowel de MySQL- alsook de PHP-kant tegen limieten aan beginnen te hikken. Informatie over MySQL kun je opvragen via phpinfo() onder het kopje mysql(i).

Als de client afwijkt van "mysqlnd" (de MySQL native driver) dan zou je eens bij je webboer kunnen informeren waarom er bewust daarvoor gekozen is, want volgens mij is mysqlnd min of meer de standaard tegenwoordig.

Ik krijg bij phpmyadmin:

Gateway Timeout
The gateway did not receive a timely response from the upstream server or application.

verder er worden dus verder geen queries uitgevoerd, maar alleen bij het laden krijg ik dit al.
Dus het heeft niets met de queries te maken.

Als ik truncate table GROTE_TABEL doe, dan duurt het jaren, lijkt mij gewoon dat mysq dit niet aankan

Wat is de query die je uitvoert?

Zit daar nog een WHERE-stuk bij?

of puur SELECT Count(1) FROM tabel?

Daniel van Seggelen op 13/06/2019 10:04:28

Als ik truncate table GROTE_TABEL doe, dan duurt het jaren, lijkt mij gewoon dat mysq dit niet aankan

Als ik zo hoor heb ik eerder het idee dat je MySQL moet tunen.

Ik neem aan dat je een eigen server hebt?
Kijk eens hier naar? Dit geeft een analyse (en fixt niks).
https://github.com/major/MySQLTuner-perl/blob/master/README.md

Ook wordt hier weer een probleem geconstateerd aan het eindpunt. Een timeout is het eindresultaat van alles wat ervoor gebeurde. Vraag is dus, wat ging hier allemaal aan vooraf. Het kan inderdaad liggen aan configuratie. Het kan natuurlijk ook gewoon dat je tabel of query inefficiënt is, of dat beide gewoon brak zijn.

Daarnaast: wat probeer je precies te bereiken?

Maar tevens: hoe luidt het gedrag van de data. Je hebt het nu alleen over een "grote tabel X", dat zegt ons niet zoveel. Wat zit hierin? Welke indexen staan hierop? Welke queries voer je hier allemaal op uit, en hoe vaak? Hoe verandert de tabel over tijd? Komen hier nog veel meer records bij? Verdwijnt er ooit iets uit de tabel? Wat is de functie van deze tabel? Hoe vaak wordt deze gemiddeld geraadpleegd? Heb je deze tabel echt nodig? Kun je deze mogelijk splitsen? Of een groot deel archiveren omdat deze toch nooit opgevraagd wordt? Is alle data die hierin zit echt relevant?

Even een update met
"truncate table GROTE_TABEL" in cli doe dan heeft dat 6 uren en 44 min en 14.12 seconde geduurd.

Daarna kom ik gewoon weer in phpmyadmin.

Dit is het tabel:

https://www.globalwebdevelopment.net/tttabel.png


Dit zijn de indexen voor het tabel

https://www.globalwebdevelopment.net/index.png

"Een timeout is het eindresultaat van alles wat ervoor gebeurde. Vraag is dus, wat ging hier allemaal aan vooraf"

Daarvoor heb ik dus via csv feeds met "load data infile" alle data in de tabel geplaatst.
Geen fouten t/, ruim 6.3 miljoen rijen.
Ja ik heb een eigen vps centos 7

De configuratie kan ik wel blijven tunen, maar weet iemand aan de hand van deze tabel informatie toevallig wat er fout kan zijn?


Daarnaast heb ik ook een standaard mysql configuratie voor mariaDB