1

我有一个带有两个表的数据库 tblVideos 大约有 800 万行，包含 Id（自动增量 1,1）、videoId、Name、Tags、（FK）VideoProviderId tblVideoProviders 目前大约有 6 个提供程序，并且有 3 列：Id（自动递增 1,1 tiny int)、名称、Url（使用提供者 + 视频 ID 构建链接）

与 YouTube 不同，较小的提供商没有 API 来返回数组然后随机获取一些东西。

以我现在得到的两种方式检索完全随机的行都需要不到一秒钟的时间：

select top 1 tblVideoProvider.Url + tblVideos.videoId as url, tblVideos.Name,
tblVideos.tags from tblVideos
inner join tblVideoProvider
on tblVideos.VideoProviderId = tblVideoProvider.id
WHERE ((ABS(CAST(
(BINARY_CHECKSUM
(tblVideos.id, NEWID())) as int))
% 6800000) < 10 )

或者

稍长

select top 1 tblVideoProvider.Url + tblVideos.videoId as url,
tblVideos.Name, tblVideos.tags from tblVideos
inner join tblVideoProvider
on tblVideos.VideoProviderId = tblVideoProvider.id
ORDER BY NEWID()

但是一旦我开始寻找更具体的东西：

select top 1 tblVideoProvider.Url + tblVideos.videoId as url, tblVideos.Name,
tblVideos.tags from tblVideos
inner join tblVideoProvider
on tblVideos.VideoProviderId = tblVideoProvider.id
where (tblVideos.tags like '%' + @tag + '%')
or (tblVideos.Name like '%' + @tag + '%')
ORDER BY NEWID()

查询达到 8 秒，删除最后一个或tblVideos 之类的将其缩短到 4~5 秒，但这太高了。

在没有“order by newid()”的情况下检索整个查询将使查询花费更少的时间，但应用程序将消耗每个用户大约 0.2~2 MB 的数据，并且假设有超过 200~400 个同时请求最终在很多数据

4

1 回答 1

1

通常，“like”运算符非常昂贵，并且当模式以“%”开头时，甚至无法使用相应列上的索引（假设您有一个）。我认为没有简单的方法可以提高查询的性能。

于 2014-06-04T14:00:04.773 回答