Хорошо, в основном я создаю хранимую процедуру, которая будет возвращать данные для нашего поиска мощности coldfusion.

Я создал представление для хранения данных из нескольких таблиц, конечно, с одинаковыми именами столбцов.

Затем в моей хранимой процедуре я создал простую временную таблицу, подобную этой ...

    CREATE TABLE #TempSearchResults
(
    search_id int identity,
    id integer,
    type varchar(20),
    title varchar(50),
    url varchar(250),
    rank integer
)

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

CREATE UNIQUE INDEX idx on #TempSearchResults (search_id)

Затем я сделал свой выбор в массовом запросе

insert into #TempSearchResults
select id, type, title, url, rank + 1200 as rank
from my view
where company_id = @company_id
and title like @keyword
union all
select id, type, title, url, rank + 1100 as rank
from my view
where company_id = @company_id
and title like @keyword
and description like @keyword

И это продолжается с разными математическими значениями ранга для того, где было найдено ключевое слово в таблицах.

И в конце концов ...

select id, type, title, url, rank
from #TempSearchResults
group by id, type, title, url, rank
order by rank desc, title asc;

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

Итак, я думаю, либо я использую временные таблицы неправильно, либо не полностью для оптимальной производительности.

Или, может быть, мне стоит перейти к табличным переменным ...

Но я как раз читал ... Временные таблицы VS переменные таблицы

Забавно то, что эта хранимая процедура кажется медленнее, чем я, выполняя запрос напрямую через coldfusion, чего я предпочитаю не делать.

Надеюсь на оптимальную производительность ....

Спасибо...

Ниже приведена базовая логика или код используемого мной представления.

select some field as id, some field as title, some field as description, 'url link' as url, 1 as rank
from table a
union
select some field as id, some field as title, some field as description, 'url link' as url, 1 as rank
from table b
union
select some field as id, some field as title, some field as description, 'url link' as url, 1 as rank
from table c

И так далее. Я не могу раскрыть точные подробности, так как это было бы нарушением безопасности. Надеюсь, это проясняет ситуацию.

1
crosenblum 18 Фев 2011 в 20:47
Как долго выполняется ваш оператор вставки? Бьюсь об заклад, это медленная часть ... запустите его в одиночку как select и посмотрите, сколько времени там вы проводите. Сначала нужно понять, ЧТО нам нужно оптимизировать!
 – 
Wavel
18 Фев 2011 в 20:54
При запуске cfstoredproc в холодном слиянии он показывает 5312 мс. В SSMS указано общее время выполнения 171.00
 – 
crosenblum
18 Фев 2011 в 21:00
Не могли бы вы подробнее рассказать о представлении.
 – 
bernd_k
18 Фев 2011 в 21:26
Само представление представляет собой группу выбора из разных таблиц в объединении. Это сделано для того, чтобы мне было проще искать в одном и том же наборе таблиц разными способами, а также облегчить чтение. Один вопрос, в моей компании нет dba, только я, еще один программист и наш босс. Помогло бы, если бы я запустил ОБНОВЛЕНИЕ СТАТИСТИКИ для таблиц, используемых в представлениях / процедурах?
 – 
crosenblum
18 Фев 2011 в 21:33
Я добавил больше деталей о представлении, по крайней мере, с точки зрения базовой логики.
 – 
crosenblum
18 Фев 2011 в 21:41

2 ответа

Лучший ответ

Я вообще не вижу необходимости использовать временную таблицу или табличную переменную. Ты можешь просто написать

select id, type, title, url, rank
from (
    select id, type, title, url, rank + 1200 as rank 
    from my view 
    where company_id = @company_id and title like @keyword 

    union all 

    select id, type, title, url, rank + 1100 as rank 
    from my view 
    where company_id = @company_id and title like @keyword and description like @keyword
) as t
group by id, type, title, url, rank
order by rank desc, title asc;

Изменить:

Заменив UNION ALL на UNION, это можно упростить до

select id, type, title, url, rank + 1200 as rank 
from my view 
where company_id = @company_id and title like @keyword 

union 

select id, type, title, url, rank + 1100 as rank 
from my view 
where company_id = @company_id and title like @keyword and description like @keyword

order by rank desc, title asc;
2
bernd_k 18 Фев 2011 в 21:14
Я знаком с этим подходом, это лучшая производительность, чем временная таблица?
 – 
crosenblum
18 Фев 2011 в 21:09
Могу поспорить, что это так, но я не знаю наверняка.
 – 
bernd_k
18 Фев 2011 в 21:12
С учетом изменений в холодном сварке это 5265 мс. Изначально я перешел с union на union all, потому что union больше снижает производительность, потому что он различает результаты.
 – 
crosenblum
18 Фев 2011 в 21:16
При переходе от union all к union производительность холодного сварки составила 5515 мс.
 – 
crosenblum
18 Фев 2011 в 21:17
1
Если вы знаете, что у вас нет дубликатов, вы можете использовать UNION ALL и обойтись без группы by. Эта внешняя группа по эквивалентна отличному во внешнем выборе.
 – 
bernd_k
18 Фев 2011 в 21:23

Используйте подсказку with (Nolock) для таблиц, где бы вы ни выбирали данные; это может улучшить производительность, если ваше приложение допускает грязное чтение.

0
LittleBobbyTables - Au Revoir 11 Окт 2012 в 15:15