![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
![]() Grupa: Zarejestrowani Postów: 476 Pomógł: 96 Dołączył: 10.04.2008 Skąd: Koszalin Ostrzeżenie: (0%) ![]() ![]() |
Witam
Posiadam stronę WWW, na której użytkownicy wyszukują muzykę. Każda nowa fraza, która jest wyszukiwana jest zapisywana do bazy. W frazach istniejących aktualizowany jest licznik wyszukań. Aktualnie w dość szybkim czasie tabela zapełnia się rekordami, w miesiąc dochodzi nawet do 30-50k nowych rekordów. Przy każdym wyszukaniu cała tabela jest przeszukiwana, przez co MySQL dość mocno obciąża CPU serwera. Na razie staram się systematycznie czyścić tabele, lecz wolałbym jakieś inne rozwiązanie usprawniające/przyspieszające. Frazy jak i ilości wyszukań wykorzystywane są do chmury tagów, ostatnio wyszukiwanych oraz najlepszych dlatego wolałbym nie czyścić tabel. Zrzut tabeli
Wykonywane zapytania podczas wyszukiwania muzyki przez użytkownika
-------------------- |
|
|
![]()
Post
#2
|
|
![]() Grupa: Moderatorzy Postów: 6 072 Pomógł: 861 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza ![]() |
Po pierwsze - dodaj indeks na pole search_txt. Po drugie - zastanów się nad poprawnością typów pól, jakie zastosowałeś. Wspomniany search_txt powinien być VARCHAR, a pola z datami powinny być typu DATETIME, a nie tekstowego.
|
|
|
![]()
Post
#3
|
|
![]() Grupa: Zarejestrowani Postów: 476 Pomógł: 96 Dołączył: 10.04.2008 Skąd: Koszalin Ostrzeżenie: (0%) ![]() ![]() |
Dziękuję za odpowiedź.
Wykonałem następujące rzeczy:
Czy ma dużą różnicę nadanie indeksu na całe 255 znaków tak jak to wykonałem? Czy zapytania Select należy modyfikować pod nowy indeks? Z góry dziękuję i pozdrawiam -------------------- |
|
|
![]()
Post
#4
|
|
![]() Grupa: Zarejestrowani Postów: 508 Pomógł: 75 Dołączył: 2.11.2005 Skąd: Bydgoszcz Ostrzeżenie: (0%) ![]() ![]() |
Ja mam dwie uwagi:
1) Z tego, co przedstawiłeś wynika, że nie masz łączenia tabel. Upewnij się, że rodzaj składowania danych tabeli to MyISAM. Sprawuje się szybciej niż InnoDB w Twoim przypadku, gdzie wyszukujesz w tekście w jednej tabeli. 2) VARCHAR zmień na CHAR. Różnica jest taka, że pola typu CHAR są stałej długości i nie potrzeba kolejnych obliczeń, aby znaleźć dalsze pola. Minus taki, że CHAR za każdym razem rezerwuje 255 bajtów danych, podczas gdy VARCHAR tyle, ile zajmuje tekst. Tańsze jest dokupienie 100 GB HHD/SSD niż dokupienie 1 GHz procesora. Ta zamiana ma sens tylko wtedy, gdy rodzaj składowania danych to MyISAM, bo przy InnoDB nie ma to tak wielkiego znaczenia. Do tego możesz znaleźć optymalną długość pola search_txt: Kod SELECT * FROM `mp3_search` PROCEDURE ANALYSE() Patrzysz na maksymalną długość tekstu w kolumnie i na jej podstawie (+ mały zapas) określasz najbardziej odpowiednią wielkość pola. Długość indeksu najwygodniej, gdy zapełnia całą przestrzeń pola. Nigdy nie oszczędzaj dysku kosztem zużycia procesora. Wychodzi dużo taniej. Ten post edytował franki01 20.12.2010, 12:34:07 |
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 19.07.2025 - 02:06 |