MySQL – optymalizacja i wydajność

W poprzednim poście wspominałem o mechanizmie LOCKów w MyISAM. Zasadniczo wygląda to tak, że MyISAM obsługuje LOCKi na poziomie tabeli – jeśli dane są odczytywane przez jedno zapytanie, to nie ma możliwości aby w tym samym czasie wykonywana była modyfikacja danych w tej tabeli (wyjątkiem jest opisywana w poprzednim poście sytuacja). Domyślnie pierwszeństwo mają zapytania, które modyfikują dane. Dopiero jak żaden INSERT/UPDATE/DELETE nie wisi w kolejce, wykonywane są SELECTy. Czasami dobrze byłoby mieć możliwość zmiany tego zachowania. Jak to zrobić?

Jednym z rozwiązań jest po prostu ustawienie zmiennej low-priority-updates na ‚yes’. Zmienna ta może być definiowana na poziomie globalnym lub sesji. Wprowadzenie takiej zmiany odwraca domyślne ustawienie i w tym momencie wyższy priorytet będą miały zapytania typu SELECT. Zmiana ta jednak dotyczy wszystkich zapytań a w pewnych sytuacjach dobrze by było móc sterować priorytetem poszczególnych zapytań. Są i na to sposoby.
czytaj dalej…

Słyszeliście, drodzy Czytelnicy, o mechanizmie Concurent Inserts? Jeśli nie, to posłuchajcie. Jak wiemy, w silniku MyISAM locki tworzone są na poziomie tabel. Jest to z jednej strony dobre, bo np. w ten sposób wykluczamy możliwość zaistnienia deadlocka (a przynajmniej w dużej części – w przypadku użycia kursorów deadlock może się pojawić także w przypadku blokowania na poziomie tabel), z drugiej strony jest to problem, bo tego typu mechanizm blokowania nie radzi sobie w momencie, gdy ruch do danej tabeli obejmuje spory procent zapisów.
czytaj dalej…

W dniu wczorajszym Oracle wydało kolejną stabilną wersję MySQL – MySQL 5.5.8

Pozwolę sobie nie przepisywać informacji prasowych, podam tylko kilka linków. Najważniejsze to to, że domyślnym silnikiem bazodanowym staje się InnoDB – może teraz będziemy spędzać mniej czasu na naprawianiu tabel MyISAM.

Oficjalna informacja prasowa

Informacje o tym, co zostało dodane i poprawione

Wpis na blogu Oracle

Zdarza się, że chcielibyśmy obrobić wynik jakiegoś zapytania. Czasami problemem jest to, że w wyniku otrzymaliśmy po prostu dużą ilość rekordów i przydałaby się jakaś paginacja. Czasami chcielibyśmy wyciągnąć z wyniku jakieś konkretne fragmenty – w powłoce można użyć grep’a, w konsoli MySQL teoretycznie jest z tym problem. Tylko czy aby na pewno problem?
czytaj dalej…

W poprzednich postach pisałem o algorytmie Index Merge i wykonałem krótki test jego wydajności. Tym razem przyglądniemy się jak wygląda wydajność tego algorytmu gdy danych jest dużo. Tabela, do jakiej będziemy wykonywać zapytania ma następującą strukturę:

czytaj dalej…

W poprzednim poście pisałem o algorytmie Index Merge, który w pewnych, szczególnych wpadkach umożliwia skorzystanie z kilku indeksów jednocześnie. Jak wygląda wydajność tego algorytmu? Czy jest sens stosować go zamiast indeksów na wiele kolumn? Aby to sprawdzić przygotowałem środowisko testowe. Tabela ma następującą strukturę:

Jak widać, jest w niej 2 miliony niewielkich rekordów. Kolumny `b`, `c`, `d` i `e` przyjmują pseudolosowo generowane wartości z zakresu 0 – 100.

Tabela w takiej postaci zajmuje: dane –  41016K, klucz główny – 20045K.
czytaj dalej…