ďťż
 
MySQL i indexy ďťż
 
MySQL i indexy
Zobacz wiadomości
 
Cytat
A gdyby tak się wedrzeć na umysłów górę, / Gdyby stanąć na ludzkich myśli piramidzie, / I przebić czołem przesądów chmurę, / I być najwyższą myślą wcieloną. . . Juliusz Słowacki, Kordian
Indeks BCB i MySQL subiekt gt fototapeta
 
  Witamy

MySQL i indexy



Johnny - 14-12-2006 16:08
MySQL i indexy
  Witam

Robie selecta po tabeli z tematami forum, ale nie uzywam where, tylko
zakres (LIMIT) od do i order po dacie watku:

SELECT TF.PRIORYTET,TF.IDTEMATU,TF.TEMAT,
TF.DATAGODZINA,TF.LICZBAWPISOW,TF.IDAUTORA
FROM FORUM_TEMATY TF
ORDER BY TF.PRIORYTET DESC,TF.DATAGODZINA DESC
LIMIT 0,32

Tabela MyISAM, mam indexy na polach datagodzina i priorytet, a plan
wychodzi taki:

select_tyle: SIMPLE
table TF
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 2465
Extra: Using filesort

i wlasnie dlaczego nie uzywa indexu i przewala zawsze 2465 wierszy, a nie
tylko 32? Czy musze zrobic jakies inne indexy?

pzdr
Johnny





Johnny - 14-12-2006 16:08

  Dnia Tue, 28 Nov 2006 18:29:53 +0100, Johnny napisa?(a):

> i wlasnie dlaczego nie uzywa indexu i przewala zawsze 2465 wierszy, a nie
> tylko 32? Czy musze zrobic jakies inne indexy?

Powoli dochodze do przykrej konkluzji, ze LIMIT x,y wymusza przegladanie
calego zbioru danych, gdyz de facto serwer nie wie, ktore to rekordy beda
na pozycji x nim ich wszystkich nie przemieli. Niech mnie ktos wyprowadzi z
tego przekonania, bo nic tylko sie chlastac :/

pzdr
Johnny




Johnny - 14-12-2006 16:08

  Dnia Tue, 28 Nov 2006 20:12:01 +0100, Johnny napisa?(a):

> Powoli dochodze do przykrej konkluzji, ze LIMIT x,y wymusza przegladanie
> calego zbioru danych, gdyz de facto serwer nie wie, ktore to rekordy beda
> na pozycji x nim ich wszystkich nie przemieli. Niech mnie ktos wyprowadzi z
> tego przekonania, bo nic tylko sie chlastac :/

A skoro tak jest to pytanie mam praktyczne:

czy w przypadku duzych tabel w zamian za LIMIT praktykuje sie dodanie
kolumny ID, ktora zawiera kolejne numery wierszy i potem uzywanie tej
kolumny z takim skutkiem jak LIMIT x,y czyli: WHERE ID>=X AND ID<X+Y?

pzdr
Johnny




Maciek Dobrzanski - 14-12-2006 16:08

  "Johnny" <moja_ocena@gazeta.pl> wrote in message
news:9lts04h6yn69.1txdeop7exut$.dlg@40tude.net...

> czy w przypadku duzych tabel w zamian za LIMIT praktykuje sie dodanie
> kolumny ID, ktora zawiera kolejne numery wierszy i potem uzywanie tej
> kolumny z takim skutkiem jak LIMIT x,y czyli: WHERE ID>=X AND ID<X+Y?

Nie, bo nie mia?o by to ?adnego sensu.

Maciek





Johnny - 14-12-2006 16:08

  Dnia Tue, 28 Nov 2006 20:28:32 +0100, Maciek Dobrzanski napisa?(a):

> Nie, bo nie mia?o by to ?adnego sensu.

A co ma sens, gdy tabele maja po kilkaset tysiecy, a klauzula LIMIT
100000,30 powoduje, ze serwer mieli te 100 tys rekordow?

Johnny




Johnny - 14-12-2006 16:08

  Dnia Tue, 28 Nov 2006 18:29:53 +0100, Johnny napisa?(a):

> i wlasnie dlaczego nie uzywa indexu i przewala zawsze 2465 wierszy, a nie
> tylko 32? Czy musze zrobic jakies inne indexy?

To juz zakrawa na paranoje, upraszczam zapytanie do:

SELECT * FROM FORUM_TEMATY TF
ORDER BY TF.DATAGODZINA
LIMIT 31,32

a on co prawda niby korzysta z indexu, ale nadal mieli te rekordy
key: DATAGODZINA
rows: 2465

Co jest grane?

pzdr
Johnny




Maciek Dobrzanski - 14-12-2006 16:08

  "Johnny" <moja_ocena@gazeta.pl> wrote in message
news:vcdfwlgctxtj.18ylkuryxu2fp.dlg@40tude.net...

> A co ma sens, gdy tabele maja po kilkaset tysiecy, a klauzula LIMIT
> 100000,30 powoduje, ze serwer mieli te 100 tys rekordow?

Co do powy?szego pytania to generalnie mo?na przyj??, ?e nale?y d??y? do
minimalizowania liczby rezultatów poprzez odfiltrowywanie ich tam, gdzie
jest to wydajne czyli wewn?trz WHERE. To si? zwykle da rozwi?za? odpowiednio
projektuj?c/modyfikuj?c baz? i/lub aplikacj?.

