[MySQL] SELECT COUNT verschil vraag.

[Gigazone]

Hallo,

Ik ben bezig met het schrijven van een CSV import script om op die manier PHP/MySQL te leren.

Ik lees automatisch 6 bestanden in van ieder 25k regels in de tabel 'products'.

Nu zie ik in phpmyadmin voor de tabel products ~159,533 rijen, wat vreemd is aangezien 5x25k 150k is. Na een beetje Googlen kwam ik erachter dat de tilde (~) , circa betekent. Dus okay, het is ruwweg dat aantal rijen give or take een percentage.

Maar ik wilde graag weten hoeveel rijen er nu daadwerkelijk zijn ingelezen. dus kwam ik met een COUNT op de proppen.

code:

SELECT COUNT(*) from products

resultaat: 159,533, hmm, vreemd aangezien ik maar 150k regels heb ingelezen.
zouden er dan dubbele zijn? Toch eens kijken of er dubbele EAN in de tabel staan.

code:

SELECT EAN FROM product_prices GROUP BY EAN HAVING COUNT(*)  > 1

Resultaat = 0
raar, hoeveel unieke EAN staan er dan in?

code:

SELECT EAN FROM product_prices GROUP BY EAN HAVING COUNT(*)  = 1

Resultaat = 150,000

wel verhipt, maar de count gaf toch iets anders aan? Nog maar een keer dan

code:

SELECT COUNT(*) from products

resultaat = 150,000

Nu breekt mijn spreekwoordelijke klomp!
Nog even iets anders proberen dan maar

code:

SELECT * from products

Resultaat: "Showing rows 0 - 24 (150093 total, Query took 0.0020 seconds.)"


Nou snap ik er dus helemaal niets meer van. Moet ik na het inlezen een reindex initieren om een juist aantal rijen te krijgen in een count?

En waarom zijn er verschillen tussen " SELECT * from products" en "SELECT COUNT(*) from products" ?

[MAX3400]

Misschien even een andersommetje; puur ter jouwer controle: wat nu als je alle produkten weer dumpt naar een CSV, deze inleest in een applicatie als Excel en dan daar een "de-duplicatie" uitzoekt?

Uit mijn hoofd; select * leest alle rows uit ongeacht of / wat ingevuld is (bij een gebrekkige import kan je dus ook empty rows importeren). Je zou natuurlijk ook een extra statement kunnen toevoegen in je query zoals controle of kolom 2 en kolom 5 beiden een waarde bevatten (waarvan jij zeker weet dat die er moet zijn).

Ondanks de ~ vind ik het een best groot verschil dat je 150K rows of 160K rows ziet; dat is bijna 6% meer.

[Kaaswagen]

Misschien dat dit artikel wat helderheid brengt?

Wat geeft

MySQL:

SELECT category,COUNT(DISTINCT(EAN)) FROM products
GROUP BY category; 

? (aangenomen dat je iets als category hebt)

[Wolfboy]

Gigazone schreef op dinsdag 7 mei 2019 @ 16:59:
Nou snap ik er dus helemaal niets meer van. Moet ik na het inlezen een reindex initieren om een juist aantal rijen te krijgen in een count?

MySQL heeft een cache zitten op:

SQL:

SELECT COUNT(*)
FROM table

Als je daar omheen wil werken dan kan je gewoon een conditie erbij zetten die altijd waar is. Bijvoorbeeld iets als dit:

SQL:

SELECT COUNT(*)
FROM table
WHERE id > 0

Of de niet-standaard MySQL only optie:

SQL:

SELECT SQL_NO_CACHE COUNT(*)
FROM table

Mocht je correcte resultaten willen dan zou ik je aanraden om PostgreSQL eens te proberen
Daarbij hoef je je geen zorgen te maken om vreemde resultaten door caching. Mocht je query fout zijn dan krijg je gewoon een foutmelding in plaats van een approximatie wat niet altijd klopt. Mocht je data fout zijn dan kan je het er gewoon niet in zetten

[ Voor 5% gewijzigd door Wolfboy op 07-05-2019 17:58 ]

[Gigazone]

Bedankt allemaal, hier kan ik wat mee. En weer iets nieuws geleerd vandaag!

MAX3400 schreef op dinsdag 7 mei 2019 @ 17:10:

Ondanks de ~ vind ik het een best groot verschil dat je 150K rows of 160K rows ziet; dat is bijna 6% meer.

Ik heb gelezen (niet mijn woorden) dat er wel een verschil kan zitten van 40~50%. Een beetje een overheids database dus… : Tsja, we denken dat het 500 miljoen is, maar het kan ook 1 miljard worden