Переваги запуску запиту OPTIMIZE TABLE в MySQL DB Server


9

Я хотів би знати, які переваги [насправді практичні], які можна отримати, запустивши OPTIMIZE TABLE tbl_nameзапит у MySQL Server.

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

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

Відповіді:


7

Майте на увазі, що ОПТИМІЗАЦІЯ ТАБЛИЦЯ не виконує дефрагментацію. Внутрішньо OPTIMIZE TABLE виконує кілька операцій (копіювання даних у тимчасовий файл, відтворення індексів, перерахування статистики індексу). Насправді, приклад, який я маю, можна виконати вручну, як показано.

Приклад: Якщо ви оптимізуєте mydb.mytable, вводите цю команду:

OPTIMIZE TABLE mydb.mytable;

Зауважте, що mysql виконує щось наступне під кришкою:

CREATE TABLE mydb.mytable2 LIKE mydb.mytable;
ALTER TABLE mydb.mytable2 DISABLE KEYS;
INSERT INTO mydb.mytable2 SELECT * FROM mydb.mytable;
ALTER TABLE mydb.mytable2 ENABLE KEYS;
DROP TABLE mydb.mytable;
ALTER TABLE mydb.mytable2 RENAME mydb.mytable;
ANALYZE TABLE mydb.mytable;

Це досить корисно для таблиць із великим обсягом ОНОВЛЕННЯ та ВИДАЛЕННЯ

Виконуючи це, можна досягти двох речей

  1. Не дозволяйте mysql переглядати фрагменти таблиці, намагаючись завантажити дані у потрібні розміри. Усунення цих фрагментів зменшить цю операцію.

  2. Перерахування статистики індексу допомагає оптимізатору запитів MySQL побудувати кращі плани EXPLAIN. В іншому випадку запити можуть погіршитися у часі виконання, оскільки оптимізатор запитів MySQL вирішив погано здогадуватися в плані EXPLAIN. Це було б певним симптомом таблиці, яка мала велику кількість ОНОВЛЕННЯ та УДАЛЕННЯ.

КАВАТИ

Що стосується кешування, кешування швидко занурюється через сканування повного столу. Для індексованих сторінок MyISAM виходять і виходять із кешу клавіш MyISAM. Для InnoDB дані та покажчикові сторінки витікають із та в пул InnoDB Buffer.


Дякуємо за Ваш відповідь. З вашої точки зору, я розумію, що я краще користуюся якоюсь послугою, як роботою cron, для планування оптимізації таблиці для моєї часто оновлюваної таблиці, щоб я міг досягти кращих показників. Крім цього, я використовую InnoDB для цієї таблиці. Це кращий вибір. Крім того, я знаходжу HASH приєднується до SQL Server, який було запропоновано з метою покращити продуктивність запитів, чи можете ви пояснити це мені та як отримати подібний до цього в MySQL. Також будь ласка, дайте мені оптимізатор запитів SQL для MySQL [версія Windows7].
Сараванан

@savaranan: Оптимізатор запитів MySQL, про який я говорив, - це внутрішній, вбудований у MySQL. BTW Оскільки таблиця, яку ви хочете оптимізувати, є InnoDB, ви можете пропустити кроки DISABLE KEYS та ENABLE KEYS. Крім того, ANALYZE TABLE можна пропустити, оскільки він абсолютно марний на таблицях InnoDB, оскільки InnoDB перераховує свої основні таблиці шляхом близьких наближень за допомогою сторінок з індексів BTREE, відомих як дайвинг індексів.
RolandoMySQLDBA

@savaranan: Що стосується індексів HASH, InnoDB має адаптивні хеш-індекси ( dev.mysql.com/doc/refman/5.5/uk/innodb-adaptive-hash.html ). Також є приємні пропозиції щодо емуляції власних хеш-індексів та обробки зіткнень на сторінках 103-106 "Високопродуктивного MySQL" ( amazon.com/dp/0596101716 )
RolandoMySQLDBA
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.