W Twoim konkretnym przypadku MySQL najpewniej nie korzysta z indeksów,
poniewa? za?o?one s? na pola priorytet i datagodzina niezale?nie zamiast na
par? (pariorytet,datagodzina). My?l?, ?e gdyby? zagl?dn?? do dokumentacji,
odpowied? odnalaz?by? ju? wczoraj.

Maciek




Johnny - 14-12-2006 16:08

  Dnia Wed, 29 Nov 2006 16:06:33 +0100, Maciek Dobrzanski napisa?(a):

> W Twoim konkretnym przypadku MySQL najpewniej nie korzysta z indeksów,
> poniewa? za?o?one s? na pola priorytet i datagodzina niezale?nie zamiast na
> par? (pariorytet,datagodzina).

Indeksy zakladalem cudaczne, ten o ktorym piszesz takze, probowalem
wymuszac (use index) uzycie indexu, wszystko jak piach w krew.
W innym poscie tego watku podalem banalny przyklad:

SELECT * FROM FORUM_TEMATY TF
ORDER BY TF.DATAGODZINA
LIMIT 31,32

i on co prawda niby korzysta z indexu, ale nadal mieli te rekordy:

key: DATAGODZINA
rows: 2465

To nie kwestia indexu chyba, to jakis inny myk, ktorego nie potrafie pojac.

>My?l?, ?e gdyby? zagl?dn?? do dokumentacji,
> odpowied? odnalaz?by? ju? wczoraj.

PDFa z dokumentacja, ktory ma 1800 stron mam otwartego od 48 godzin, szukam
rozwiazania problemu i nie moge znalezc nadal.

pzdr
Johnny




Johnny - 14-12-2006 16:08

  Dnia Wed, 29 Nov 2006 18:05:34 +0100, Johnny napisa?(a):

> wszystko jak piach w krew.

oczywiscie mialo byc "jak krew w piach" ;-)

Johnny




Maciek Dobrzanski - 14-12-2006 16:08

  "Johnny" <moja_ocena@gazeta.pl> wrote in message
news:1mogsiqfow4vf.ohigh8ccc75p$.dlg@40tude.net...
> Dnia Wed, 29 Nov 2006 16:06:33 +0100, Maciek Dobrzanski napisa?(a):
>
> SELECT * FROM FORUM_TEMATY TF
> ORDER BY TF.DATAGODZINA
> LIMIT 31,32
>
> i on co prawda niby korzysta z indexu, ale nadal mieli te rekordy:
>
> key: DATAGODZINA
> rows: 2465

No to jest akurat pewna niedogodno?? EXPLAIN w MySQL. Nie uwzgl?dnia on
efektów optymalizacji klauzuli LIMIT i cho? tak naprawd? dzia?a wydajnie w
tym przypadku, to tego nie wida?. Natomiast nale?y pami?ta?, ?e za wyj?tkiem
szeregu zaprogramowanych optymalizacji, LIMIT jest jedynie filtrem
rezultatów, wi?c nale?y mie? to na uwadze przy jego wykorzystywaniu.

Maciek
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • effulla.pev.pl
  • comp
    [mysql] =?ISO-8859-2?Q?Za=E6mienie=2E=2E=2E_jak_wy=B6wietli=E6?==?ISO-8859-2?Q?=2E=2E=2E?= [mysql] =?ISO-8859-2?Q?wielko=B6=E6_bazy_a_stabilno=B6=E6=2C?==?ISO-8859-2?Q?_podzia=B3_du=BFej_bazy_a_powi=B1zania_tabel?= [MySQL] =?ISO-8859-2?Q?Wy=B6wietlenie_kolejnej_pozycji=2C_?==?ISO-8859-2?Q?jak=B1_mia=B3by_dany_rekord=2C_gdybym_czyta=B3 _?==?ISO-8859-2?Q?wg_konkretnych_kryteri=F3w=2E_Da_si=EA_=3F?= [mysql 4.0.x] przenoszenie kolum =?ISO-8859-2?Q?mi=EAdzy_bazam?==?ISO-8859-2?Q?i_cd_=2E=2E=2E_?= [MySQL] =?ISO-8859-2?Q?z=B3=B1czenie_tabeli_u=BFytkownik_i?==?ISO-8859-2?Q?_zdj=EAcia_z_wyborem_zdj=EAcia_domy=B6lnego?= [MySQL] Jak =?ISO-8859-2?Q?wpisa=E6_do_tabeli_pozycje_dl?==?ISO-8859-2?Q?a_wierszy_gdybym_te_wiersze_wybiera=B3_w_ok?== ?ISO-8859-2?Q?re=B6lonej_kolejno=B6ci_=3F?= Gdzie MySQL 4.1, a gdzie 5.0? [MySQL 4.0...4.1] zabezpieczenie przed =?ISO-8859-2?Q?jednoczesn?==?ISO-8859-2?Q?=B1_edycj=B1?= [MS SQL] "set names" (mySQL) w MS SQL [mysql 5.x] jak =?ISO-8859-2?Q?zrealizowa=E6_zapytanie=3F_cz?==?ISO-8859-2?Q?yli_podzapytanie_i_wi=EAcej_ni=BF_jeden_rz=B1? ==?ISO-8859-2?Q?d_wynik=F3w?=
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • wawa19wwa91.pev.pl
  • Cytat

    Decede mihi sole - nie zasłaniaj mi słonca.
    Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
    Hoc fac - tak czyń.
    A tergo - od tyłu; z tyłu.
    I czarne włosy posiwieją. Safona

    Valid HTML 4.01 Transitional

    Free website template provided by freeweblooks.com