[PHP] snelheid query

[Verwijderd]

Ik doe een simpel select query op een database met meer dan 50.000 velden, deze query doet er errug lang over dus het duurt ook lang voor de site klaar is met laden, weet iemand mischien een manier waarop dit sneller kan?

bvd

[Verwijderd]

Dan moet je indexen gaan aanmaken, op sitepoint.com is daar wel ergens een artikel over te vinden.

Verder hoort dit in P&W volgens mij.

[MikeN]

Indexen op kolommen zetten....

[edit]Trage k*t schoolnetwerk ook....

[ACM]

Lijkt me een P&W vraagje, wat voor queries zijn het?

Op wat voor database?

[dmnq]

Je kan er natuurlijk ook voor kiezen om je queries op vaste intervallen te cachen...

[Nielsz]

Yeah, dit zijn de interesante topics!
Ik wil hier ook nog wat dingen over weten,
heeft iemand een richtlijn of een tutorial over wanneer je een colom op index moet zetten?

Want ik zet nu in principe wat dingen random op 'index' ("Mwah, userid word wel veel gebruikt, *pats*, username ook wel, *pats* ")

[dmnq]

Op woensdag 03 oktober 2001 09:07 schreef dmnq het volgende:
Je kan er natuurlijk ook voor kiezen om je queries op vaste intervallen te cachen...

Doet tweakers ook met UpdateTracker toch?

[Janoz]

Op woensdag 03 oktober 2001 08:47 schreef N-ZA het volgende:
Ik doe een simpel select query op een database met meer dan 50.000 velden, deze query doet er errug lang over dus het duurt ook lang voor de site klaar is met laden, weet iemand mischien een manier waarop dit sneller kan?

bvd

Als je alle 50.000 records op gaat halen duurt het idd wel lang. Maar als je slechts 1 of enkele records eruit wil pikken zou het kunnen wijzen op:
1. slecht geformuleerde query
2. slecht db-model (ontwerp en/of implementatie)

Maarja .. Zoals eerder ook al gezegd is, zonder wat source kunnen we er hier verder ook niks mee.


Nielz >>

Zegt 'Orde' je iets met betrekking tot algoritme efficientie? Dan kan ik daar wel ff een verhaaltje over ophangen

[Nielsz]

Janos >> Weinig, maar als je het me verteld dan zeg ik vast van 'Ja!'
De huidige methode die ik gebruik bij mijn forum = index gebruiken wanneer data veel wordt opgevraagd maar waar de tabel weinig wordt veranderd;


table posts: niet
table topics: topicid,forumid,userid,title
table forums: alles.
table users: userid, username, pass,signature,icon,title

[bakkerl]

Op woensdag 03 oktober 2001 09:13 schreef Nielsz het volgende:
Yeah, dit zijn de interesante topics!
Ik wil hier ook nog wat dingen over weten,
heeft iemand een richtlijn of een tutorial over wanneer je een colom op index moet zetten?

Algemeen Advies, overal waar je op selecteerd en/of sorteerd, index op aan maken. Een index kost voornamelijk extra diskruimte om die gegevens op te slaan.
Bij kolommen waar je veel in muteerd kan het zijn dat het iets (niet merkbaar) trager wordt.

[ACM]

Op woensdag 03 oktober 2001 09:53 schreef bakkerl het volgende:
Bij kolommen waar je veel in muteerd kan het zijn dat het iets (niet merkbaar) trager wordt.

Tsja, ik denk dat dat afhangt van de queries en database enzo.

Een van de redenen waarom we denken dat GoT zo traag is, is dat er vrij veel table-locks zijn, die dus de andere clients blokkeren en daardoor ook de apache-clients.

Aantal clients loopt naar max -> load naar 100...
En got is niet meer te gebruiken.


