Когда индекс, который не стоит обновить

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

  1. Planing тщательно в деталях вперед. Особенно некоторая домашняя работа, что не может быть виртуализировано.

  2. Если поставщик приложения, работающего на Вашем сервере, не поддерживает виртуальную среду, ожидает, пока они не поддерживают.

  3. Реализуйте w/SAN как устройство хранения данных, хранящее все образы виртуальной машины.

  4. Выполненный ESX или ESX (i), или Hyper-V, для получения большей части производительности.

Возможно, больше, но это - все на данный момент.:)

[обновление] здесь - другой. Примените последнее встроенное микропрограммное обеспечение к хост-серверу. У меня был тот, который я не сделал, который дал мне фиолетовый экран однажды несколько дней и разрушил сервер полностью.

3
задан 14 October 2009 в 16:03
2 ответа

Я не думаю, что имеет смысл основывать решение о количестве одних только чтений/записей (если, конечно, Вы не читаете == 0, но затем почему у Вас есть таблица?:-)).

Полагайте что:

  • даже если существует немного чтений, они могут быть чрезвычайно трудоемкими без индекса
  • чтения могут быть более строго ограничены во времени, чем записи, таким образом, индекс мог бы стоить того несмотря на уменьшенную производительность записи
  • производительность записи не должна обязательно страдать; я предположил бы, что самый современный DBMS может задержать обновление индекса, пока это не необходимо, таким образом, например, много ВСТАВОК в последовательности должен только вызвать одно индексное обновление

Короче говоря, как всегда, единственный совет: профиль перед оптимизацией. Нет никакого легкого ярлыка :-/.

2
ответ дан 3 December 2019 в 06:51
  • 1
    Существуют, конечно, строки, возвращенные из заключенных в кавычки TSQL, которые имеют 0 чтений. Это только показывает, что индекс не использовался, не делает этого? Запрос на данные был необходим, но что конкретный индекс не использовался...? Сама таблица жизненно важна, но индексы, кажется, были созданы вроде " Хорошо это было похоже на хорошую идею во время "! 0 индексов чтения находятся, конечно, в списке для удаления. Что я, после то, сколько далее должно я переходить - в 1:1 точка..? –  Fatherjack 14 October 2009 в 17:35
  • 2
    А-ч извините, конечно, чтения относятся для индексации использования. –  sleske 14 October 2009 в 18:10

Чего Вы пытаетесь достигнуть? Вы пытаетесь улучшить i/o производительность? Вы испытываете нехватку дискового пространства? Преждевременная оптимизация является корнем всего зла!

Палка с быстрыми победами как 0 чтений и 100 000 000 записей. Все остальное - компромисс. Если Ваш сервер имеет высоту, но никакое дисковое пространство, то начните работать назад от самого низкого отношения чтений к записям и следите за производительностью.

Может быть более мудро исследовать другие альтернативы, такие как оптимизация процедур/запросов, добавив сжатие страницы, добавив дисковое пространство / ect RAM.

1
ответ дан 3 December 2019 в 06:51
  • 1
    Nick, мудрые слова наверняка. После того как я получаю шанс вернуться к базе данных (позже это пополудни или завтра) затем, 0 индексов чтений удаляются несомненно. Мое намерение состоит в том, чтобы оптимизировать базу данных, те индексы являются полной грузоподъемностью судна - приблизительно 2 ГБ полной грузоподъемности судна. 2 ГБ, которых мы копируем, копируют, зеркально отражают и так далее. У нас есть пространство жесткого диска, мы справляемся с пропускной способностью, время резервного копирования, ЦП и т.д., но если мы делаем что-то, что является тратой действия сервера I' d предпочитают не. В основном я хотел удовлетворить свой интерес в том, знал ли кто-то/использовал данное отношение как их сохранять/отбрасывать точку, которую я мог принять –  Fatherjack 15 October 2009 в 15:44

Теги

Похожие вопросы