[MySQL] zoekoptimalisatie

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • ZeroXT
  • Registratie: December 2007
  • Laatst online: 16-10 18:13
Beste mensen,

Is het voor MySQL (InnoDB) belangrijk in welke volgorde de "where" clausule geschreven wordt?

Ik heb namelijk een productentabel waarin gezocht kan worden. Aangezien er meerdere titels voor kunnen komen voor elke leverancier_id in mijn productentabel, is het wellicht relevant om eerst te filteren op de leverancier_id en dan pas te filteren op de titel van een product:

SQL:
1
2
3
SELECT product_titel
FROM product
WHERE product_leverancier_id = 1 AND product_titel LIKE %titel%;


Of zou deze statement net zo snel zijn:
SQL:
1
2
3
SELECT product_titel
FROM product
WHERE product_titel LIKE %titel% AND product_leverancier_id = 1;

Acties:
  • 0 Henk 'm!

  • C0rnelis
  • Registratie: Juni 2010
  • Laatst online: 26-08 22:21
Je kunt sowieso altijd de queries uitvoeren met 'EXPLAIN' ervoor. MySQL laat dan goed zien wat MySQL daadwerkelijk van plan is. Als de output hetzelfde is, maakt de volgorde in dit geval niet uit.

Acties:
  • 0 Henk 'm!

  • M-ThijZ
  • Registratie: Maart 2003
  • Nu online

M-ThijZ

Riding on Rails

Ik zou eerder een alternatief voor je
code:
1
LIKE '%titel%'
clausule zoeken, want dat is een drama voor je performance.

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Ik zou eens beginnen met een index op leverancier_id en dan 't executionplan dat MySql verzint bekijken (met de eerder aangehaalde Explain) ;)

Like '%foo% is nooit zelden een goed plan; misschien dat je ook eens moet kijken naar FTS.

[ Voor 71% gewijzigd door RobIII op 28-01-2015 22:33 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 09-09 13:58

NMe

Quia Ego Sic Dico.

De enige momenten waarop de volgorde uit zou kunnen maken is als je meerdere indices op een tabel hebt en je daarop wil filteren. Zo uit het hoofd kan MySQL maar één index per gejoinde tabel gebruiken dus daar zou in theorie de volgorde kunnen bepalen wélke index gebruikt wordt. Maar ook dat zie je direct als je beide varianten door een EXPLAIN gooit. :)

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


Acties:
  • 0 Henk 'm!

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Volgens mij is een explain echter niet een eeuwig definitief antwoord. Maar slechts de situatie zoals de query-optimalizer die op dat moment kan overzien.

In principe verwacht ik hierbij geen verrassingen, maar het was alleen een opmerking dat het met een volle query-cache een ander resultaat op kan leveren dan net na opstarten db-server etc.

Maar sowieso verwacht ik hier geen performance verschil in, of je moet een andere query hebben en deze enkel als voorbeeld bedoelen, maar in principe verwacht ik dat elke query-optimizer je query intern omschrijft naar de 1e variant want de kans dat een = sneller / minder resultaten teruggeeft dan een like '%' is ongeveer 100%.

Van een enkele like 'iets' (dus zonder wildcards) verwacht ik op zich nog dat een query-optimizer dat omschrijft naar een = variant.

Maar in wezen vind ik dit optimalisaties waarvan ik eigenlijk verwacht dat een volwassen RDBMS die gewoon afhandelt, maar als ik het toch echt zou willen weten dan is het devies : "Meten is weten"
Menig query-optimizer is tegenwoordig zo ingewikkeld dat er geen lijn meer op te trekken valt zonder de daadwerkelijke query en de daadwerkelijke data te kennen (als je bijv 200 miljoen records hebt en maar 2 product leveranciers die 50/50 leveren dan kan het weer best efficienter zijn om eerst de like uit te voeren dan om eerst de helft te pakken en daarop alsnog de like uit te voeren, maar met 100 records kan dat weer anders liggen, maar daarvoor bestaan statistics en die heeft de query-optimizer tot zijn beschikking en daar valt geen wet van meden en perzen op te trekken zonder de data te kennen)

Oftewel in het algemeen : Geen zorgen om maken maar pas naar kijken bij problemen
Bij eerste problemen : Explain erbij pakken en bekijken
Bij blijvende problemen : Meten is weten

En in dit specieke geval als 1e stap : Gewoon de like '%iets%' eruit proberen te werken want die blokkeert zo ongeveer elk index-gebruik en is daarmee per definitie een trage stap ongeacht of die nu voor of na je product_leverancier_id zit, de stap blijft traag.
Pagina: 1