Mam taki pytanko odnośnie bazki w Mysql. Na razie wszystko działa ok, ale mam jedna tabelkę(12 pól), która dość szybko się zapełnia nowymi rekordami. Przewiduję, że za kilka miesięcy może być kilkaset tysięcy rekordów, może milion. Czy taka liczba rekordów wpłynmie znacząco na szybkość przeszukiwaniaq bazki? Bo mam pomysł, żeby podzielić ją na kilka bliźniaczych, ale nie wiem czy jest sens. moze ktoś zna odpowiedź

z dobrze założonymi indeksami nie powinno być tak źle, ale oczywiście czym mniej rekordów w bazie tym lepiej (czyt. szybciej). jesli częśc danych ulega "przedawnieniu", tzn. np stare zamówienia czy coś w tym rodzaju, czy też po prostu dane z których coraz rzadziej korzystamy najlepiej wywalić do innej tabeli...

właśnie problem w tym, że wszystkie rekordy w tej tabeli będą aktualne, będą podlegać conajwyżej modyfikacji. zastanawiam się czy możnaby stworzyć kilka tabel bliźniaczych, podzielić ej odpowiednio na kategorie, nie wiem tylko czy to eleganckie, no i trochę mniej funkcjonalne

Aby być przygotowanym na ewentualne kłopoty,
najlepiej stwórz sobie kopie tej bazy i zapełnij ją do ok 2 milionów.
Następnie wykonaj testy a dowiesz się czy masz dobre index'y

1. założenie indeksów to podstawa. jesli dane są ułożone według konkretnej kolumny np.daty możesz co jakis czas wykonywać ALTER TABLE table ORDER BY kolumna DESC

2. stworzenie bliznaczych tabel dla różnych kategori, jesli tylko nie przeszkodzi to w formułowaniu zapytań, a wpłynie na wydajność jest jak najbardziej dobrym rozwiązaniem. w końcu właścicielowi systemu przeważnie nie chodzi o to czy rozwiązanie będzie eleganckie, ale czy skuteczne i wydajne z punktu widzenia użytkownika.

Co to znaczy?

No nie wiem.
Jeżeli będzie chciał wyszukiwać dane we wszystkich tabelach,
to używanie UNION dla kilku tabel będzie małą katastrofą.

1. porzadkuje rekordy w bazie wedlug kolumny kolumna

2. jak napisalem : "jesli to nie przeszkodzi w formułowaniu zapytań"

Wiem, chodziło mi jaki ma to związek z wydajnością.

Tu nie chodzi o formułowanie zapytań. Chcąc cokolwiek wyszukać, musisz zrobić coś w rodzaju:

[SQL] pobierz, plaintext 
SELECT * 
FROM (SELECT * 
FROM tabela1 UNION ALL SELECT * 
FROM tabela2 UNION ALL SELECT * 
FROM tabela3 ....itd) AS temp WHERE pole='costam'
[SQL] pobierz, plaintext 

Jak wiesz podzapytanie from buduje tabelę tymczasową,
więc moim zdaniem lepiej trzymać wszystko w jednej tabeli z dobrze założonymi index'ami.

no i tu pojawia się problem, ponieważ wykonanie zapytania dla 700 000 rekordó trwa kilka minut lokalnie, w przypadku zwróconych kilku, kilkunastu rekordów kilkadziesiąt sekund, ale z bliźniaczymi tabrlami to też niedobry pomysł. Ale przeciez istnieją duże serwisy oparte o mysql'a, więc jakies optymalne rozwiązanie musi istnieć
pozdrawiam

To moze napisz cos wiecej o danych, ktore przechowujesz.
Podaj strukture tabeli i zapytanie(a), ktore tak muli(ą).

są to dane firm, ale mój problem chyba został rozwiązany przez zastosowanie indeksów. To chyba optymalne rozwiązanie. pozdrawiam

cytując manuala This option is mainly useful when you know that you are mostly going to query the rows in a certain order; by using this option after big changes to the table, you might be able to get higher performance.

innymi słowy, mysql szybciej wyszuka rekordy z tabeli jesli sa uporzadkowane tak jak w zapytaniu.

Sorki za [OT]W Sieci można znaleść artykuły opisujące przypadki kiedy MysQL działał z 5 miliardami(!) rekordów tabeli(!) -- pogoogluj troche [/OT]

Z mojego doświadczenia wynika, że dobrze opracowane tabele zawierające bardzo duże ilości danych znacznie lepiej działają niż źle opracowane tabele z małą ilością rekordów...
Warto wykonać na tabeli polecenie:

[SQL] pobierz, plaintext 
SELECT * 
FROM `tabela` PROCEDURE ANALYSE ( )
[SQL] pobierz, plaintext 

by zobaczyć jak silnik MySQLa ułożył dane w takiej tabeli (w phpMyAdmin jest to funkcja "Propozycja struktury tabeli" dostępna pod listą pól tabeli).