If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
All this month I’m going to be giving readers (watchers? stalkers?) access to my Starting SQL video course.
Enjoy!
Going Further
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
Working with a client… Well, it’s hard to know based on my publishing schedule. But they were using ISNUMERIC all over the place, and getting the same wacky results, and even errors.
Here’s a short setup:
SELECT
x.n
INTO #t
FROM
(
SELECT '$'AS n
UNION ALL
SELECT ','AS n
UNION ALL
SELECT '.'AS n
UNION ALL
SELECT ',1,'AS n
UNION ALL
SELECT '-'AS n
UNION ALL
SELECT '+'AS n
UNION ALL
SELECT CHAR(9)AS n
UNION ALL
SELECT CHAR(10)AS n
UNION ALL
SELECT CHAR(11)AS n
UNION ALL
SELECT CHAR(12)AS n
UNION ALL
SELECT CHAR(13)AS n
) AS x;
We’re definitely not dumping anything in that table that’s a number.
Competitors
Let’s see what happens when we run this query:
SELECT
t.n,
i = ISNUMERIC(t.n),
t = TRY_CONVERT(bigint, t.n),
c = CASE
WHEN t.n NOT LIKE '%[^0-9]%'
THEN 1
ELSE 0
END
FROM #t AS t
The first column is what each of the next three columns are evaluating:
oops
You can see ISNUMERIC stink it up every time. TRY_CONVERT mostly does okay, but I’m not sure how I feel about + and – being converted to zero.
That case expression is the only thing that seems reliable.
Of course, integers are stodgy. Stiff. Maybe we need something a little more floaty.
SELECT
t.n,
i = ISNUMERIC(t.n),
t = TRY_CONVERT(float, t.n),
c = CASE
WHEN t.n NOT LIKE '%[^0-9]%'
THEN 1
ELSE 0
END
FROM #t AS t
What happens?
more right
Well, ISNUMERIC still stinks, but at least TRY_CONVERT does better.
Majority
No one should be using ISNUMERIC, period. Depending on your query needs, you can certainly use TRY_CONVERT in most situations, assuming you’re on SQL Server 2016+.
For everyone else, and even maybe people on 2016+, that CASE expression works really well for rooting out things that aren’t numbers.
Thanks for reading!
Going Further
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
The thing is that most rewrites are pretty simple, as long as there aren’t two columns fed into it.
For example, there’s not much the optimizer could do about this:
WHERE DATEDIFF(DAY, u.CreationDate, u.LastAccessDate) > 1
But that’s okay, because if you do that you deserve exactly what you get.
Computed columns exist for a reason. Use them.
Whaffle House
Where things get a bit easier is for simpler use cases where constant folding and expression matching can be used to flip predicates around a little bit.
It’s just a little bit of pattern recognition, which the optimizer already does to make trees and apply rules, etc.
CREATE INDEX p ON dbo.Posts(CreationDate);
There’s a huge difference between these two query plans:
SELECT
c = COUNT_BIG(*)
FROM dbo.Posts AS p
WHERE DATEADD(MONTH, -1, p.CreationDate) >= '20191101'
GO
SELECT
c = COUNT_BIG(*)
FROM dbo.Posts AS p
WHERE p.CreationDate >= DATEADD(MONTH, 1, '20191101');
GO
hand rub
Thanks for reading!
Going Further
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. Need hands-on help? I offer consulting engagements from targeted investigations to ongoing retainers. Want a quick sanity check before committing to a full engagement? Schedule a call — no commitment required.
One might expect the query inside the cursor to be subject to some special rules, but alas, nothing good comes of it.
Eau de Sample
To repro a little bit, we need to create a certainly suboptimal index.
CREATE INDEX p ON dbo.Posts
(OwnerUserId);
If you have a lot of single key column indexes, you’re probably doing indexing wrong.
Full demo code is at the end because it’s a bit long, but the end result is five query plans that all share the same bad estimate based off the density vector.
The worst of them looks like this:
Occurling
And the best of them looks like this:
Gruntled
Over and Over
If you’re getting bad guesses like this over and over again in any loop-driven code, local variables might just be to blame.
That guess of 10 rows of course comes from this calculation:
SELECT
density =
(
1 /
CONVERT
(
float,
COUNT(DISTINCT p.OwnerUserId)
)
) *
COUNT_BIG(*)
FROM Posts AS p
Which, with a little bit of rounding, gets us to the estimate we see in the query plan:
hectic
Thanks for reading!
Going Further
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. Blog readers get 25% off the Everything Bundle — over 100 hours of performance tuning content. I’m also available for consulting if you just don’t have time for that and need to solve performance problems quickly.
Demo Code
SET STATISTICS XML OFF;
SET NOCOUNT ON;
DECLARE
@CurrentId int;
DROP TABLE IF EXISTS #UserIds;
CREATE TABLE #UserIds
(
UserId int PRIMARY KEY CLUSTERED
);
INSERT
#UserIds WITH(TABLOCK)
(
UserId
)
SELECT
u.Id
FROM dbo.Users AS u
WHERE u.Reputation > 850000
ORDER BY u.Reputation DESC;
DECLARE counter CURSOR
LOCAL STATIC
FOR
SELECT
UserId
FROM #UserIds;
OPEN counter;
FETCH NEXT FROM counter
INTO @CurrentId;
WHILE @@FETCH_STATUS = 0
BEGIN
SET STATISTICS XML ON;
SELECT
p.PostTypeId,
c = COUNT_BIG(*)
FROM dbo.Posts AS p
WHERE p.OwnerUserId = @CurrentId
GROUP BY p.PostTypeId
ORDER BY c DESC;
SET STATISTICS XML OFF;
FETCH NEXT FROM counter
INTO @CurrentId;
END;
CLOSE counter;
DEALLOCATE counter;