это может уменьшить размер таблиц и индексов (выделение добавлено)
Уменьшение размера возможно только , если большинство персонажей, по существу [space]
, 0 - 9
, A - Z
, a - z
, и некоторые основные знаки препинания. За пределами этого конкретного набора символов (в терминах практического использования, стандартных значений ASCII 32–126) вы будете в лучшем случае равны по размеру NVARCHAR
/ UTF-16 или во многих случаях больше.
Я планирую перенести данные, так как считаю, что чтение меньшего количества данных вообще приведет к повышению производительности системы.
Быть осторожен. UTF-8 - это не волшебный переключатель «все исправить». При прочих равных условиях, да, чтение меньше улучшает производительность. Но здесь «все остальные вещи» не равны. Даже при хранении только стандартных символов ASCII (то есть: все символы имеют длину 1 байт, что требует вдвое меньше места по сравнению с сохранением в NVARCHAR
), существует небольшое ухудшение производительности при использовании UTF-8. Я полагаю, что проблема связана с тем, что UTF-8 является кодировкой переменной длины, что означает, что каждый байт должен интерпретироваться так, как он читается, чтобы узнать, является ли он полным символом или является ли следующий байт его частью. Это означает, что все строковые операции должны начинаться с начала и проходить побайтово. С другой стороны,NVARCHAR
/ UTF-16 всегда составляет 2 байта (даже дополнительные символы состоят из двух 2-байтовых кодовых точек), поэтому все можно прочитать в 2-байтовых фрагментах.
В моем тестировании, даже с использованием только стандартных символов ASCII, сохранение данных в формате UTF-8 не дало экономии прошедшего времени, но было определенно хуже для процессорного времени. И это было без сжатия данных, поэтому, по крайней мере, было использовано меньше дискового пространства. Но при использовании сжатия пространство, необходимое для UTF-8, было только на 1% - 1,5% меньше. Таким образом, экономия места не достигается, а время процессора увеличивается для UTF-8.
Ситуация усложняется при использовании, NVARCHAR(MAX)
так как сжатие Unicode не работает с этим типом данных, даже если значение достаточно мало для хранения в строке. Но если данные достаточно малы, они все равно должны извлечь выгоду из сжатия строк или страниц (в этом случае они действительно становятся быстрее, чем UTF-8). Однако данные вне строки не могут использовать сжатие. Тем не менее, сделав таблицу Clustered Columnstore Index, вы значительно уменьшите размер NVARCHAR(MAX)
(даже если он все еще немного больше, чем UTF-8 при использовании Clustered Columnstore Index).
Кто-нибудь может указать сценарий и причину, чтобы не использовать типы данных char с кодировкой UTF
Определенно. На самом деле, я не вижу убедительной причины использовать его в большинстве случаев. Единственный сценарий, который действительно выигрывает от UTF-8, это:
- Данные в основном стандартные ASCII (значения 0 - 127)
- Это должен быть Unicode, потому что может потребоваться хранить более широкий диапазон символов, чем доступно на любой 8-битной кодовой странице (т.е.
VARCHAR
)
- Большая часть данных хранится вне строки (поэтому сжатие страниц даже не работает)
- У вас достаточно данных, которые вам нужно / вы хотите уменьшить размер по причинам, не связанным с производительностью запросов (например, уменьшить размер резервной копии, сократить время, необходимое для резервного копирования / восстановления и т. Д.)
- Вы не можете использовать Clustered Columnstore Index (возможно, использование таблицы ухудшает производительность в этом случае?)
Мои тесты показывают, что почти во всех случаях NVARCHAR работал быстрее, особенно когда данных было больше. Фактически, для 21 тыс. Строк со средним объемом 5 тыс. Символов на строку требуется 165 МБ для UTF-8 и 236 МБ для NVARCHAR
несжатого. И все же он NVARCHAR
был в 2 раза быстрее по прошествии времени и, по крайней мере, в 2 раза быстрее (иногда больше) времени процессора. Тем не менее, это заняло еще 71 МБ на диске.
Помимо этого, я все еще не рекомендовал бы использовать UTF-8, по крайней мере, для CTP 2, из-за множества ошибок, которые я обнаружил в этой функции.
Для подробного анализа этой новой функции, включая объяснение различий между UTF-16 и UTF-8, и список этих ошибок, пожалуйста, смотрите мой пост:
Встроенная поддержка UTF-8 в SQL Server 2019: Спаситель или Лжепророк?