Провели замеры на типичных пользовательских операциях из клиента.
Усредненно выборки по таблицам с General_Latin1_1251_CI_AS быстрее чем Cyrilic_General_CI_AS на 30%.
если неиспользование table scan вместо индекса при General_Latin1_1251_CI_AS по описаниям должен побеждаться вводом на сервере вычисляемого поля вида TERTIARY_WEIGHTS(TEXT_FIELD1) и индексами по нему,
то для таблиц в Cyrilic_General_CI_AS помогает ввод вычисляемых доп. полей вида InventDimID_fast = (InventDimID collate General_Latin1_1251_CI_AS), и использования их в Like и т.п.
например,
Цитата:
select *
from SalesPickingListJournalLine (nolock)
where TST_01 like '%01Д0002320%'
быстрее чем
Цитата:
select *
from SalesPickingListJournalLine (nolock)
where PickingListId like '%01Д0002320%'
в 7 раз (40-50мс против 330-340)
при
Цитата:
[dbo].[SALESPICKINGLISTJOURNALLINE](
...
[PICKINGLISTID] [varchar](100) COLLATE Cyrillic_General_CI_AS NOT NULL CONSTRAINT DEFAULT (''),
...
[TST_01] AS ([PickingListId] collate SQL_Latin1_General_CP1251_CI_AS)
) ON [PRIMARY]
Да и JOIN'ы при SQL_Latin1_General_CP1251_CI_AS быстрее, например,
Цитата:
select top 1 *
from SalesPickingListJournalLine l (nolock) join SalesPickingListJournalTable t (nolock) ON l.TST_01 = t.TST_01
order by t.TST_01
быстрее чем
Цитата:
select top 1 *
from SalesPickingListJournalLine l (nolock) join SalesPickingListJournalTable t (nolock) ON l.PickingListId = t.PickingListId
order by t.PickingListId
вдвое (без order by тоже быстрее, но на 15%, в SalesPickingListJournalTable тоже добавлено вычисляемое поле [TST_01] AS ([PickingListId] collate SQL_Latin1_General_CP1251_CI_AS))
Жаль, что только до первой синхронизации только помогут эти методы, конечно...
Вот такой вот неординарный способ повышения производительности, получается - хранить данные в устаревшем collation...
Жаль, никто не повторил опытов...
да и на sql.ru тоже интереса не проявилось пока - то ли все про это давно знают, то ли одно из двух