Перестроить индекс для таблицы со 128 миллионами строк

У меня есть таблица базы данных с более чем 128 миллионами строк.

Проблема, с которой мне приходится иметь дело, - это индексы, база данных со временем работает очень плохо, я отчасти объясняю это фрагментацией индексов. Один из текущих индексов в большой таблице составляет около 50% общей фрагментации.

Реорганизация сделала около 1% за 1 час, так что это заняло бы слишком много времени.

На такой большой таблице переиндексация может занять до 5 часов, если не больше, и я не нашел реального способа отслеживать прогресс. Каким будет лучший и самый быстрый способ перестроить индекс для такой большой таблицы? Должен ли я установить базу данных как «OFFLINE»?

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

Мне также нужно обновить все остальные индексы в базе данных, но эта таблица — самая сложная.


mysql sql rebuild sql-server indexing
person Aki    schedule 11.07.2014    source источник
comment
Вы действительно измерили значительное улучшение производительности от перестроения индекса, проанализировав производительность до и после? Если да, то какова разница в производительности OLTP между свежим индексом и индексом, фрагментированным на 50%? Часто администраторы баз данных перестраивают индексы только потому, что считают, что это нужно делать. Индексы спроектированы так, чтобы в них было некоторое раздувание/фрагментация, и попытки их постоянной дефрагментации часто могут быть бесполезными.   -  person codenheim    schedule 11.07.2014
comment
Честно говоря, я не проводил настоящих тестов производительности между новым индексом и старым, все, что я знаю, это то, что часто после этого медленные запросы и отчеты, которые мы запускаем в нашей системе, становятся намного быстрее. Перестроение или реорганизация этой таблицы не проводились более 1 года. Я не знаком с термином OLTP, извините!   -  person Aki    schedule 11.07.2014
comment
@Aki: OLTP = онлайн-обработка транзакций. Рабочая нагрузка OLTP характеризуется большим количеством небольших операций чтения и сочетанием операций чтения/записи, что типично для базы данных, обслуживающей веб-сайт. Вы можете просто обновить статистику (что также делает перестроение индекса). Устаревшая статистика может привести к неоптимальным планам выполнения и, как следствие, снижению производительности.   -  person Dan Guzman    schedule 11.07.2014

Ответы (1)


arrow_upward
3
arrow_downward

Если вы не измерили следующие две вещи в этом конкретном индексе, у вас, вероятно, еще нет причин для перестроения.

  1. Насколько (если таковые имеются) ваши запросы на самом деле улучшаются сразу после перестроения.
  2. Как долго длится улучшение (т. е. сколько времени потребуется вашему индексу, чтобы вернуться к устойчивому состоянию фрагментации 50% после перестроения.

Индексы B-Tree предназначены для фрагментации/раздувания/свободного пространства. Индексы часто быстро возвращаются к своему устойчивому состоянию фрагментации. Они обычно хорошо работают в этом состоянии, склонны хотеть вернуться в устойчивое состояние.

person codenheim    schedule 11.07.2014
comment
Проблема в том, что у меня нет под рукой такой информации, поскольку мы не записывали предыдущие результаты прошлых перестроений. Есть ли способ узнать, требуется ли переиндексация без предыдущих результатов? - person Aki; 11.07.2014
comment
Вы должны измерить время запроса. Это именно моя точка зрения. Вы привержены чрезвычайно дорогой операции без доказательства ее преимуществ. Вы должны написать несколько тестовых запросов и засечь время до и после. В Google есть много информации о том, как профилировать запросы. - person codenheim; 11.07.2014