Avatar billede mtrolle Nybegynder
20. juni 2007 - 10:35 Der er 9 kommentarer og
1 løsning

Hvor mange rækker er feltet x = 10 inden for de sidste 100 rækker

Hej

Jeg har en tabel der ser således ud:

CREATE TABLE `percentage` (
`id` int(11) NOT NULL auto_increment,
`time` int(11) NOT NULL default '0',
`campaign` int(11) NOT NULL default '0',
PRIMARY KEY (`id`)
)

`time` indeholder et unix timestamp
Således kan jeg få de 100 nyeste rækker således:
SELECT * FROM `percentage` ORDER BY `time` DESC LIMIT 100

Jeg ønsker nu at kunne tælle, hvor mange af de sidste 100 rækker, hvor `campaign`=1 fx

Altså noget lign: (bare noget opfunden mysql ;)
SELECT COUNT(`campaign`=1) FROM `percentage` ORDER BY `time` DESC LIMIT 100

Altså i de sidste 100 rækker, hvor mange af dem er campaign sat til 1.

//mtrolle
Avatar billede barklund Nybegynder
20. juni 2007 - 10:38 #1
Hvilken MySQL-version? Specifikt, er den version 4.1 eller nyere?
Avatar billede arne_v Ekspert
20. juni 2007 - 10:41 #2
proev:

SELECT COUNT(*) FROM (SELECT * FROM percentage ORDER BY time DESC LIMIT 100
) x WHERE campaign=1
Avatar billede mtrolle Nybegynder
20. juni 2007 - 10:49 #3
Kører 4.1.19

>arne_v
Er dit x med vilje? Så laver den en tabel ud fra forespørgelsen som den så laver forespørgelsen count(*) i? korrekt?
Avatar billede arne_v Ekspert
20. juni 2007 - 10:51 #4
ja ja ja (hvis det altsaa virker)
Avatar billede barklund Nybegynder
20. juni 2007 - 11:17 #5
Jeg ville hellere hive tidspunktet for den 100'nde sidste ud og tælle:

SELECT COUNT(*) FROM percentage WHERE campaign = 1 AND time >= (SELECT time FROM percentage ORDER BY time DESC LIMIT 1 OFFSET 100)

Men skal ikke lige kunne sige, hvad der er mest effektivt :)

Problemet med min er jo, at hvis der er mere end 1 række med samme timestamp, så går det galt. Og mon ikke mysql's optimizer kan gøre en god del ved arne_v's forslag? :)

--
Morten Barklund
Avatar billede mtrolle Nybegynder
20. juni 2007 - 15:21 #6
Jeg bruger Arnes, den virker mindst komplex. Smider du et svar.
Avatar billede arne_v Ekspert
20. juni 2007 - 15:32 #7
svar
Avatar billede arne_v Ekspert
20. juni 2007 - 15:33 #8
Jeg er ikke saa bekymret over peroformance ved den nestede query, fordi de 100
raekker kan sagtens vaere i memory.
Avatar billede mtrolle Nybegynder
20. juni 2007 - 15:48 #9
Problemet kommer når vi har 2000 tabeller som skal køre det samtidig - den mindste bedring i performence er en kæmpe forskel for mig.
Avatar billede arne_v Ekspert
23. juni 2007 - 20:04 #10
At hente 100 rækker fra den tabel fylder 1200 bytes + overhead. Det er ingenting.
Heller ikke selv om det skal gøres for 2000 ad gangen (og du kan ikke køre de
2000 parallelt anyway - medmindre du har en 100+ CPU box at køre det på).
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