Jakie są główne różnice między InnoDB i MyISAM?


245

Jakie są główne różnice między InnoDB i MyISAM?


23
Jeśli chcesz silnik bazy danych, użyj InnoDB. Nie możesz ich porównać .
Jeremy Stein,

Chociaż wiele z poniższych odpowiedzi jest poprawnych, nie sprowadzają się one jasno, IMHO. Ta strona działa i główny punkt: InnoDB to blokowanie na poziomie wiersza, MyISAM to blokowanie na poziomie tabeli. Oznacza to, ogólnie rzecz biorąc, MyISAM będzie lepszy dla OLAP (analizy, głównie odczyty), a InnoDB będzie lepszy dla OLTP (transakcje, głównie zapisy lub przynajmniej wiele zapisów).
Mike Williamson

Odpowiedzi:


159

Pierwszą dużą różnicą, którą widzę, jest to, że InnoDB implementuje blokadę na poziomie wiersza, podczas gdy MyISAM może wykonać blokadę tylko na poziomie tabeli. Lepsze odzyskiwanie po awarii znajdziesz w InnoDB. Jednak nie ma FULLTEXTindeksów wyszukiwania aż do wersji 5.6, podobnie jak MyISAM. InnoDB implementuje także transakcje, klucze obce i ograniczenia relacji, podczas gdy MyISAM tego nie robi.

Lista może pójść nieco dalej. Oboje mają jednak swoje wyjątkowe zalety na swoją korzyść i wady względem siebie. Każdy z nich jest bardziej odpowiedni w niektórych scenariuszach niż w innych.

Podsumowując ( TL; DR ):

  • InnoDB ma blokowanie na poziomie wiersza, MyISAM może wykonywać tylko pełne blokowanie na poziomie tabeli.
  • InnoDB ma lepsze odzyskiwanie po awarii.
  • MyISAM ma FULLTEXTindeksy wyszukiwania, InnoDB zrobił to dopiero MySQL 5.6 (luty 2013).
  • InnoDB implementuje transakcje, klucze obce i ograniczenia relacji, MyISAM tego nie robi.

Szanowny Panie, więc w końcu czego należy użyć? MyISAM czy InnoDB? jestem całkowicie zdezorientowany ... moja strona używa mysql i muszę o tym zadecydować.
sqlchild

3
zależy od aplikacji, zapisz listę z potrzebnymi funkcjami (np. wyszukiwanie pełnotekstowe, klucze obce ...) i spróbuj wybrać jedną z nich (spróbuj ocenić każdą funkcję, a następnie policzyć wynik). nie będziesz w stanie mieć ich wszystkich, ale to Ty decydujesz, która funkcja jest najbardziej potrzebna.
poelinca

2
Zredagowałem jego post dla wyjaśnienia.
Mathias Lykkegaard Lorenzen

1
@MathiasLykkegaardLorenzen dzięki, to jeden z powodów, dla których lubimy
stackexchange

od version 5.6.4InnoDB obsługuje FULLTEXTwyszukiwanie. dev.mysql.com/doc/refman/5.6/en/fulltext-restrictions.html
daydreamer

85

Inną zasadniczą różnicą, o której jeszcze nie wspomniano, jest sposób buforowania każdego silnika pamięci masowej.

MYISAM

Głównym stosowanym mechanizmem jest pamięć podręczna kluczy. Buforuje tylko strony indeksowe z plików .MYI. Aby zmienić rozmiar pamięci podręcznej kluczy, uruchom następujące zapytanie:

SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.4999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1))
recommended_key_buffer_size FROM
(SELECT LEAST(POWER(2,32),KBS1) KBS
FROM (SELECT SUM(index_length) KBS1
FROM information_schema.tables
WHERE engine='MyISAM' AND
table_schema NOT IN ('information_schema','mysql')) AA ) A,
(SELECT 2 PowerOf1024) B;

To da Zalecane ustawienie dla pamięci podręcznej kluczy MyISAM ( key_buffer_size ) biorąc pod uwagę twój aktualny zestaw danych ( zapytanie ograniczy rekomendację do 4G (4096M). W przypadku 32-bitowego systemu operacyjnego limit to 4 GB. W przypadku 64-bitowego 8 GB.

InnoDB

Głównym zastosowanym mechanizmem jest pula buforów InnoDB. Buforuje dane i strony indeksowe z tabel InnoDB, do których uzyskano dostęp. Aby zmienić wielkość puli buforów InnoDB, uruchom następujące zapytanie:

SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.49999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_innodb_buffer_pool_size
FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables
WHERE engine='InnoDB') A,
(SELECT 2 PowerOf1024) B;

