Когда необходимо рассмотреть индексацию sql таблиц?
Я обнаружил, что @Publisher публикует дважды из-за конфигурации в ExampleConfig. Эта новая конфигурация (заимствованная из здесь ), кажется, работает нормально:
@Bean
public static BeanFactoryPostProcessor bfpp() {
return bf -> bf.getBean(IntegrationContextUtils.PUBLISHER_ANNOTATION_POSTPROCESSOR_NAME,
PublisherAnnotationBeanPostProcessor.class).setProxyTargetClass(true);
}
8 ответов
Нет никакого серьезного основания предшествовать очевидным индексам (FKs, и т.д.), когда Вы составляете таблицу. Это никогда не будет заметно влиять на производительность, чтобы иметь ненужные индексы на крошечных таблицах, и хорошо взять первое сокращение, когда Ваш ум в дизайн схемы. Кроме того, некоторые индексы служат для предотвращения дубликатов, которые могут быть полезными независимо от размера таблицы.
Я предполагаю, что надлежащий ответ на Ваш вопрос - то, что количество записей в таблице должно не иметь никакого отношения, когда создать индексы.
Я создал бы элементы индекса, когда я составляю свою таблицу. Если Вы решаете создать индексы после того, как таблица выросла до 100, 1000, 100 000 записей, она может просто занять много времени и возможно сделать Вашу базу данных недоступной при выполнении ее.
Думайте о таблице сначала, создайте индексы, Вы думаете, что будете нуждаться и затем идти дальше.
В некоторых случаях Вы обнаружите, что необходимо было индексировать столбец, если это так, зафиксируйте его при обнаружении его.
Создание индекса на искавшем поле не является предварительной оптимизацией, ее, что должно быть сделано.
Когда время запроса недопустимо. Еще лучше создайте несколько индексов теперь, когда, вероятно, будут полезны, и выполнят ОБЪЯСНЕНИЕ или ОБЪЯСНЯТ, АНАЛИЗИРУЮТ на Ваших запросах, после того как Ваша база данных заполняется представительными данными. Если индексы не помогают, отбрасывают их. Если существуют медленные запросы, которые могли бы извлечь выгоду из больше или различные индексы, изменить индексы.
Вы не собираетесь быть привязанными к начальному выбору индексов. Эксперимент, и удостоверяется, что Вы измеряете уровень!
В целом я соглашаюсь с предыдущим советом. Всегда объявляйте ссылочную целостность для таблиц (Первичный ключ, Внешние ключи), ограничения столбца (не пустой, проверка). Сохраняет Вас от кошмаров, когда приложения помещают неправильные данные в таблицы (даже в разработке). Я рассмотрел бы добавляющие индексы для общих столбцов доступа (столбцы в Вашем, где пункты, которые используются в =, <> тесты), также. Большинство современных реализаций RDBMS довольно хорошо в хранении, Вы индексируете актуальный, не поражая Вашу производительность. Так, стоимость наличия индексов минимальна. Кроме того, большая часть RDBMS имеют средства анализа плана запросов, которые смотрят на относительные затраты, идущие в строки данных через индекс или использующие своего рода сканирование таблицы. Так, снова хиты производительности минимальны.
Это зависит.
Сколько данных находится в таблице? Как часто данные вставляются? Много индексов может замедлить время вставки. Вы всегда запрашиваете все строки таблицы? В этом случае индексы, вероятно, не помогут многому.
Это не общее использование все же. В большинстве случаев Вы знаете, что собираетесь быть запросами подмножества данных. НА какой поля? Есть ли общие поля, на которых всегда присоединяются? Взгляд на планы запросов для общих или типичных запросов, это будет обычно показывать Вам, где это проводит все свое время.
Два.
Я серьезен. Если существует две строки теперь, и всегда будет две строки, стоимость индексации является почти нулем. Это более быстро для индексации, чем обдумать, должны ли Вы. Это не будет брать оптимизатор очень долго, чтобы выяснить, что сканирование таблицы более быстро, чем использование индекса.
Если существует две строки теперь, но будет 200,000 в ближайшем будущем, стоимость не индексации могла стать непомерно высокой. Правильное время для рассмотрения индексации теперь.
Сказав это, помните, что Вы получаете индекс автоматически, когда Вы объявляете первичный ключ. Составление таблицы без первичного ключа напрашивается на неприятности в большинстве случаев. Так единственное время действительно необходимо полагать, что индексация состоит в том, когда Вы хотите индекс кроме индекса на первичном ключе. Необходимо знать, что трафик и ожидаемый объем выполняют этот вызов. Если Вы поймете его превратно, то Вы будете знать, и можно инвертировать решение.
Я однажды видел ссылочную таблицу, которая была составлена без индекса, когда он содержал 20 строк. Из-за бизнес-изменения, эта таблица выросла приблизительно до 900 строк, но человек, который должен был заметить отсутствие индекса, не сделал. Время для вставки нового порядка выросло приблизительно с 10 секунд до 15 минут.
Как стандартную программу я выполняю следующий чтение тяжелые таблицы:
- Создайте индексы на общих объединяющих полях, таких как Внешние ключи, когда я составлю таблицу.
- Проверьте план запросов на Представления или Хранимые процедуры и добавьте индексы везде, где сканирование таблицы обозначается.
- Проверьте план запросов на запросы моим приложением и добавьте индексы везде, где сканирование таблицы обозначается. (и часто пытайтесь превратить их в Хранимые процедуры),
На записи тяжелые таблицы (как журналы операций) я избегаю индексов, если они не абсолютно необходимы. Я также склонен архивировать такие данные в индексированные таблицы равномерно.
Если будет ограничение на уникальность данных на таблицу (и должен быть по крайней мере один), то это будет обычно осуществляться уникальным индексом.
Иначе Вы добавляете индексы, когда производительность запросов будет плоха и добавляет, что индекс очевидно улучшит производительность. Существуют книги на предмет того, как создать хорошие наборы индексов на таблицах, включая Индексный Дизайн Реляционной базы данных и Оптимизаторы. Это даст Вам много идей и причин, почему они хороши.
См. также:
- Никакие индексы на маленьких таблицах
- Когда создать новый индекс SQL Server
- Лучшие практики и антишаблоны в создании индексов
и, несомненно, хост других.