[MySQL] aantal gescande rows bepalen

[Verwijderd]

af en toe komt er eens een slow query log voorbij waarin het aantal gescande rows voorbij komt. nu probeer ik zonder het slow query log op een andere query ook het aantal gescande rows te bepalen. nu is mijn vraag: hoe doe ik dat?

er staat wel een kolom rows in de explain, maar die colom is per table erg laag. (rond de 100 voor sommige, de rest op 1 of 2) terwijl de slow query log van die zelde query rond de 200.000 zat. wanneer ik ze (op aanraden van een collega) met elkaar vermenigvuldig, kom ik uit op ongeveer 10 miljoen.

kan ik met behulp van die explain of een andere methode die scanned rows bepalen? mijn baas ziet dat graag in het verslagje

[Voutloos]

Verwijderd schreef op donderdag 03 april 2008 @ 09:27:
wanneer ik ze (op aanraden van een collega) met elkaar vermenigvuldig, kom ik uit op ongeveer 10 miljoen.

Als het niet allemaal cartesische producten zijn, moet je ook niet alles vermenigvuldigen.

Verder is het wel handig om te kijken naar de hoeveelheid rijen zonder limit (indien query met limit is ), maar misschien wel de belangrijkste kolom van explain is de kolom 'extra'. In menig tutorial kan je vinden welke opmerkingen je daar graag wel en niet tegen wil komen. Vb: filesort is doorgaans niet leuk als je veel rijen moet sorteren.

[Verwijderd]

Kan het hiermee? http://dev.mysql.com/tech...g-new-query-profiler.html

[EfBe]

een table scan wordt uitgevoerd wanneer er geen index op een field is gevonden. Een join tussen twee tables over indexed fields zijn geen scanned rows. Maar wanneer jij 3 predicates in je where clause hebt staan met daarin fields zonder index, dan krijg je voor iedere predicate een table scan voor je kiezen.

[Verwijderd]

bedankt voor de racties, helaas ondersteund onze mysql server nog geen profiling. dus die optie komt helaas te vervallen.

het zoeken naar mogelijke indices om het te versnellen is ook al grotendeels gedaan, het gaan dan ook niet echt om optimalisatie in dit geval. ik zoek nu echt een manier om dat getalletje, die scanned rows, te bepalen.

@voutloos, kan je mij zeggen hoe ik in die explain bepaal of het wel of niet allemaal cartesische producten zijn? en misschien ook hoe het anders uitgerekend kan worden als het niet allemaal cartesische producten zijn.

hierbij even een iets ingekorte explain. gewoon vermenigvuldigen geeft mij 4.327.680 scanned rows. een vergelijkbare query leverde laatst een slow query log op met daarin slechts 23.000 rows. terwijl de explain bijna gelijk was (kwam ik ook in de 10 mil uit bij vermenigvuldigen)

code:

id  select_type type    rows    Extra   
1   PRIMARY ref 5   Using where; Using filesort 
1   PRIMARY ref 1   Using where 
1   PRIMARY ref 1   Using where 
1   PRIMARY eq_ref  1   Using where 
1   PRIMARY eq_ref  1       
1   PRIMARY eq_ref  1   Using where 
1   PRIMARY eq_ref  1       
1   PRIMARY eq_ref  1       
1   PRIMARY eq_ref  1       
1   PRIMARY ref 1   Using where 
11  DEPENDENT SUBQUERY  ref 1   Using where; Using index; Using filesort    
11  DEPENDENT SUBQUERY  ref 3   Using where; Using index    
11  DEPENDENT SUBQUERY  eq_ref  1   Using where 
10  DEPENDENT SUBQUERY  ref 1   Using where 
10  DEPENDENT SUBQUERY  eq_ref  1       
10  DEPENDENT SUBQUERY  ref 1   Using where; Using index    
9   DEPENDENT SUBQUERY  ref 1   Using where 
9   DEPENDENT SUBQUERY  eq_ref  1       
9   DEPENDENT SUBQUERY  ref 1   Using where; Using index    
8   SUBQUERY    ALL 98  Using where 
8   SUBQUERY    ref 23  Using where 
7   DEPENDENT SUBQUERY  ref 2   Using where 
7   DEPENDENT SUBQUERY  eq_ref  1   Using where 
7   DEPENDENT SUBQUERY  eq_ref  1   Using where 
6   DEPENDENT SUBQUERY  ref 2   Using where 
6   DEPENDENT SUBQUERY  eq_ref  1   Using where 
6   DEPENDENT SUBQUERY  ref 2   Using where 
5   DEPENDENT SUBQUERY  ref 2   Using where 
5   DEPENDENT SUBQUERY  eq_ref  1   Using where 
5   DEPENDENT SUBQUERY  eq_ref  1   Using where 
5   DEPENDENT SUBQUERY  eq_ref  1   Using where; Using index    
4   DEPENDENT SUBQUERY  ref 2   Using where 
4   DEPENDENT SUBQUERY  eq_ref  1   Using where 
4   DEPENDENT SUBQUERY  eq_ref  1   Using index 
4   DEPENDENT SUBQUERY  ref 2   Using where 
3   DEPENDENT SUBQUERY  ref 1   Using index 
3   DEPENDENT SUBQUERY  eq_ref  1       
2   DEPENDENT SUBQUERY  ref 2   Using where