Я разрабатываю индексы на основе возможных сценариев запросов.Какие наиболее распространенные запросы будут выполняться к таблице?Это должно повлиять на дизайн индекса - как для оптимизации производительности запросов, так и для минимизации накладных расходов на вставку / обновление / удаление.
Например, простое создание кластерного индекса по первичному ключу может иметь смысл в теоретическом мире.спереди, но не может отражать реальную загрузку запроса.
Например: что, если у вас есть таблица элементов заказа, где 0-n элементов заказа связаны с родительским заказом?Вы просто создаете столбец идентификатора элемента заказа, назначаете его первичным ключом и записываете свой кластеризованный индекс, даже если в реальном мире 90% ваших запросов по этой таблице будут «получать элементы заказа для xyz заказа», подразумевая, чтоКластерный индекс для идентификатора родительского заказа может иметь больше смысла, чем кластерный индекс первичного ключа «по умолчанию» для идентификатора позиции заказа?
Вы можете сделать это заранее, зная, какие сценарии будет включать ваше приложение.Затем вы также можете делать трассировки в реальном мире и анализировать их, чтобы найти, где вам не хватает индексов;SQL Server, например, поставляется с инструментами для этого, есть и сторонние инструменты.Одна из техник, которую я иногда использую, - это сделать большую трассировку, загрузить информацию трассировки в таблицу и запросить ее для различных операторов SQL (на основе каких-либо критериев ... например, дать мне все ОБНОВЛЕНИЯ для таблицы xyz ...), а затемвы можете составить план запроса для этих операторов и посмотреть, насколько хороша ваша индексация, например, путем поиска и адресации таблицы или сканирования индекса соответствующим образом - и проверки путем повторного изучения плана выполнения для запроса.
Некоторые предостережения ... не применяйте индексы по воле следа.Индекс в таблице повлияет на общую производительность всех запросов к таблице.Не думайте, что сканирование таблицы или индекса (а не поиск) обязательно плохо;это не имеет значения в таблице из десяти строк.Оптимизация индекса - это сочетание науки и искусства, поэтому очень важно сохранять его простым, часто проводить тестирование после небольших постепенных изменений - это хороший способ сохранить здравый смысл и иметь возможность часто выполнять откат, и, прежде всего, при наличии набора изменений,запишите их так, чтобы у вашего администратора базы данных был точный протокол того, что будет сделано, и он мог легко определить, куда / что откатиться, если это необходимо.