Сравнение Sql Server int и nvarchar по производительности?
для вас дизайн базы данных / производительность гуру там.
Я разрабатываю таблицу, у меня есть выбор использовать int или nvarchar (128) для столбца, предположим, что пространство не является проблемой. Мой вопрос в том, что даст производительность
при поиске с помощью столбца int
where ID = 12324
или когда я ищу с столбцом nvarchar (ключ-это все значение, поэтому я не использую оператор LIKE)
where Key = 'my str'
Я уверен, что для меньшие наборы данных не имеют значения, но предположим, что эти данные будут в миллионах строк.
4 ответов
INT будет быстрее-вот почему:
- SQL Server организует свои данные и индекс в страницы 8K
- Если у вас есть страница индекса с ключом INT на нем, вы получаете примерно 2 ' 000 записей INT
- Если у вас есть NVARCHAR (128), и вы используете в среднем 20 символов, это 40 байт на запись или примерно 200 записей на страницу
таким образом, для того же количества записей индекса случай NVARCHAR (128) будет использовать в десять раз больше индекса страницы.
загрузка и поиск этих страниц индекса потребует значительно больше операций ввода-вывода.
так коротко: Если вы можете, всегда использовать int .
пространство всегда проблемы в базах данных. Более широкие ключи означают меньше записей на страницу, больше страниц, отсканированных для агрегирования и суммирования значений, больше ввода-вывода, меньше производительности. Для кластеризованных индексов эта проблема умножается на каждый некластеризованный индекс, поскольку они должны воспроизводить ключ поиска (кластеризованный ключ) в своих листах. Итак, ключ типа nvarchar(128) будет почти всегда быть хуже, чем INT.
С другой стороны, не используйте клавишу INT, если это не так соответствующий. Всегда используйте соответствующий ключ, учитывая ваши запросы. Если вы всегда собираетесь запрашивать значение столбца nvarchar (128), то это возможно хороший кластерный ключевой кандидат. Если вы собираетесь совокупность ключом nvarchar (128), то есть скорее хороший кластерный ключевой кандидат.
основной проблемой с производительностью при этом является размер поля-an int составляет 4 байта, тогда как nvarchar(128) будет 254 байта.
все это должно управляться SQL server, поэтому управление int будет намного быстрее, чем nvarchar(128).
Я бы использовал int для производительности (если это будет иметь соединения особенно) и поставил уникальный индекс на потенциальный естественный ключ для целостности данных.