есть ли способ ограничить индексацию таблиц Mysql, чтобы не повлиять на общую производительность?

Ну, я так и не нашел способ дросселировать, но я нашел способ облегчить свою проблему. Решение было уникальным для моей проблемы, но я опубликую его на случай, если кто-то еще сочтет его полезным.

Я написал класс с именем CautiousIndexer.

1. Сначала я сохранил оператор создания таблицы, чтобы воссоздать структуру таблицы без индексов. Я сохранил массив прочитанных подчиненных баз данных, перебрал их, переименовав таблицу с неиндексированными данными в prevent_indexing_($name).
2. Затем я запустил оператор создания таблицы только на ведомых устройствах. Это эффективно убрало данные с пути операторов индексации, которые могли бы произойти на мастере.
3. Затем я выполнил индексный запрос к мастеру. Ведомые устройства чтения не влияли на производительность, пока мастер выполнял индексацию, поскольку вновь созданные таблицы были пустыми.
4. Когда мастер закончил индексирование, я вывел 1 из подчиненных устройств из ротации производства, удалил пустую таблицу, вернул полную таблицу на место, а затем проиндексировал таблицу на снятом с производства подчиненном устройстве.
5. Когда это закончилось, я вернул его в производство и повторил процедуру индексации ведомых устройств на оставшихся ведомых устройствах.
6. Когда все ведомые устройства были проиндексированы, я запустил таблицу в производство.

Это все еще было хорошо с точки зрения эффективности, но во время индексации на главном сервере производительность записи недопустимо снижалась. Все еще ищу способ индексации с дросселированием.

Хорошим решением этой проблемы является сценарий, выполняющий непрерывное обновление. Вы примените индекс к каждому ведомому устройству без репликации. Грубая иллюстрация:

for host in $hosts
do
    mysql -h $host -e "STOP SLAVE;\
      SET sql_log_bin=0;\
      FLUSH TABLE t;\
      ALTER TABLE t ADD INDEX a (b,c);\
      SET sql_log_bin=1;\
      START SLAVE;"
done

Отключив репликацию, следует уменьшить объем дисковой активности и увеличить скорость операции индексирования. Если у вас есть требования к задержке базы данных для ваших ведомых устройств, вы можете полностью исключить ведомое устройство из пула и включить логику для повторного пула ведомого устройства, когда оно возобновляет отставание в 0 секунд.

Это не то решение, которое вам нужно, но вы можете найти второй экземпляр mysqld в качестве ведомого на этом единственном компьютере и перенаправить SELECT запросы к нему по мере необходимости. Существует прокси-сервер MySQL, который может помочь вам в этом. без перезаписи клиентских приложений.

Вы также можете почерпнуть некоторые идеи из использования MySQL в FriendFeed. Они хранят фактические индексы в других таблицах и используют их для поиска. Если вы сохраните копию своих данных в другой таблице даже на другом сервере и запустите индексы там, вы сможете получить доступ к основным данным как можно скорее на полной скорости и получать более быстрые запросы позже, используя другой сервер.

Это похоже на добавление индексов на подчиненном устройстве для поисковых запросов и выполнение только поиска по первичному ключу на главном устройстве.

Идея, которую вы не пробовали раньше, также не касается регулирования индекса, что, если вы сделаете резервную копию таблицы и обновите ее так, как вы упомянули, имеет более короткий промежуток времени, а затем преобразует/переименует таблицы. Я призываю писать свои мысли, потому что вам нужно знать способ.

Вы можете отключить любые неуникальные индексы во время вставки и снова включить их после завершения. Взгляните на ключи отключения / включения ключей. Но это работает только для неуникальных индексов.

Вы также можете ускорить вставку, если используете операторы вставки с несколькими значениями (вставьте в таблицу (...) значения (...), (...), (...)...

Кстати, загрузка файла данных кажется самым быстрым способом вставки большого количества данных в mysql.

Вы пытались увеличить настройки индекса для импорта? Это может значительно увеличить производительность импорта. sort_buffer_size — для любого типа таблицы, myisam_sort_buffer_size — для таблиц MyISAM. innodb_buffer_pool_size — это своего рода «кеш ключей» для Innodb. Поднимите их для импорта в зависимости от типа вашей таблицы. То, что вы пытаетесь сделать, это избежать сортировки файлов во время создания индекса.

Вы можете сократить время импорта/индексирования до 10-15 минут или меньше. Это не троттлинг, но значительно сократит период воздействия.

Или, если вы используете таблицы MyISAM, возможно, вам подойдет таблица MERGE? Создайте новую таблицу, выполните импорт, затем добавьте новую таблицу в таблицу MERGE. Во время импорта не будет никакого влияния на базу данных. Помимо выполнения сервером задачи.