Da to ustawienie zalecane dla wielkości puli buforów InnoDB ( innodb_buffer_pool_size ), biorąc pod uwagę twój aktualny zestaw danych.

Nie zapomnij zmienić rozmiaru plików dziennika InnoDB (ib_logfile0 i ib_logfile1). Kod źródłowy MySQL umieszcza limit łącznych rozmiarów wszystkich plików dziennika InnoDB musi wynosić <4G (4096M). Dla uproszczenia, biorąc pod uwagę tylko dwa pliki dziennika, oto sposób ich rozmiaru:

  • Krok 1) Dodaj innodb_log_file_size = NNN do /etc/my.cnf (NNN powinno wynosić 25% wielkości innodb_buffer_pool_size lub 2047M, w zależności od tego, która wartość jest mniejsza)
  • Krok 2) service mysql stop
  • Krok 3) rm /var/log/mysql/ib_logfile[01]
  • Krok 4) service mysql start(ib_logfile0 i ib_logfile1 są odtwarzane)

CAVEAT

Na końcu obu zapytań znajduje się zapytanie wbudowane (SELECT 2 PowerOf1024)B

  • (SELECT 0 PowerOf1024) daje ustawienie w bajtach
  • (SELECT 1 PowerOf1024) daje ustawienie w kilobajtach
  • (SELECT 2 PowerOf1024) daje ustawienie w megabajtach
  • (SELECT 3 PowerOf1024) daje ustawienie w gigabajtach
  • Żadne moce mniejsze niż 0 lub większe niż 3 nie są akceptowane

EPILOG

Nic nie zastąpi zdrowego rozsądku. Jeśli masz ograniczoną pamięć, mieszankę silników pamięci lub ich kombinację, będziesz musiał dostosować się do różnych scenariuszy.

  • Jeśli masz 2 GB pamięci RAM i 16 GB pamięci InnoDB, przydziel 512 MB jako innodb_buffer_pool.
  • Jeśli masz 2 GB pamięci RAM i 4 GB indeksów MyISAM, przydziel 512 MB jako key_buffer_size.
  • Jeśli masz 2 GB pamięci RAM i 4 GB indeksów MyISAM i 16 GB InnoDB, przydziel 512 MB jako rozmiar_ bufora_klucza i 512 MB jako rozmiar_bufora_wynodb.

Możliwe scenariusze są nieograniczone !!!

Pamiętaj, bez względu na to, na co przeznaczasz, pozostaw wystarczającą ilość pamięci RAM na połączenia DB i system operacyjny.


To są złe formuły!
Rick James

(Ups - zapominaj, że nie mogę mieć akapitów) ... Dodam „odpowiedź”.
Rick James

Formuły Rolando dotyczące wielkości pamięci podręcznej nie są praktyczne. - Moce 2 nie są potrzebne. - 4 GB w 32-bitowym systemie operacyjnym jest niemożliwe - Itd. Oto moje podsumowanie, w jaki sposób je ustawić: mysql.rjweb.org/doc.php/memory (dotyczy różnych innych ustawień, które wpływają na użycie pamięci.)
Rick James

2
@ Rick: Moce 2 miały wyświetlać odpowiedzi w różnych jednostkach. Wykonanie (SELECT 2 PowerOfTwo) Ustawia wyświetlanie odpowiedzi w MB. Wykonanie (SELECT 3 PowerOfTwo) Ustawia wyświetlanie w GB. (WYBIERZ 1 PowerOfTwo) Wyświetla w KB. (WYBIERZ 0 PowerOfTwo) Wyświetla w bajtach. Tak właśnie działa (SELECT 2 PowerOfTwo). Konieczne jest WYŁĄCZNIE WYŚWIETLANIE, a nie narzucanie założonych wartości w architekturze.
RolandoMySQLDBA

2
@Rick: Wiesz co? Dam ci +1 z dwóch bardzo ważnych powodów. 1) Twój adres URL potwierdza, że ​​moja odpowiedź była prawidłowa, ponieważ 4 GB to największy numer do przypisania do key_buffer_size. 2) Twoja odpowiedź wraz z adresem URL ma sens w przypadku bardzo małej pamięci maszyn. Udzielę kredytu tam, gdzie jest on należny.
RolandoMySQLDBA

60

