Изменение механизма хранения по умолчанию Amazon RDS MariaDB

У меня есть сотни больших таблиц, которые я перенес в RDS MariaDB из своей базы данных MySQL (используя службу миграции Amazon). Все механизмы хранения перешли с MyISAM на InnoDB. Это катастрофически сказывается на производительности.

Короче говоря, я хочу изменить механизм хранения по умолчанию на MyISAM, а затем повторно перенести все таблицы. Я открыт для любых других идей о том, как это сделать (например, с использованием какой-либо настройки в инструменте миграции). Я действительно не хочу создавать сценарий для их изменения, потому что это означает, что мне нужно будет делать это каждый раз, когда я импортирую данные.

Я пытался изменить ParameterGroup default_storage_engine, но когда я захожу в ParameterGroup для экземпляра, который я запускаю, механизм хранения по умолчанию отображается как доступный только для чтения.Снимок экрана консоли AWS

Я также пытался создать новую группу параметров, и происходит то же самое. Значение отображается как «модифицируемое: false».

Любая помощь очень ценится. Я просмотрел другие ответы, но не думаю, что изменение my.cnf имеет отношение к RDS. Если это так, пожалуйста, дайте мне знать.


mysql amazon-web-services mariadb rds myisam
person Jason Hitchings    schedule 23.09.2017    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Очевидно, RDS не позволяет вам изменить этот параметр.

Вы можете изменить каждую из своих таблиц на MyISAM по одной:

ALTER TABLE MyTable ENGINE=MyISAM;

Вы можете получить список своих таблиц, которые необходимо изменить:

SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE='InnoDB';

Для будущих таблиц не полагайтесь на механизм по умолчанию. Создавайте таблицы с явно указанным движком в операторе CREATE TABLE.

Однако я бы предостерег вас: MySQL постепенно отказывается от MyISAM. Он не поддерживает одновременную запись, блокировку на уровне строк, транзакции или атомарные изменения. Снова и снова показано, что InnoDB превосходит MyISAM по производительности, за исключением очень немногих случаев:

  • SELECT COUNT(*) FROM MyTable; потому что MyISAM сохраняет эту статистику встроенной в каждую таблицу. По общему признанию, это большая слабость InnoDB или любой архитектуры MVCC.
  • Табличные сканы. Но в любом случае вам не следует выполнять сканирование таблиц, вы должны выполнять поиск по индексу. Оптимизированный запрос к InnoDB, как правило, будет намного лучше с точки зрения производительности, чем сканирование таблицы с помощью MyISAM.

Я бы посоветовал вам разобраться с оптимизацией запросов и придерживаться InnoDB.

person Bill Karwin    schedule 23.09.2017
comment
MyISAM также настоятельно не рекомендуется документами RDS, поскольку он, по-видимому, принципиально несовместим с механизмами, лежащими в основе резервного копирования моментальных снимков RDS и восстановления на определенный момент времени. похожее на сбой состояние, которое возникает, когда MySQL впервые просыпается после восстановления из резервной копии, созданной с помощью моментального снимка диска. Таблицы MyISAM не справятся с этим. (Неподтвержденные наблюдения показывают, что восстановление на определенный момент времени и моментальных снимков в RDS, по-видимому, проходит через аварийное восстановление при запуске.) - person Michael - sqlbot; 23.09.2017

arrow_upward
0
arrow_downward

Распространенная проблема с производительностью при внезапном переключении на InnoDB связана с «транзакциями».

Вероятно, произошло то, что каждый запрос стал отдельной транзакцией, потому что autocommit = ON. (Не поворачивайте его OFF, это приведет к еще большим проблемам.) Вам нужно понимать транзакции, по крайней мере, достаточно, чтобы объединять операторы вместе в такие блоки, как

BEGIN;
multiple statements, usually more than one, but not a huge number
COMMIT;

Это (во многих случаях) восстановит потерянную производительность.

Подробнее о конверсии читайте здесь .

person Rick James    schedule 23.09.2017