Avatar billede lone_a_p Praktikant
23. maj 2011 - 19:53 Der er 15 kommentarer og
1 løsning

Brug af index i to forskellige tabeller

Jeg har en query:

SELECT threadid, title, text, userid, datetime, user.username, age, oprettet, access, sex, public, postcount
FROM forumpost, user WHERE user.id = userid AND threadid = 43683 ORDER BY datetime ASC

Det er fra mit forum, hvor jeg både henter tråden samt oplysninger fra brugerne som har postet i tråden.

Men ved brug af explain får jeg følgende oplysninger:
forumpost, rows: 81
user, rows: 1
Dvs. en join size på 81 i alt.

Men ved brug af jet profiler for mysql får denne sql følgende stempel:
join size 81 (fair) 2 røde prikker
using filesort (bad)

Jeg kan ikke se, at ovenstående kan optimeres yderligere? Jeg har mange sql-statements der rangeres som bad og very bad, er dette normalt?
Avatar billede arne_v Ekspert
24. maj 2011 - 01:39 #1
SELECT threadid, title, text, userid, datetime, user.username, age, oprettet, access, sex, public, postcount
FROM forumpost, user WHERE user.id = userid AND threadid = 43683 ORDER BY datetime ASC

tilsiger at du skal have index paa:

user.id
forumpost.userid
forumpost.threadid
forumpost.datetime
Avatar billede arne_v Ekspert
24. maj 2011 - 01:40 #2
Et produkt som forsoeger at vurdere en querys effektivitet paa 81 raekker er lige til skraldespanden.
Avatar billede arne_v Ekspert
24. maj 2011 - 01:40 #3
Hvordan kan du have et felt med navn DATETIME uden at putte `` omkring det?
Avatar billede lone_a_p Praktikant
24. maj 2011 - 07:13 #4
datetime er navnet på kolonnen, så det virker fint? Jeg putter kun " på hvis det er fx "2011-04-31". Er det der den går galt?
Avatar billede lone_a_p Praktikant
24. maj 2011 - 07:15 #5
Altså selvom den kigger 81 rækker igennem, så kan den godt returnere row 1 i explain?

Det er jeg lidt i tvivl om, men det må den kunne?

Dvs. 81 rækker er altid til skraldespanden - ingen undtagelse?
Avatar billede arne_v Ekspert
24. maj 2011 - 15:07 #6
Du putter '' (lodrette dapper) omkring strenge.

Du putter `` (venstrhaeldende dapper) omkring navne som er reserveret i MySQL.
Avatar billede arne_v Ekspert
24. maj 2011 - 15:10 #7
Det er umuligt at maale performance paa 81 raekker (med normal raekke laengde).

Formentligt vil 81000 raekker ogsaa vaere nemme at faa til at performe.

Ved 81 millioner raekker begynder det at blive interessant.
Avatar billede lone_a_p Praktikant
24. maj 2011 - 15:26 #8
Der er ikke kun 81 rækker i mine tabeller. Jeg trækker ud fra tabeller med millioner af rækker.

I dette eksempel handler det om titusinder af rækker, hvor jeg får at vide at join size er 81 i alt. Altså rows = 81 ud fra min explain select.

Jeg synes det er nemmest at forklare med et mere simpelt eksempel ... samt forstå svar.

Mit spørgsmål er om en join-size på 81 kan være optimal, eller om den helt sikkert kan blive bedre.

Så forstår jeg ikke din kommentar om "skraldespanden"?
Avatar billede arne_v Ekspert
24. maj 2011 - 15:39 #9
jeg har lidt svaert ved at foelge dig

er de 81 raekker antal raekker i output?
Avatar billede lone_a_p Praktikant
24. maj 2011 - 15:50 #10
når jeg benytter "explain select ... " får jeg en tabel over brug af indexes.

Heri er der én kolonne der hedder "ROWS". Der står 1 ved det ene tabelnavn og 81 ved det andet tabelnavn i denne værdi.

Jet Profiler for Mysql fortæller mig så, at jeg har en join size på 81.

Mit spørgsmål er om de 81 muligvis er optimal for min table. Men jeg tror selv, at jeg har fundet ud af, at det er den optimale select.

Jeg er ved at kigge mine tabeller igennem, da min database performer dårligt, og jeg søger lidt i blinde pt. Måske derfor mit spørgsmål er uklart.
Avatar billede arne_v Ekspert
24. maj 2011 - 16:12 #11
hvor mange raekker er der i output?
Avatar billede lone_a_p Praktikant
04. juni 2011 - 21:40 #12
Hvis der er 81, er det så optimalt?
Avatar billede lone_a_p Praktikant
04. juni 2011 - 21:43 #13
Man kan lave sådan nogle sammensatte indexeringer (kender ikke den korrekte faglige term) - jeg går ud fra, at det er det korrekte at bruge i stedet for at indexere enkeltvis?

Bare lige for at være sikker :)
Avatar billede arne_v Ekspert
05. juni 2011 - 00:39 #14
Hvis queryen returnerer 81 raekker saa vil der noedvendigvis paa et tidspunkt i udfoerslen optrade 81 raekker.
Avatar billede arne_v Ekspert
25. juni 2011 - 04:12 #15
all set?
Avatar billede lone_a_p Praktikant
09. juli 2011 - 18:24 #16
ja, jeg tror det er den optimale løsning :)
Avatar billede Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester