Техническое обслуживание баз данных, оптимизация больших двоичных таблиц

Question

У меня есть огромная база данных размером около 1 ТБ, большая часть пространства потребляется таблицей, в которой хранятся изображения, а таблицы имеют сейчас почти 800 тыс. Строк.

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

, к каждой строке обращается столбец идентификатора изображения, и он имеет свой кластеризованный индекс по этому столбцу, и каждые два дня я реорганизую индекс и каждые 7 дней его перестраиваю, но, похоже, для работы

любые предложения?

Answer 1

Если таблица кластеризована с помощью image_id, и вы всегда получаете доступ к файлу image_id, размер таблицы не имеет значения, и так же фрагментация (нет необходимости перестраивать).

Если вы видите снижение производительности, то в игре больше всего будет что-то другое. Вы проводите сканирование диапазона? Посмотрите в sys.dm_db_index_usage_stats, отличается ли столбец user_scans от 0? Это означает, что у вас есть запросы, которые выполняют сканирование.

Если вы не измеряете , где время увеличивается, вы будете снимать пробелы в темноте и никогда не будете правильно решать проблему. Примените методологический подход, например Waits and Queues, чтобы определить проблему.

Единственное, что я могу вам сказать прямо сейчас: Разделение - это никогда улучшение производительности. Он предназначен для обслуживания данных (включение/выключение) и для распределения нагрузки на контролируемый режим в файловых группах. Но вы никогда не можете ожидать разделения на улучшить производительность, вы можете в лучшем случае надеяться на равную производительность с помощью несегментированной таблицы.

Answer 2

Если время отклика увеличивается, вы должны делать больше с этой таблицей, чем просто потянуть изображения для идентификаторов?

Какие еще столбцы данных хранятся в вашей таблице изображений?

Если у вас есть сгруппированный индекс на идентификаторе (вероятно, идентичность), это нормально, но, возможно, поможет добавить дополнительный некластеризованный индекс, который может покрывать критерии поиска.

Скажем, у вас также есть столбцы для имени или тега или региона или что-то еще в этой таблице изображений (и если вы не собираетесь вертикально разбивать эту таблицу на отдельные таблицы), то с некластеризованным индексом на теге id INCLUDE (имя), скажем, или что-то, что соответствует вашим шаблонам использования, поможет много.

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