对返回 100+ 的存储过程使用临时表或表变量行
好吧,基本上我正在创建一个存储过程,它将返回用于我们的 Coldfusion Power 搜索的数据。
我创建了一个视图,用于保存多个表中的数据,当然返回相同的列名。
然后在我的存储过程中,我创建了一个像这样的简单临时表...
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;
现在当我在 Coldfusion 中测试该存储过程时,它似乎需要很长时间。
所以我在想,要么我错误地使用了临时表,要么没有完全实现最佳性能。
或者也许我应该切换到表变量...
但我只是在阅读...临时表 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
诸如此类。我无法透露具体细节,因为这会构成安全漏洞。我希望这能让事情变得更清楚。
Okay basically I am creating a stored procedure that will return data for our coldfusion power search.
I created a view, to hold data from multiple tables, with the same column names returned of course.
Then in my stored procedure i have created a simple temporary table like this....
CREATE TABLE #TempSearchResults
(
search_id int identity,
id integer,
type varchar(20),
title varchar(50),
url varchar(250),
rank integer
)
Then I added an index to it, in my perhaps limited experience as a way to improve performance.
CREATE UNIQUE INDEX idx on #TempSearchResults (search_id)
Then i did my select into massive query
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
and it goes on like that having different rank math values for where it found the keyword in the tables.
And at the end it does...
select id, type, title, url, rank
from #TempSearchResults
group by id, type, title, url, rank
order by rank desc, title asc;
Now when I test that stored procedure in coldfusion, it seems to take very long.
So I am thinking, either I am using temp tables wrong or incompletely for optimal performance.
Or perhaps I should switch to table variables...
But I was just reading...Temp Tables VS Table Variables
Funny thing is, this stored procedure seems to be slower than me running the query directly via coldfusion, which I prefer not to.
I am hoping for optimal performance....
Thank you...
Below is the basic logic or code for the view I am using.
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
Etc like that. I can't reveal the exact details, as that would be a security breach. I hope that makes it clearer.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我认为根本不需要使用临时表或表变量。你可以只写
编辑:
用UNION替换UNION ALL,这可以简化为
I see no need to use a temporary table or table variable at all. You can just write
Edit:
Replacing UNION ALL by UNION, this can be simplified to
在选择数据的表上使用
with (Nolock)
提示;如果您的应用程序允许脏读,它可能会提高性能。Use
with (Nolock)
hint on tables where ever you are selecting the data; it may improve performance if your application allows for dirty reads.