|
1. Да
2. С уходом бакетов (sift-levels to montain) изменились правила игры с вычисляемыми полями. Представьте ключ из десяти поле Field1..Field10. Раньше - sift-levels to montain стоит на всех уровнях, наложили фильтр по Field1, sumindexfield просчитался мгновенно, селективность идеальная, т.к. есть соотвествующий уровень и записи расположены по порядку, наложили фильтр по Field10 - селективность самая низкая, sumindex field будет считаться долго. С появлением индексированных представлений запросы фильтром что по Field1, что по Field10 будут выполнятся практически одинаково (по Field1 возможно несколько быстрее в силу страничного расположения индекса). В общем случае рекомендация - по возможности разбивайте длинные ключи на более короткие.
4. Точно не такой же что и в более ранних версиях. Экспериментируйте.
К сожалению, сказав А и изменив подход к sift ключам в SQL версии, разработчики MS не сказали Б и не оптимизировали ключи для работы в новых условиях, и, насколько мне известно, даже не выдали рекомендации.
К примеру, устаревшее правило хорошего тона задвигать Posting Date в конец ключа (в старых версиях индексы по дате могли монтироваться в т.ч. по месяцу и году, что могло породить дублирование на более низких уровнях) приводит к низкой селективности и как следствие существенному замедлению отчетов по оборачиваемости.
Возможно причина в том, что подход к формированию ключей для SQL версии и native DB должен быть различным, и MS пока не спешит пересаживатся со стула Native DB.
|