"Subquery has multiple rows for like comparison - sql

Question

I have one table give below.
In the following query, the outer query joins on a like comparison on the tag column with the subquery.
SELECT top 6 *
FROM [piarchive].[picomp2]
WHERE tag Like
(
Select distinct left(tag,19) + '%'
from (SELECT *
FROM [piarchive].[picomp2]
WHERE tag like '%CPU_Active' and time between '2014/10/02 15:13:08'and'2014/10/02 15:18:37'
and value=-524289 order by time desc) as t1
)
and tag not like '%CPU_Active' and tag not like '%Program%' and time between '2014/10/02
15:13:08'and'2014/10/02 15:18:37' order by time desc
But this subquery returns multiple rows, causing the following error:
Error : "When used as an expression, subquery can return at most one row."

Answer 1

Replace the where tag like (...) (where ... is the subquery, omitted here for brevity) part with where exists (...), and bring the like comparison into the subquery.
select top 6
*
from
[piarchive].[picomp2] t0
where
exists
(
select
*
from
(
select
*
from
[piarchive].[picomp2]
where
tag like '%cpu_active' and time between '2014/10/02 15:13:08' and '2014/10/02 15:18:37'
and
value = -524289
)
as t1
where
t0.tag like left(t1.tag, 19) + '%'
)
and
tag not like '%cpu_active'
and
tag not like '%program%'
and
time between '2014/10/02 15:13:08' and '2014/10/02 15:18:37'
order by
time desc;
I've added a table alias to the outer query to disambiguate the tag columns, but you can see the like comparison is shifted to within the subquery.
I can't vouch for how this will perform on large data sets, but that's a different topic. Personally, I would be looking for a way to get rid of the subquery altogether, since it's all querying the same table.
More on optimisation
It's not going to be easy to optimise, and indexes will be of little use here, for the following reasons:
The join criteria (t0.tag like left(t1.tag, 19) + '%') is not simple, and the query optimiser may have a hard time producing anything better than nested loops (i.e., executing the subquery for every row of the outer query). This is probably your biggest performance killer right here.
None of the like comparisons can utilise table indexes, because they are checking the end of the value, not the start.
Your only hope might be if the date-range check is highly selective (eliminates a lot of records). Since the same check on the time field is performed in both outer and inner queries, you could select that into a temp table:
select left(tag, 19) as key, *
into #working
from [piarchive].[picomp2]
where [time] between '2014/10/02 15:13:08' and '2014/10/02 15:18:37';
#working now has only the records in the specified time period. Since your example range is quite narrow (only 5 1/2 minutes), I'd wager this might knock out ~99% of records. An index on time will speed this up significantly. After you do this, you're only dealing with a tiny fraction of the data.
Then, possibly (see later) index key:
create clustered index cx_key on #working (key);
Then complete the rest of the query as:
select a.*
from #working a
where exists
(
select *
from #working b
where a.key = b.key and b.tag like '%cpu_active'
)
and
a.tag not like '%program%'
and
a.tag not like '%cpu_active'
What I've done is create a clustered index on the joining criteria (the first 19 chars of tag) to optimise the subquery. You'll have to test this out, as it may make no difference or even slow things down if the gains are outweighed by the cost in creating the index in the first place. This will depend on how much data you have, and other factors. I only got minimal gains by doing this (about a 5% speed increase), though I'm only running this against a few hundred rows of test data I knocked up. The more data you have, the more effective it should be.