Доброго времени суток!

У меня такая проблема, помогите, пожалуйста.
Есть база УТ 11.1, подключена по технологии Клиент-сервер
В ней большой справочник "Партнеры" - порядка 200000 записей.
Есть выгруженная из внешнего источника данных таблица телефонных звонков с графами
"Длительность звонка" и "Телефонный номер", количество строк может быть любым.
Требуется по телефонному номеру найти партнеров для всех строк из этой таблицы.
Я написал процедуру примерно такого вида:

&НаСервере
Процедура СопоставитьПартнеров()

//Операторы загрузки данных из внешней таблицы в таблицу значений ВнешТЗ
...

//Попытка найти партнеров по номеру телефона
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ *
|ПОМЕСТИТЬ ВнешТЗ
|ИЗ &ВнешТЗ КАК ВнешТЗ
|;
|ВнешТЗ.ДлительностьЗвонка КАК Длительность,
|ВнешТЗ.ТелефонныйНомер КАК ТелефонныйНомер,
|ПартнерыКИ.Ссылка КАК Партнер
|ИЗ
|ВнешТЗ КАК ВнешТЗ
|ЛЕВОЕ СОЕДИНЕНИЕ
|Справочник.Партнеры.КонтактнаяИнформация КАК ПартнерыКИ
|ПО ВнешТЗ.ТелефонныйНомер ПОДОБНО(ПартнерыКИ.НомерТелефона)";

Запрос.Параметры.Вставить("ВнешТЗ", ВнешТЗ);
Рез = Запрос.Выполнить();

//Дальнейшая обработка результата запроса
...
КонецПроцедуры


Проблема такая:
Если во внешней таблицы записей немного (в пределах 1000), то запрос отрабатывает нормально.
Но если их передано очень много (порядка 100000), то на выполнении запроса 1С мертво подвисает на
несколько часов, и вместе с ней подвисает и сервер, на котором она установлена, т.е. не могут работать
и другие пользователи этой базы, и даже пользователи других программ, установленных на этом сервере.
Подскажите, пожалуйста, как грамотно получить данные из справочника партнеров, чтобы запрос выполнялся быстрее, или хотя бы чтобы он не подвешивал сервер.
Заранее благодарен

>"ВЫБРАТЬ * это конечно очень оптимистично...

Для начала определить когда зависает? Например попробовать просто передать внешнюю таблицу в запрос. Если все ОК, то работать с запросом - оптимизировать (индексы, строка ограниченой длины вместо неограниченной, номер телефона в виде числа и т.п.). Не должно так тормозить.

Спасибо, Casey1984! Зависает при сравнении со справочником партнеров. Сама внешняя таблица передается в запрос моментально, уже пробовал. А вот индексы пока не использовал.

Думается, что проблема где-то тут.
|ПО ВнешТЗ.ТелефонныйНомер ПОДОБНО(ПартнерыКИ.НомерТелефона)

представляю размер  tempdb на сервере.

Из внешней ТЗ выбирай интервалами по 10000 записей например

Индексировать таблицу?

(0) Если привести телефонные номера к единому общему формату (преобразовав предварительно внешние данные и данные в базе кодом), то пропадет необходимость в ПОДОБНО. Это значительно ускорит запрос.

(5) Ты не дооцениваешь возможности СУБД.

Я один не понимаю смысла использовать ПОДОБНО вместо = в данном конкретном случае?

(0) Сделай так - сгруппируй внешнюю таблицу по телефонному номеру, соедини с партнёрами, а потом соединяй по равенству поля телефонный номер.И юзай ВЫРАЗИТЬ(ТелефонныйНомер КАК СТРОКА(15))ТелНомер

(10) ну у него в базе номера, может, то с 8, то с +7 начинаются, а во внешней таблице вообще без кода

(12) нет

(12) тогда условие выглядит так:

ПО ПартнерыКИ.НомерТелефона  ПОДОБНО(ВнешТЗ.ТелефонныйНомер+""%"")

Без подстановочных знаков ПОДОБНО не имеет смысл. Единственный вариант - эти знаки уже в самих таблицах, но чето врядли.

(14) Пардон, условие тогда
ПО ПартнерыКИ.НомерТелефона  ПОДОБНО(""%""+ВнешТЗ.ТелефонныйНомер)