InnoDB oferuje:

  • Transakcje ACID
  • blokowanie na poziomie wiersza
  • ograniczenia klucza obcego
  • automatyczne przywracanie po awarii
  • kompresja tabeli (odczyt / zapis)
  • typy danych przestrzennych (bez indeksów przestrzennych)

W InnoDB wszystkie dane z rzędu oprócz TEKSTU i BLOBA mogą zajmować maksymalnie 8 000 bajtów. Indeksowanie pełnotekstowe nie jest dostępne w InnoDB do MySQL 5.6 (luty 2013). W InnoDB COUNT(*)s (kiedy WHERE, GROUP BYlub JOINnie jest używany) działa wolniej niż w MyISAM, ponieważ liczba wierszy nie jest przechowywana wewnętrznie. InnoDB przechowuje zarówno dane, jak i indeksy w jednym pliku. InnoDB używa puli buforów do buforowania zarówno danych, jak i indeksów.

MyISAM oferuje:

  • fast COUNT(*)s (w przypadku WHERE, GROUP BYalbo JOINnie jest używana)
  • indeksowanie pełnotekstowe (aktualizacja: obsługiwane w InnoDB z MySQL 5.6)
  • mniejszy ślad na dysku
  • bardzo wysoka kompresja tabeli (tylko do odczytu)
  • typy danych przestrzennych i indeksy (R-drzewo) (aktualizacja: obsługiwane w InnoDB z MySQL 5.7)

MyISAM ma blokowanie na poziomie tabeli, ale nie blokuje na poziomie wiersza. Brak transakcji. Brak automatycznego odzyskiwania po awarii, ale oferuje funkcje tabeli napraw. Brak ograniczeń klucza obcego. Tabele MyISAM są na ogół bardziej kompaktowe na dysku w porównaniu do tabel InnoDB. Tabele MyISAM można dodatkowo znacznie zmniejszyć, kompresując myisampack, jeśli to konieczne, ale stać się tylko do odczytu. MyISAM przechowuje indeksy w jednym pliku, a dane w innym. MyISAM używa buforów kluczy do buforowania indeksów i pozostawia zarządzanie buforowaniem danych w systemie operacyjnym.

Ogólnie polecam InnoDB do większości celów, a MyISAM tylko do specjalistycznych zastosowań. InnoDB jest teraz domyślnym silnikiem w nowych wersjach MySQL.


5
Przeczytałem twoją odpowiedź i porównałem ją z innymi już tutaj. Twój jako jedyny wspomniał o BLOBach. Zazwyczaj uważa się je za coś oczywistego. Twoja jest także jedyną, która wspomina o myisampack, jednym z niedocenianych bohaterów szybko czytelnych tabel MyISAM. Twoja dzisiaj jest +1!
RolandoMySQLDBA

2
Przykładem może być skompresowana tabela tylko do odczytu, w której rzadko ją aktualizujesz, całkowicie zastępując tabelę.
dabest1

30

Jeszcze jedno: możesz wykonać kopię zapasową tabel InnoDB, wykonując migawkę systemu plików. Tworzenie kopii zapasowej MyISAM wymaga użycia mysqldump i nie ma gwarancji, że będzie spójne (np. Jeśli wstawisz tabelę nadrzędną i podrzędną, w kopii zapasowej może znajdować się tylko wiersz tabeli podrzędnej).

Zasadniczo, jeśli masz inną kopię danych i buforujesz ją tylko w MySQL, np. W celu umożliwienia standardowego dostępu do niej ze strony PHP, to MyISAM jest w porządku (tzn. Jest lepszy niż płaski plik CSV lub plik dziennika do zapytań i równoczesny dostęp). Jeśli baza danych jest faktyczną „główną kopią” danych, jeśli robisz INSERTi UPDATEużywasz prawdziwych danych od użytkowników, głupotą jest używanie czegokolwiek innego niż InnoDB, w jakiejkolwiek skali MyISAM jest zawodny i trudny do zarządzania, ty Będę robił myisamchkpołowę czasu, negując jakiekolwiek zyski wydajności ...

(Moje osobiste doświadczenie: 2 terabajtowa baza danych w MyISAM).


29

Trochę za późno na grę ... ale oto dość obszerny post, który napisałem kilka miesięcy temu , opisując główne różnice między MYISAM a InnoDB. Chwyć cuppa (a może herbatniki) i ciesz się.


Główną różnicą między MyISAM a InnoDB jest integralność referencyjna i transakcje. Istnieją również inne różnice, takie jak blokowanie, wycofywanie zmian i wyszukiwanie pełnotekstowe.