Dus dat 'niet merkbaar' hangt *kuch* nogal van de situatie af. Waarschijnlijk heeft het in dit geval weinig met indexing te maken (alhoewel al die inserts wel een stukje slomer zijn en daardoor nog iets langer de boel blokken). Maar iets waarvan je denkt dat het weinig uitmaakt kan soms erg veel uitmaken.

Wat erg nuttig is, is je queries door een of andere query analyzer (EXPLAIN query... in postgres geeft een best aardig overzicht) waardoor je kan zien of bij een bepaalde query je index wel gebruikt wordt (ook bij updates en zelfs bij inserts kunnen indices nuttig zijn).

[dusty]

Op woensdag 03 oktober 2001 09:13 schreef Nielsz het volgende:
("Mwah, userid word wel veel gebruikt, *pats*, username ook wel, *pats* ")

Volgens mij zoek jij niet zovaak een bepaalde usernaam op dus een index erop heeft weinig nut. Probeer een index op de velden te zetten waarop je vaak zoekt. (zal dus vooral de ID's zijn inderdaad..)

[Verwijderd]

en waar kan ik makkelijk informatie vergaren over indezering in postgresql??

[Nielsz]

Niet zo heel erg veel nee, maar ik wil die wel kunnen selecten (select username). Maar indexes moet je dus plaatsen als je er op selecteerd oid?

[dusty]

Op woensdag 03 oktober 2001 10:50 schreef Nielsz het volgende:
Niet zo heel erg veel nee, maar ik wil die wel kunnen selecten (select username). Maar indexes moet je dus plaatsen als je er op selecteerd oid?

Yup en dan de afweging maken of het heel vaak wordt geselecteerd of "zelden" zoals inloggen heb je de gebruikers naam nodig.. en wachtwoord, echter dat wordt zelden gedaan. Dus is het niet de moeite waard om daar een index op te zetten, immers moet de database dan die index ook bijhouden e.d. en dat kost o.a. ook weer tijd bij een insert of update.

[ACM]

Op woensdag 03 oktober 2001 10:47 schreef N-ZA het volgende:
en waar kan ik makkelijk informatie vergaren over indezering in postgresql??

In principe gelden daar dezelfde regels voor, als voor elke ('sql') DB

Maar bij bijv postgresql kan je dan als je eenmaal een index gemaakt hebt (zie de manual van postgres voor indices) met EXPLAIN je query bekijken of ie wel gebruikt maakt van de index.

[Killemov]

Op woensdag 03 oktober 2001 08:47 schreef N-ZA het volgende:
Ik doe een simpel select query op een database met meer dan 50.000 velden, deze query doet er errug lang over dus het duurt ook lang voor de site klaar is met laden, weet iemand mischien een manier waarop dit sneller kan?

bvd

50.000 velden => 50.000 kolommen in X tabellen, das errug fors
50.000 velden => 5.000 rows in X kolommen in Y tabellen, das peanuts

Maar goed, de grootste snelheid haal je altijd door je query zo specifiek mogelijk te maken. Selecteer alleen de velden die je echt nodig hebt ipv *, neem zoveel mogelijk where-clauses op (where id = ... of datum = ...), als je de db zelf ontwerpt: ga niet overboard met normaliseren.

[Verwijderd]

Op woensdag 03 oktober 2001 11:14 schreef ACM het volgende:

[..]

In principe gelden daar dezelfde regels voor, als voor elke ('sql') DB

Maar bij bijv postgresql kan je dan als je eenmaal een index gemaakt hebt (zie de manual van postgres voor indices) met EXPLAIN je query bekijken of ie wel gebruikt maakt van de index.

euhm ik kan me herinneren dat dat met MySQL ook zo is

[ACM]

Op woensdag 03 oktober 2001 11:46 schreef woeitje het volgende:
euhm ik kan me herinneren dat dat met MySQL ook zo is

Ik zeg toch ook niet dat mysql het niet heeft?

Overigens vond ik de output van postgresql wel duidelijker dan die van mysql.