(16) Об индексе при этом можно забыть. Тут индексы вообще не отработают от слова Никогда, пока ПОДОБНО не заменим на =. Но это не значит, что ПОДОБНО не может работать с индексами.

это разовая операция или нужно постоянно?
если разовая, то разбивай на порции как в (6)
ессли постоянно, то пиши в РС, приводя телефонный номер к стандартному виду, потом соединяй с этим РС по индексированному полю безо всяких ПОДОБНО

|ЛЕВОЕ СОЕДИНЕНИЕ
|Справочник.Партнеры.КонтактнаяИнформация КАК ПартнерыКИ
|ПО ВнешТЗ.ТелефонныйНомер ПОДОБНО(ПартнерыКИ.НомерТелефона)
Убери во вложенный запрос.
Только не спрашивай почему.
Просто проверь.

Господа, спасибо за рекомендации!
Операция нужна будет постоянно.
Прошу прощения, когда я печатал сообщение, пропустил строку ""%"". На самом деле, условие у меня выглядит именно так, как написал
HADGEHOGs:

ПО ПартнерыКИ.НомерТелефона ПОДОБНО(""%""+ВнешТЗ.ТелефонныйНомер)

именно потому, что, как написал Скай, номера начинаются то с +7, то с 8.
Про РС я уже думал - это же сильно раздует базу. Ведь на каждого партнера (а их порядка 200000, и будут еще) приходится несколько телефонов.

(20)

Операция нужна будет постоянно.

Добавить индексированное поле
НомерТелефонаВнешний и искать сначало (первым запросом) по нему по точному соответствию.

(20) 200000 элементов * 10 номеров * 100 байт (ссылка+номер и на комментарий останется) = 200 МБ

Добавить индексированное поле
НомерТелефонаВнешний и искать сначало (первым запросом) по нему по точному соответствию.

Я не упомянул, что мне запрещено менять объекты типовой (в т.ч. справочник "Партнеры")

ут 11... и контактные данные... это, если мягко выражаться, очень жесткое место для приземления..

Регламентом выбирать только свежие записи. Какую-нить бд из телефонии парсишь?

Там же наверняка дата звонка есть. Вот и тягай только свежие

Да, SQL-базу из Asterisk. Там в таблице еще много полей (даты начала и окончания звонка, код провайдера и т.д.), просто я указал в коде только два поля для того, чтобы объяснить суть проблемы.

Знакомо. Ну так все просто, первоначальное заполнение в 1С делаешь просто по периодам, в первом запросе через where выборку ограничить. А потом регламентное задание раз в день, к примеру, которое только сегодняшние звонки получает.

А так, проблема в ПОДОБНО помноженном на большое число записей.

Уважаемый Скай! Дата звонка есть, и записи оттуда тягаются только свежие (раз в 15 минут), и процедура отрабатывала до сих пор нормально. Просто сейчас потребовалось провести повторную закачку звонков за месяц, вот тут-то и выяснилось, что код проблемный

(23) Хочешь быстро - нормализуй номера там и там, и ищи по равенству иди хотя бы по префиксам.

(27) Или выгрузи партнеров в тот SQL, где Asterisk, и сопоставляй там. Там ты не будешь связан ограничением "запрещено менять объекты типовой" и сможешь делать любые преобразования создавать нужные индексы.

Или выгрузи партнеров в тот SQL, где Asterisk, и сопоставляй там

Тогда получается, что нужно будет регулярно выкачивать новых партнеров в SQL-базу Asterisk. Хотя тоже вариант...

я бы для начала выбрал РАЗЛИЧНЫЕ из ВнешТЗ.ТелефонныйНомер, может там из 200000 только 1000 постоянно названивают, потом бы заморочился с нормализацией

(32) Прикинь, сколько появляется новых партнеров и сколько звонков. Звонков явно больше.

(23) Так в УТ 11 есть доп. реквизиты без изменения типовой или в прочую контактную информацию нормальный телефон записать. Трудозатраты на ведение внешней базы без ошибок и с правильной синхронизацией не соответствуют "лишней" записи для каждого нужного партнера.

Человеку сказали попробуй вложенный запрос, ноль реакции. Баклан какой-то