Więzy integralności

Integralność referencyjna zapewnia spójność relacji między tabelami. Mówiąc dokładniej, oznacza to, że gdy tabela (np. Listy) ma klucz obcy (np. Identyfikator produktu) wskazujący na inną tabelę (np. Produkty), kiedy aktualizacje lub usunięcia mają miejsce w tabeli wskazanej, zmiany te są kaskadowane do łączenia stół. W naszym przykładzie, jeśli nazwa produktu zostanie zmieniona, klucze obce tabeli łączącej również się zaktualizują; jeśli produkt zostanie usunięty z tabeli „Produkty”, wszelkie wykazy wskazujące na usunięty wpis również zostaną usunięte. Ponadto każdy nowy wpis musi mieć ten klucz obcy wskazujący prawidłowy, istniejący wpis.

InnoDB jest relacyjnym DBMS (RDBMS), a zatem ma integralność referencyjną, podczas gdy MyISAM nie.

Transakcje i atomowość

Dane w tabeli są zarządzane za pomocą instrukcji DML (Data Manipulation Language), takich jak SELECT, INSERT, UPDATE i DELETE. Transakcja grupuje dwie lub więcej instrukcji DML razem w jedną jednostkę pracy, więc albo stosowana jest cała jednostka, albo żadna z niej nie jest.

MyISAM nie obsługuje transakcji, podczas gdy InnoDB obsługuje.

Jeśli operacja zostanie przerwana podczas korzystania z tabeli MyISAM, operacja zostanie natychmiast przerwana, a zmienione wiersze (lub nawet dane w każdym wierszu) pozostaną niezmienione, nawet jeśli operacja nie zostanie ukończona.

Jeśli operacja zostanie przerwana podczas korzystania z tabeli InnoDB, ponieważ wykorzystuje ona transakcje o atomowości, każda transakcja, która nie została zakończona, nie wejdzie w życie, ponieważ nie zostanie wykonane zatwierdzenie.

Blokowanie tabeli a blokowanie wiersza

Gdy zapytanie działa przeciwko tabeli MyISAM, cała tabela, w której jest ona wysyłana, zostanie zablokowana. Oznacza to, że kolejne zapytania będą wykonywane dopiero po zakończeniu bieżącego. Jeśli czytasz dużą tabelę i / lub często wykonujesz operacje odczytu i zapisu, może to oznaczać ogromne zaległości w zapytaniach.

Gdy zapytanie działa przeciwko tabeli InnoDB, tylko zaangażowane wiersze są zablokowane, reszta tabeli pozostaje dostępna dla operacji CRUD. Oznacza to, że zapytania mogą być uruchamiane jednocześnie w tej samej tabeli, pod warunkiem, że nie używają tego samego wiersza.

Ta funkcja w InnoDB jest znana jako współbieżność. Niezależnie od tego, jak duża jest współbieżność, istnieje poważna wada, która ma zastosowanie do wybranego zakresu tabel, polegająca na tym, że przełączanie między wątkami jądra wiąże się z narzutem, i powinieneś ustawić limit wątków jądra, aby zapobiec zatrzymaniu się serwera .

Transakcje i wycofania

Po uruchomieniu operacji w MyISAM zmiany są ustawiane; w InnoDB zmiany te można wycofać. Najpopularniejsze polecenia używane do kontrolowania transakcji to COMMIT, ROLLBACK i SAVEPOINT. 1. COMMIT - możesz napisać wiele operacji DML, ale zmiany zostaną zapisane dopiero po wykonaniu COMMIT 2. ROLLBACK - możesz odrzucić wszelkie operacje, które nie zostały jeszcze zatwierdzone 3. SAVEPOINT - ustawia punkt na liście operacje, do których można przywrócić operację ROLLBACK

Niezawodność

MyISAM nie zapewnia integralności danych - awarie sprzętu, nieczyste wyłączenia i anulowane operacje mogą spowodować uszkodzenie danych. Wymagałoby to pełnej naprawy lub przebudowy indeksów i tabel.

InnoDB, z drugiej strony, wykorzystuje dziennik transakcji, bufor podwójnego zapisu oraz automatyczne sumowanie i sprawdzanie, aby zapobiec uszkodzeniu. Przed wprowadzeniem jakichkolwiek zmian InnoDB rejestruje dane przed transakcjami w pliku obszaru tabel o nazwie ibdata1. W przypadku awarii InnoDB automatycznie odzyskałby zawartość poprzez odtworzenie tych dzienników.

Indeksowanie FULLTEXT

