Проблема с большими таблицами (первичный ключ недоступен) - PullRequest
2 голосов
/ 15 февраля 2012

Tabe1 имеет около 10 записей отсутствия (1 миллион) и не содержит первичного ключа. Получение данных с помощью команды SELECT (с определенным условием WHERE) занимает много времени. Можем ли мы сократить время поиска, добавив первичный ключ в таблицу, или нам нужно использовать любые другие способы сделать то же самое. Пожалуйста, помогите мне.

Ответы [ 5 ]

3 голосов
/ 15 февраля 2012

Первичный ключ не оказывает прямого влияния на производительность. Но косвенно это так. Это связано с тем, что при добавлении первичного ключа в таблицу SQL Server создает уникальный индекс (кластеризованный по умолчанию), который используется для обеспечения целостности объекта. Но вы можете создавать свои собственные уникальные индексы для таблицы. Таким образом, строго говоря, первичный индекс не влияет на производительность, но индекс, используемый первичным ключом, влияет.

КОГДА СЛЕДУЕТ ИСПОЛЬЗОВАТЬ ПЕРВИЧНЫЙ КЛЮЧ?

3 голосов
/ 15 февраля 2012

Первичный ключ необходим для ссылки на конкретную запись.

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

например. для ускорения SELECT * FROM "Customers" WHERE "State" = 'CA' необходимо создать индекс для столбца State.

1 голос
/ 15 февраля 2012

Primarykey не поможет, если у вас нет Primarykey для определения причины.

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

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

1 голос
/ 15 февраля 2012

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

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

Без дополнительной информации трудно быть более конкретным. На эту тему написано целых книг, в том числе:

0 голосов
/ 15 февраля 2012

Один из способов сделать это - create indexes на вашем столе.Всегда лучше создать первичный ключ, который создает уникальный индекс, который по умолчанию сокращает время поиска .........

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

Подробнее: Преимущества использования индексов в базе данных?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...