Dlaczego miałbym kiedykolwiek preferować ALGORYTM = KOPIUJ zamiast ALGORYTM = WSTAW?

16

Ponieważ MySQL 5.6 wprowadził DDL online, ALTER TABLEpolecenie może opcjonalnie mieć jeden ALGORITHM=INPLACElub ALGORITHM=COPYokreślony. Przegląd internetowych DDL zauważa, że domyślnie INPLACEjest stosowany wszędzie tam, gdzie to możliwe, i sugeruje (nigdy dość podając ją), że INPLACEalgorytm jest tańszy niż COPYsię jest.

Jaki więc powód powinienem podać ALGORITHM=COPYw ALTER TABLEoświadczeniu?

— Mark Amery
źródło

Jeśli użyjesz funkcji KOPIUJ, co stanie się z indeksami na stole? Czy kończysz na defragmentacji indeksów z powodu tworzenia nowej tabeli i wypełniania jej od zera?

— Dave Poole

Jeśli COPY zapełni się od zera, to mimo że jest to wolna opcja, wynikowa tabela może działać lepiej z powodu defragmentowanych indeksów.

— Dave Poole

@DavePoole Fajna teoria, ale podejrzewam, że jest nie na miejscu, ponieważ OPTIMIZE TABLE(jak sądzę, ma defragmentujące indeksy jako dużą część jej celu ) używa ALGORITHM=INPLACEod MySQL 5.7.4. Więc myślę, że to przypadek, że tak, COPY czy indeksy Defrag, ale tak robiINPLACE (jakoś), znoszący ją jako potencjalną korzyść COPY.

— Mark Amery

2

„Tabele InnoDB utworzone przed MySQL 5.6 nie obsługują ALTER TABLE ... ALGORITHM=INPLACEtabel zawierających kolumny czasowe (DATA, DATETIME lub TIMESTAMP) i nie zostały odbudowane przy użyciu ALTER TABLE ... ALGORITHM=COPY” ... Ograniczenia DDL online

— JSapkota

10

Tak, zdarzają się przypadki, w których można określić COPY, ale dzieje się tak z innych powodów niż wydajność.

Ważne jest, aby zrozumieć, że MySQL wprowadził nową funkcję - przetwarzanie DLL online w wersji 5.6. Nie usunęło przetwarzania offline. Dlatego należy rozróżnić te 2 tryby:

Niektóre operacje nadal działają tylko w trybie offline. Tabela 15.10, „ Podsumowanie statusu online operacji DDL ” zawiera listę operacji DDL, które można lub nie można wykonać na miejscu.
Operacje w trybie online i offline mają nieco inne zachowanie, więc możesz wybrać „stary” ze względu na kompatybilność.

Kilka przykładów (proszę sugerować więcej):

Tabele InnoDB utworzone przed MySQL 5.6 nie obsługują ALTER TABLE ... ALGORITHM=INPLACEtabel zawierających kolumny czasowe ( DATE, DATETIMElub TIMESTAMP) i nie zostały przebudowane przy użyciu ALTER TABLE ... ALGORITHM=COPY. W takim przypadku ALTER TABLE ... ALGORITHM=INPLACEoperacja zwraca błąd.
ADD PRIMARY KEYklauzula in COPY modepo cichu konwertuje NULLna wartości domyślne dla tego typu danych (0 dla INT, pusty ciąg dla varchar), podczas IN_PLACEgdy nie robi tego.

Dzięki klauzuli ALGORITHM = COPY operacja kończy się powodzeniem pomimo obecności wartości NULL w kolumnach klucza podstawowego; dane są dyskretnie zmieniane, co może powodować problemy.

Kolejny powód, aby preferować COPY:

Operacje, dla których określono ALGORITHM = KOPIUJ lub stary_tabela_tabeli = 1, aby wymusić zachowanie kopiowania tabeli, jeśli jest to konieczne dla dokładnej zgodności wstecznej w wyspecjalizowanych scenariuszach.

Chociaż instrukcja MySQL nie mówi o rzeczywistych scenariuszach, możesz sobie wyobrazić niektóre. Np. Programista polegał na zablokowaniu tabeli podczas ALTER INDEXpracy, więc tabela jest tylko do odczytu lub całkowicie zablokowana, a proces przeszukiwania tabeli statycznej odbywa się podczas przebudowy indeksu.

— Stoleg
źródło

1

Myślę, że ludzie również mylą się ALGORITHM=INPLACEz tym, że „jest to Online DDL i nie blokuje bazy danych”, podczas gdy tak naprawdę chcą z niego korzystać LOCK=NONE.

— Brendan Byrd

2

@Stoleg ma prawdopodobnie najlepszą odpowiedź, ale tutaj jest inna. Zgaduje, że programiści pozostawili =COPYluk ratunkowy na wypadek poważnego błędu =INLINE. Pozwoliłoby to użytkownikom nadal korzystać, ALTERnawet jeśli nowa funkcja jest zepsuta.

Przez lata widziałem takie rzeczy (flagi sql_mode, my.cnfustawienia itp.). Celem nowej wersji jest wyraźnie przedstawienie nowej, lepszej funkcji.

Flagi optymalizacji należą do tej kategorii, ale istnieje jeszcze więcej powodów, aby trzymać się poprzednich działań - Optymalizator zawsze „zrobi to źle”; jest po prostu zbyt wiele możliwości.

— Rick James
źródło

1

Dlaczego nazwałbyś to „lukiem ratunkowym” zamiast „wsteczną kompatybilnością”? Choć może nie być dużej różnicy;)

— Stoleg

1

Powiedziałbym „kompatybilność wsteczna”, gdybym potrzebował tego samego kodu do uruchomienia w obu wersjach. Ale wtedy martwiłbym się, czy nowa składnia została rozpoznana przez starą wersję.

— Rick James

-1

W wersjach MySQL, które obsługują szyfrowanie obszaru tabel InnoDB, po zmianie tabeli w celu dodania szyfrowania zmiana jest wykonywana przy użyciu algorytmu kopiowania z konieczności.

— nthdesign
źródło