Index_merge

Der kommer følgende frem i "extra"-feltet ved brug af explain:
using intersect(brugerid, dato)

Laver jeg til gengæld et kombineret index med både (brugerid, dato) så stiger rows i min explain select. (med using intersect gav det 1 row i alt fra en query på to tables, dvs. perfekt)

Det undrer mig meget at rows-tallet stiger! Det kan vel ikke andet end betyde en dårligere select? Jeg troede, at man kun kunne FORBEDRE ved at sætte et index på (mod en forøgelse af datastørrelse).

Men det har jeg netop erfaret ikke er korrekt.

Det har gjort mig total forvirret mht at benytte indexes? Hvordan ved jeg hvilke indexes jeg så skal bruge? Jeg modtager meget gerne forklaringer, links ... anything der kan hjælpe mig med at gøre performance bedre.

Håber på hjælp :)

Mvh Lone

Ét spørgsmål mere:

Bruges indexes kun på de where-statements der har en konstant?

Altså ikke på table1.row = table2.row ? (index kan ikke bruges??)

Men derimod table table1.row = 10 (her kan index bruges??)

index kan ogsaa bruges paa table1.row = table2.row

det er helt standard at have index paa felter man joiner paa (husk at primary key er et index)

http://dev.mysql.com/doc/refman/5.5/en/index-merge-optimization.html forklarer om index_merge

men det er godt nok ikke ligefrem letforstaaeligt

Jeps, jeg har læst på mysql.com :-/ Men forstod det ikke helt, så jeg skrev herind i stedet :)

Er der ikke nogle helt basale regler for at oprette index? Jeg troede jeg havde fulgt dem indtil nu, men når jeg benytter ovenstående index, og det forringer querien, så har jeg alligevel ikke forstået det.

Mvh Lone

Hvis du saetter index paa felter du bruger i ON og WHERE, saa gaar det ikke helt galt.

Skal du fintune skal du maale.

Som oftest er det bedst med lavt antal raekker i "mellem regningerne" i EXPLAIN, men er du i gang med at fintune vil jeg anbefale dig at maale.

Og det er rigtigt at principielt boer tilfoejelse af index enten goer det hurtigere eller lige saa hurtigt at lave en SELECT, men optimizere er ikke perfekt - de kan lade sig narre til at bruge et index, hvor det var bedre at lade vaere. Det er sjaeldent at det sker.

Tak for dit svar.

Du anbefaler mig at måle, men jeg ved ikke helt hvordan? Jeg har netop fået et tip om et program, som hedder "Jet profiler for mysql".

Det kan vise de mest langsomme queries, dem som bruger mest tid, de tabeller som er tungest og lignende.
Er det et sådan program du mener?

Jeg overvejer at købe licens til 2000 kr. for netop at kunne se de langsomme queries også, for der er selvfølgelig visse muligheder man ikke har uden licens.

Eller hvorledes kan man ellers måle de queries der bliver sendt til databasen? (mere end explain)

Tag tiden, udfoer tung query, tag tide, beregn forskellen mellem de to tider.

PS: bruger du den her http://dev.mysql.com/doc/refman/5.5/en/slow-query-log.html ?

Hej Arne,

Tak for forklaringerne + slow_query_log. Mine tests har vist, at det er fint, men jeg vil holde øje med det med mellemrum. Der er nogle queries der stikker ud i forhold til andre, så dem skal der især et øje på.

Vil du give et svar til point, så vil jeg lukke :)

svar

saa mangler du bar at acceptere svaret