InnoDB nie obsługuje indeksowania FULLTEXT, dopóki MySQL w wersji 5.6.4. W chwili pisania tego postu wersja MySQL wielu dostawców hostingu współdzielonego jest nadal niższa niż 5.6.4, co oznacza, że ​​indeksowanie FULLTEXT nie jest obsługiwane dla tabel InnoDB.

Nie jest to jednak uzasadniony powód do korzystania z MyISAM. Najlepiej jest zmienić się na dostawcę usług hostingowych obsługującego aktualne wersje MySQL. Nie dlatego, że tabela MyISAM, która korzysta z indeksowania FULLTEXT, nie może zostać przekonwertowana na tabelę InnoDB.

Wniosek

Podsumowując, InnoDB powinien być twoim domyślnym silnikiem pamięci. Wybierz MyISAM lub inne typy danych, jeśli spełniają one określone potrzeby.


1
Dzięki, naprawdę pouczające i jasne podsumowanie.
informatik01

18

Z mojego doświadczenia wynika, że ​​najbardziej znaczącą różnicą jest sposób, w jaki każdy silnik obsługuje blokowanie. InnoDB używa blokowania wierszy, a MyISAM korzysta z blokowania tabel. Zasadniczo używam InnoDB do pisania ciężkich tabel i MyISAM do odczytu ciężkich tabel.

Inne ważne różnice obejmują:

  1. Transakcje obsługi InnoDB i klucze obce. MyISAM nie.
  2. MyISAM wykorzystuje indeksowanie pełnotekstowe.
  3. MyISAM źle sobie radzi z egzekwowaniem integralności danych.

Nieaktualne - InnoDB ma teraz FULLTEXTi SPATIAL. InnoDB jest dobry zarówno dla obciążeń o wysokim stopniu odczytu, jak i zapisu.
Rick James

8

Zazwyczaj postrzegam MyISAM jako „domyślną” tabelę dla MySQL, więc wskazuję różnice dla większości użytkowników InnoDB

  • Blokowanie poziomu rzędu
  • Egzekwowanie klucza obcego
  • Obsługa transakcji
  • Uderzenie wydajności w systemach o wysokim użyciu

5
z wyjątkiem najnowszej wersji MySQL nie używa już MyISAM jako domyślnego silnika. W wersji 5.5 zmienili domyślną na InnoDB :). I nie zgodziłbym się z uogólnieniem, że InnoDB w ogóle dostaje po prostu „hit wydajności”. Dobrze zaprojektowane tabele InnoDB z właściwym indeksowaniem i dobrze skonfigurowanymi ustawieniami pamięci mogą sprawić, że tabela InnoDB będzie działać tak samo, jak ten sam schemat w MyISAM
TechieGurl

3
W wielu sytuacjach „intensywnego użycia” InnoDB faktycznie działa znacznie lepiej niż MyISAM. MyISAM jest specyficznym narzędziem dla konkretnego problemu, podczas gdy InnoDB będzie ci lepiej służył w większości sytuacji (dlatego zespół MySQL uczynił go domyślnym silnikiem). To dlatego, że MyISAM był jedynym silnikiem przez długi czas, dlatego społeczność MySQL nabrała zwyczaju domyślnego używania MyISAM, nawet po dojrzewaniu InnoDB.
Nick Chammas,

2
Wyszukiwanie FULLTEXT dla InnoDB zostało dodane w trakcie cyklu rozwoju MySQL 5.6. Cytowany adres URL obejmuje teraz także InnoDB.
Max Webster,

5

MYISAM

MYISAM zapewnia blokowanie na poziomie tabeli, wyszukiwanie FULLTEXT. MYISAM ma najbardziej elastyczną obsługę kolumn AUTO_INCREMENTED we wszystkich silnikach pamięci. MYISAM nie obsługuje transakcji.

INNODB

INNODB to bezpieczny dla transakcji silnik pamięci. INNODB ma funkcje zatwierdzania, wycofywania i odzyskiwania po awarii. INNODB obsługuje integralność referencyjną klucza obcego.


5

Obejmuje zmiany w MySQL 5.6

