Чому я коли-небудь віддаю перевагу ALGORITHM = КОПІЯ перед ALGORITHM = INPLACE?

16

Оскільки MySQL 5.6 представив онлайн-DDL, ALTER TABLEкоманда може необов'язково мати ALGORITHM=INPLACEабо ALGORITHM=COPYвказати. Огляд онлайн DDL зазначає , що, за замовчуванням, INPLACEвикористовується всюди , де це можливо, і передбачає (ніколи не цілком виклавши його) , що INPLACEалгоритм дешевше , ніж COPYодин.

Отже, яку причину мені колись доведеться вказати ALGORITHM=COPYу ALTER TABLEзаяві?

— Марк Амерді
джерело

Якщо ви використовуєте COPY, що відбувається з індексами таблиці? Чи закінчуєте ви дефрагментовані індекси через створення нової таблиці та заповнення з нуля?

— Дейв Пул

Якщо COPY заповнюється з нуля, тоді хоча це повільний варіант, отримана таблиця може працювати краще за рахунок дефрагментованих індексів.

— Дейв Пул

@DavePoole Хороша теорія, але я підозрюю, що це не вдається, оскільки OPTIMIZE TABLE(як я вважаю, дефрагментація індексів є значною частиною його призначення ) використовує ALGORITHM=INPLACEMySQL 5.7.4. Так що я думаю , що це так , що, так, COPY робить індекси дефрагментировать, але так самоINPLACE (як - то), зводить на немає його як потенційне перевагу COPY.

— Марк Амері

2

"Таблиці InnoDB, створені до MySQL 5.6, не підтримують ALTER TABLE ... ALGORITHM=INPLACEтаблиці, що містять тимчасові стовпці (DATE, DATETIME або TIMESTAMP) і не були відновлені за допомогою ALTER TABLE ... ALGORITHM=COPY" ... Обмеження Інтернет DDL

— JSapkota

10

Так, є випадки, коли ви можете вказати COPY, але це може бути з інших причин, ніж продуктивність.

Важливо розуміти, що MySQL представив нову функцію - Інтернет-обробку DLL у версії 5.6. Це не видалило офлайн-обробку. Тому існує необхідність розмежувати ці два режими:

Деякі операції все ще працюють лише в автономному режимі. Див. Таблицю 15.10, " Підсумок стану в Інтернеті для операцій DDL " для списку операцій DDL, які можна або не можна виконувати на місці.
Операції в режимах онлайн та офлайн мають дещо різну поведінку, тому ви можете вибрати "старий" з міркувань сумісності.

Деякі приклади (будь ласка, підкажіть більше):

InnoDB таблиці , створені до MySQL 5.6 не підтримує ALTER TABLE ... ALGORITHM=INPLACEдля таблиць , які включають в себе тимчасові стовпці ( DATE, DATETIMEабо TIMESTAMP) і не були реконструйовані з використанням ALTER TABLE ... ALGORITHM=COPY. У цьому випадку ALTER TABLE ... ALGORITHM=INPLACEоперація повертає помилку.
ADD PRIMARY KEYпункт COPY modeтихо перетворює NULLзначення за замовчуванням для цього типу даних (0 для INT, порожній рядок для varchar), тоді як IN_PLACEце не робить.

За допомогою пункту ALGORITHM = COPY операція успішна, незважаючи на наявність значень NULL у стовпцях первинного ключа; дані мовчки змінюються, що може спричинити проблеми.

Ще одна причина віддати перевагу COPY:

Операції, для яких ви вказуєте ALGORITHM = COPY або old_alter_table = 1, щоб примусити поведінку копіювання таблиць, якщо це потрібно для точної сумісності з зворотним ходом у спеціалізованих сценаріях.

Хоча керівництво MySQL не говорить про фактичні сценарії, ви можете їх уявити. Наприклад, розробник покладався на блокування таблиці під час ALTER INDEXроботи, тому таблиця є лише для читання або повністю заблокована, і існує процес, який читає статичну таблицю під час перебудови індексу.

— Stoleg
джерело

1

Я думаю, що люди також схильні плутати ALGORITHM=INPLACE"це онлайн DDL і не заблокує базу даних", адже вони насправді хочуть використовувати LOCK=NONE.

— Брендан Берд

2

@Stoleg, мабуть, має найкращу відповідь, але ось ще одна. Це здогадка, що розробники залишили, =COPYяк аварійний люк, на випадок серйозної помилки =INLINE. Це дозволить користувачам продовжувати користуватися, ALTERнавіть якщо нова функція порушена.

Я бачив такі речі (у прапорах sql_mode, my.cnfналаштуваннях тощо) протягом багатьох років. Наміром нового випуску є чітке виявлення нової, кращої, функції.

Прапори оптимізації потрапляють у цю категорію, але є ще більше причин зависати на попередні дії - Оптимізатор завжди "зробить неправильно"; можливостей занадто багато.

— Рік Джеймс
джерело

1

Чому б ви назвали це "люком втечі", а не "зворотною сумісністю"? Хоча різниці можуть бути не великі;)

— Stoleg

1

Я б сказав "зворотна сумісність", якби мені потрібен один і той же код для запуску в обох версіях. Але тоді я б потурбувався про те, чи визнано новий синтаксис старою версією.

— Рік Джеймс

-1

У версіях MySQL, які підтримують шифрування табличного простору InnoDB, коли ви змінюєте таблицю для додавання шифрування, зміна робиться за допомогою алгоритму копіювання з необхідності.

— nthdesign
джерело