WN - problem med Mysql Slow query

WN (https://www.wn.se/forum/index.php)

- Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)

- - problem med Mysql Slow query (https://www.wn.se/forum/showthread.php?t=1041594)

Saken är den att jag använder paging scriptet som finns på följande länk:
http://net.tutsplus.com/tutorials/ph...data-with-php/

nu verkar det som att den inte går att använda..

Clarence
kan ej spara antalet rader i en fil/tabell då jag även har sökkriterier på sidan.. kanske blir enklast att bara köra med anrop:

count()...sök kriterier..

sen så kör jag samma anrop med:

sökkriterier.. order by ?

Kolla lite på SQL_CALC_FOUND_ROWS. Då kan du få fram totala antalet rader även om du använder LIMIT.

Tack för svar allihopa..

Jag har kommit fram till följande:

I och med att sidan kommer att visas beroende på sökkriterier och jag använder paging och behöver limit på detta så är den smidigaste lösningen

att t.ex. få följande mysql anrop rad

observera att detta bara är ett exempel på anrop, den är inkorrekt men vill bara visa hur jag skulle vilja ha det.

Kod:

SELECT * FROM users t LEFT JOIN guestbook g ON g.uid=t.i WHERE bla bla bla GROUP BY bla bla ORDER BY id DESC LIMIT 0,25



till denna rad:



SELECT COUNT(*) FROM users t LEFT JOIN guestbook g ON g.uid=t.i WHERE bla bla bla

med andra ord vill jag ersätta allt som finns mellan SELECT och FROM med COUNT(*) samt att jag vill få bort group by, order by samt limit..

Om jag inte har fel så kan man fixa detta med reguljära uttryck, är bara n00b på detta.. har kommit så här långt:

Kod:

        $search_sql = "SELECT * FROM users t LEFT JOIN guestbook g ON g.uid=t.i WHERE bla bla bla GROUP BY bla bla ORDER BY id DESC LIMIT 0,25";

        $reg_expr = '/SELECT * FROM$/';

        

        $rep_with = ' COUNT(*) ';

        $count_sql = preg_replace($reg_expr, $rep_with, $search_sql);

någon som har en lösning?

varför krångla till det med ett regex? om du vet tabellens namn så ser jag ingen anledning att krångla med regex.

SQL " ORDER BY " åsidosätter användning av INDEX.

Därför kommer frågan att klassas som SLOW QUERY när du använder det.

Fabians " SELECT count(<fältnamn>) ..." är ett bättre alternativ eftersom den kommer att använda INDEX.

Citat:

Ursprungligen postat av Jonas (Inlägg 20351830)

Nej, det beror på WHERE-satsen, joins, sorteringsordningen (ASC/DESC) osv. Endast ett index används, men kan användas för både sortering och villkor. Se http://dev.mysql.com/doc/refman/5.0/...imization.html för detaljer för första biten.

En liten detalj är också att COUNT(fältnamn) räknar icke-null värden på fältet. COUNT(*) däremot räknar antalet rader.

Dock bör man om man använder innodb använda räknare så långt som möjligt - med ett gäng miljoner rader kan en COUNT(*) lätt ta flera minuter (och i bästa fall hamna i query cache en liten liten stund innan en ny insert görs). Eftersom frågan verkar kunna ställas utan WHERE-sats bör man ha en räknare för antalet rader. Sen åsidosätter man den med en COUNT(*) för ovanliga queries (ofta allt utom just den utan villkor).

Hej och tack för alla svar.. Nu har jag åtgärdat problemet med en COUNT(*), sen så kör jag med en vanlig SELECT-sats för att hämta ut data från mysql.

Nu har jag dock ett annat litet mindre problem med mysql slow queries.
Följande rad hamnar i mysql slow queries filen, här kan man ju inte köra en explain så jag förstår inte riktigt varför det blir så.

Kod:

UPDATE apps SET downloads = downloads+1 WHERE id = "ettid" ;

Jag har satt ID som en primär nyckel, förstår inte att det kan hamna under mysql slow queries? Någon som har tips på vad detta kan bero på?

Kod:

UPDATE apps SET downloads = downloads+1 WHERE id = "ettid" ;

Jag har satt ID som en primär nyckel, förstår inte att det kan hamna under mysql slow queries? Någon som har tips på vad detta kan bero på?

är id en sträng, eller bara ett konstigt exempel (syftar på "ettid") ?

Citat:

Ursprungligen postat av Jonas (Inlägg 20351830)

Grattis, 3 av 3 fel. Folk som bara gissar borde verkligen inte uttala sig.

zilveer, det blir enklare att se vad som är fel om du postar en DESCRIBE på tabellen så att vi ser att du faktiskt har id som primary key och inte förvirrat till det för dig själv.