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

Question

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

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

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

есть предложения?

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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