Влияние Юникода на занимаемое пространство и производительность
SQL Server хранит данные в Юникоде с помощью схемы кодирования UCS-2. С помощью этого механизм все символы Юникода занимают 2 байта при хранении.
Разница в хранении символьных данных между Юникодом и кодовой страницей, отличной от Юникода, зависит от того, хранятся ли данные, не являющиеся данными Юникода, с использованием двухбайтовой кодировки. Все языки, не являющиеся восточноазиатскими, и тайский язык хранят символы, отличные от Юникода, как один байт. Следовательно, хранение этих языков в Юникоде занимает вдвое больше места, чем при указании кодовой страницы, отличной от Юникода. С другой стороны, кодовые страницы, отличные от Юникода, для многих других азиатских языков хранят символы в двухбайтовой кодировке (DBCS). Следовательно, для этих языков почти нет разницы в хранении между Юникодом и кодовой страницей, отличной от Юникода.
Следующая таблица показывает кодовые страницы, отличные от Юникода, указывающие хранение символов в двухбайтовой кодировке.
Язык |
Кодовая страница |
|---|---|
Китайский (упрощенный) |
936 |
Китайский (традиционный) |
950 |
Японский |
932 |
Корейский |
949 |
Влияние данных Юникода на производительность осложняется различными факторами, среди которых:
различие между правилами сортировки в Юникоде и кодовой страницей, отличной от Юникода;
различие между сортировкой двухбайтовых и однобайтовых символов;
преобразование кодовой страницы между клиентом и сервером.
SQL Server производит строковое сравнение данных в кодовой странице, отличной от Юникода, определенное параметрами сортировки Windows, с использованием правил сортировки Юникода. Поскольку эти правила более сложны, чем правила сортировки, отличной от Юникода, они потребляют больше ресурсов. Поэтому, несмотря на то, что правила сортировки данных в Юникоде часто более затратны, обычно есть лишь малая разница в производительности между данными в Юникоде и данными, не в Юникоде, определенными параметрами сортировки Windows.
Единственный случай, когда SQL Server использует правила сортировки кодовой страницы, отличной от Юникода, — с данными, отличными от кодовой страницы в Юникоде, определенными с использованием параметров сортировки SQL. Сортировка и сканирование на этом экземпляре обычно происходят быстрее, чем при применении правил сортировки Юникода. Правила сортировки Юникода применяются ко всем данным в Юникоде, определенным с использованием параметров сортировки либо Windows, либо SQL.
Что тоже важно, сортировка большого объема данных в Юникоде может быть медленнее, чем данных, отличных от Юникода, так как данные хранятся в двух байтах. С другой стороны, сортировка азиатских символов в Юникоде быстрее, чем сортировка азиатских данных в DBCS по конкретной кодовой странице, так как данные DBCS являются смесью однобайтовых и двухбайтовых, тогда как длина символов в Юникоде фиксирована.
Другие вопросы производительности в основном определены вопросом преобразования механизма кодировки между экземпляром SQL Server и клиентом. Обычно влияние преобразования кодовой страницы между клиентом и сервером на производительность крайне незначительно. Но все равно следует понимать, что происходит на этом уровне.
ODBC API версии 3.6 или более ранней и API библиотеки баз данных не распознают Юникод. В клиентах, использующих методы доступа к данным, определенные этими API, ресурсы используются для скрытого преобразования данных в Юникоде в соответствии с кодовой страницей клиента. Кроме того, есть риск повреждения данных на стороне клиента, когда кодовая страница клиента не распознает некоторые символы в Юникоде.
Последние версии ODBC, начиная с Microsoft Data Access Components версии 2.7, включенной в SQL Server версии 7.0, OLE DB и ADO распознают Юникод и применяют механизм кодировки UCS-2. Следовательно, если приложение распознает Юникод, то при работе строго с данными в Юникоде с экземпляра SQL Server проблем с преобразованием нет. Если клиент использует распознающий Юникод API, но механизм хранения данных на экземпляре SQL Server работает не в Юникоде, проблем с преобразованием нет. Однако есть риск, что любая операция по вставке или обновлению данных будет повреждена, если код указывает на любой символ, который не может быть сопоставлен с кодовой страницей SQL Server.
Оптимальные методы работы с Юникодом
Решение о том, следует ли хранить данные, не являющиеся данными DBCS, в виде данных Юникода обычно зависит от знания, как это влияет на хранение и сколько ошибок при сортировке и преобразовании и повреждений данных может иметь место при взаимодействии клиента с данными. Сортировка и преобразование могут повлиять на производительность в зависимости от того, где они происходят. Однако для большинства приложений это влияние незначительно. Базы данных с хорошо разработанными индексами менее всего могут быть затронуты. Однако повреждение данных повлияет не только на целостность приложения и базы данных, но и на весь бизнес. Учитывая соотношение выгод и потерь, хранение символьных данных в конкретной кодовой странице имеет смысл только при выполнении следующих двух условий.
Экономия пространства хранения является важным вопросом из-за ограничений аппаратуры. Или проводятся частые сортировки больших объемов данных, и тестирование показывает, что механизм хранения Юникода серьезно влияет на производительность.
Есть уверенность, что кодовые страницы всех клиентов, имеющих доступ к данным, совпадают со страницей, используемой для данных, и что эта ситуация не изменится неожиданно.
В большинстве случаев решение хранить символьные данные, даже данные, не являющиеся данными DBCS, в Юникоде должно основываться более на бизнес-требованиях, чем на производительности. В глобальной экономике, поддерживаемой быстрым ростом трафика в Интернете, важно как никогда поддерживать клиентские компьютеры, работающие в разных языковых стандартах. Кроме того, сейчас все труднее выбрать одну кодовую страницу, поддерживающую все символы, необходимые для всемирной аудитории.