Сильно переделанная УПП 1.3 на 8.2, MySQL 2005. Используется RLS. Столкнулся с такой проблемой, что в зависимости от того какие есть "Группы доступа" у пользователя очень сильно различается скорость чтения данных. Стал изучать проблему. Для этого переделал шаблон из RLS в обычный запрос и проверяю время выполнения. Разница между пользователями огромна: 0.14 с. и 40 с. время выполнения.
Запрос стандартный:
ВЫБРАТЬ ПЕРВЫЕ 50 //Ограничил ПЕРВЫЕ 50 для ускорения выполнения
ТекущаяТаблица.Ссылка,
ТекущаяТаблица.Реквизит1 //и т.д.
ИЗ
Документ.ТаблицаККоторойНеобходимоПолучитьДоступ КАК ТекущаяТаблица
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ
СоставГруппы.Ссылка КАК ГруппаПользователей
ИЗ
Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы
ГДЕ
СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей
ПО (ИСТИНА)
ГДЕ
НЕ ГруппыПользователей.ГруппаПользователей ЕСТЬ NULL
И НЕ 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
ИЗ
РегистрСведений.НазначениеВидовОбъектовДоступа КАК НазначениеВидовОбъектовДоступа ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПравДоступаПользователей КАК НастройкиПравДоступаПользователей
ПО
(НастройкиПравДоступаПользователей.ОбъектДоступа = ВЫБОР
КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Организации)
ТОГДА ТекущаяТаблица.Организация
КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Подразделения)
ТОГДА ТекущаяТаблица.Подразделение
КОГДА НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа = ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.СтатьиДДС)
ТОГДА ТекущаяТаблица.СтатьяДвиженияДенежныхСредств
КОНЕЦ
)
И НастройкиПравДоступаПользователей.ВидОбъектаДоступа = НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа
И НастройкиПравДоступаПользователей.ОбластьДанных = ЗНАЧЕНИЕ(Перечисление.ОбластиДанныхОбъектовДоступа.ПустаяСсылка)
И НастройкиПравДоступаПользователей.Пользователь = ГруппыПользователей.ГруппаПользователей
ГДЕ
НазначениеВидовОбъектовДоступа.ГруппаПользователей = ГруппыПользователей.ГруппаПользователей
И НазначениеВидовОбъектовДоступа.ВидОбъектаДоступа В (
ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.ПустаяСсылка),
ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Организации),
ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.Подразделения),
ЗНАЧЕНИЕ(Перечисление.ВидыОбъектовДоступа.СтатьиДДС)
)
И НастройкиПравДоступаПользователей.ОбъектДоступа ЕСТЬ NULL )
Показать
Посмотрел план запроса в SQL Profilere. Он одинаковый для "быстрого" и "медленного" пользователей. За единственным исключением: у "медленного" пользователя громадное значение "Actual number jf rows", равное количеству строк в нашей таблице или для некоторых операций равное произведению итераций на количество строк таблицы. "Estimeted number of rows" равен 1. Для "быстрого" пользователя данные этих параметров вполне нормальные. К примеру: "A-number" = 250, "E-number" = 55.
Из различий между двумя пользователями можно выделить: "быстрый" много работает с этой таблицей, в его "группах доступа" указаны те элементы, которые часто используются. У "медленного" -- наоборот, всё редко.
Как я понимаю, проблема в статистике. Пробовал обновить статистику для конкретной таблицы с помощью "Update statistic with fullscan". Кроме того ночью обновляется статистика всей базы. Ни то, ни другое не помогло. Есть мысль, что "медленного" пользователя очень нерепрезентативная выборка и данных мало, поэтому оптимизатор не пользуется статистикой.
Собственно вопрос: кто с чем то подобным сталкивался ? Что вообще можно сделать в такой ситуации ? Как возможна разница во времени выполнения одного и того же запроса в 280 раз ?..