SILNIK DO PRZECHOWYWANIA INNODB:

  • Zapewnia pełną zgodność z ACID (atomowość, konsystencja, izolacja, trwałość). Wiele wersji służy do izolowania transakcji od siebie.
  • InnoDB zapewnia automatyczne odzyskiwanie po awarii serwera MySQL lub hosta, na którym działa serwer.
  • InnoDB obsługuje klucze obce i integralność referencyjną, w tym kaskadowe usuwanie i aktualizacje.
  • MySQL 5.6 opiera się na platformie InnoDB w pełni zintegrowanej jako domyślny silnik pamięci
  • Trwałe statystyki optymalizatora : Zapewnia lepszą dokładność statystyk indeksu InnoDB i spójność podczas restartowania MySQL.
  • Czyszczenie pamięci podręcznej tabeli InnoDB: Aby zmniejszyć obciążenie pamięci w systemach z dużą liczbą tabel, InnoDB zwalnia teraz pamięć związaną z otwartą tabelą. Algorytm LRU wybiera tabele, które przeszły najdłużej bez dostępu.
  • Obsługuje wyszukiwanie pełnotekstowe: specjalny rodzaj indeksu, indeks FULLTEXT, pomaga InnoDB radzić sobie z zapytaniami i operacjami DML obejmującymi kolumny tekstowe i zawarte w nich słowa. Indeksy te są fizycznie reprezentowane jako całe tabele InnoDB.
  • InnoDB wydaje się być znacznie szybszy w wyszukiwaniu pełnotekstowym niż MyISAM

Więc nie ma sensu używać MyISAMEngine, jeśli jesteś już uaktualniony do wersji 5.6, jeśli nie, nie czekaj na aktualizację do MySQL 5.6.

Wydajność InnoDB VS MyISAM przy użyciu MySQL 5.6


2

MyISAM

MyISAM to silnik pamięci masowej dla MySQL. Przed MySQL 5.5 był domyślnym silnikiem pamięci MySQL. Opiera się na starszym silniku pamięci ISAM. MyISAM jest zoptymalizowany do środowisk z intensywnymi operacjami odczytu, z niewielką liczbą zapisów lub wcale. Powodem, dla którego MyISAM pozwala na szybkie odczytywanie, jest struktura jego indeksów: każdy wpis wskazuje na rekord w pliku danych, a wskaźnik jest przesunięty względem początku pliku. W ten sposób rekordy mogą być szybko odczytywane, szczególnie gdy format jest NAPRAWIONY. Tak więc rzędy mają stałą długość. Typowym obszarem, w którym można preferować MyISAM, jest hurtownia danych, ponieważ obejmuje zapytania dotyczące bardzo dużych tabel, a aktualizacja takich tabel odbywa się, gdy baza danych nie jest używana (zwykle w nocy). Wstawki są również łatwe, ponieważ nowe wiersze są dołączane na końcu pliku danych. Jednak, operacje usuwania i aktualizacji są bardziej problematyczne: usuwanie musi pozostawić puste miejsce, w przeciwnym razie przesunięcia wierszy ulegną zmianie; to samo dotyczy aktualizacji, ponieważ długość wierszy staje się krótsza; jeśli aktualizacja wydłuży wiersz, wiersz zostanie pofragmentowany. Aby defragmentować wiersze i przejąć puste miejsce, należyOPTIMIZE TABLEpolecenie musi zostać wykonane. Z powodu tego prostego mechanizmu statystyki indeksu MyISAM zwykle są dość dokładne. Inne główne wady MyISAM to brak obsługi transakcji i kluczy obcych.

InnoDB

InnoDB to silnik pamięci dla MySQL. MySQL 5.5 i nowsze wersje używają go domyślnie. Zapewnia standardowe funkcje transakcji zgodne z ACID, a także obsługę klucza obcego (deklaratywna integralność referencyjna). Implementuje transakcje SQL i XA, obszary tabel, FULLTEXTindeksy i operacje przestrzenne zgodnie ze standardem OpenGIS. Jest standardowo dołączany do większości plików binarnych dystrybuowanych przez MySQL AB, z wyjątkiem niektórych wersji OEM. Oprogramowanie jest podwójnie licencjonowane przez Oracle Corporation; jest rozpowszechniany na podstawie Powszechnej Licencji Publicznej GNU, ale może być również licencjonowany dla stron, które chcą połączyć InnoDB w oprogramowaniu prawnie zastrzeżonym.

Widelce

MariaDB ma silnik pamięci o nazwie Aria, który jest opisany jako „bezpieczna alternatywa dla MyISAM”. MariaDB i Percona Server domyślnie używają rozwidlenia InnoDB o nazwie XtraDB. XtraDB jest utrzymywany przez Percona. Zmiany w Oracle InnoDB są regularnie importowane do XtraDB, a także niektóre poprawki błędów i dodatkowe funkcje.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.