2 ms·
Maybe it's just Microsoft's SQL server, but I've come to become extremely suspicious of this. I've run into far too many cases where, despite our DBA playing w
by Pxtl 7y ago
Maybe it's just Microsoft's SQL server, but I've come to become extremely suspicious of this. I've run into far too many cases where, despite our DBA playing with cache-clearing strategy and statistics and the like, we found that queries would run fine in the unparameterized query-console and would run with pathological performance in the actual application.
Every time it's "hey mr senior developer, I'm trying to reproduce that slow query but I can't, even though I'm doing the same thing as the application" and I'm like "you must be doing something wrong" and sure enough: no, it's the SQL server doing something wrong. And every time we found out "oh, running it un-parameterized makes it fast". So then I have to talk down the juniors who are like "well fine, I can fix it by running it unparameterized, let's just do that!".
So then we have to figure out how to trick it to generating a non-idiotic query plan without abandoning the security that parameterization provides.
... basically I'm deep into "the emperor has no clothes" on MS SQL server in general.
- bcrosby95 7y agoThis is like a window into my current problems. We've never used SQL Server, but a vendor for a client requires it. We are constantly running into this problem. Right now we have a query that takes 300ms when we back out the parameters, or ~12 minutes when we parameterize it. It is extremely frustrating. Never ran into problems like this with Postgres or MySQL.