BLOGS BY TOPIC▼
BLOGS BY AUTHOR▼
BLOGS BY YEAR▼
Posted by Andy Brown on 13 May 2019
You need a minimum screen resolution of about 700 pixels width to see our blogs. This is because they contain diagrams and tables which would not be viewable easily on a mobile phone or small laptop. Please use a larger tablet, notebook or desktop computer, or change your screen resolution settings.
Stored procedure running slowly? Here's the likely culprit
In general our stored procedures aren't that time-critical: we just don't have enough data for them to matter. But one procedure was seizing up our internal Intranet. It used lots of possible culprits:
| Possible culprit | Notes |
|---|---|
| User-defined functions | Everything I read says that scalar functions are slow. |
| Multiple criteria | My SQL statement had about 15 criteria in. |
| Nested functions | One scalar function called another. |
I tried removing all of these, but the procedure still took over 10 seconds to run. Finally, I found the culprit - some really sloppy programming, because I'm always short of time when I write these things:
-- use main address if gmail, etc
IF EXISTS (
SELECT *
FROM tblUrlHome AS u
WHERE u.UrlHomeName = @DomainMain
)
SET @email = @EmailAddress
So I changed this to code which is almost as sloppy:
-- use main address if gmail, etc
DECLARE @NumberMain AS int = (
SELECT COUNT(*)
FROM tblUrlHome AS u
WHERE u.UrlHomeName = @DomainMain
)
IF @NumberMain > 0
SET @email = @EmailAddress
The difference? The use of IF EXISTS within a function. Lots of websites will tell you the SQL structures you should avoid, but this seems to me to be an order of magnitude slower than correlated subqueries, dynamic SQL, scalar functions, cursors and any of the other usual suspects.