Travis
11/21/2022, 11:36 PMTravis
11/21/2022, 11:39 PMTravis
11/21/2022, 11:39 PMTravis
11/21/2022, 11:42 PMs1deburn
11/22/2022, 12:26 AMRodney
11/22/2022, 12:30 AMs1deburn
11/22/2022, 1:09 AMzackster
11/22/2022, 10:05 AMdswitzer
11/22/2022, 12:00 PMselect col1, col2 from Table where col3 = 1234
But your CFML code is like this:
select col1, col2 from Table where col3 = <cfqueryparam value="1234" />
Then those are not equivlient things. SQL Server will cache the parameterized query and it can be affected by Parameter Sniffing:
https://www.brentozar.com/archive/2013/06/the-elephant-and-the-mouse-or-parameter-sniffing-in-sql-server/
This is generally the culprit in these situations.
However, as @zackster allued to, you can also be bit by type mistmatches. I recently discovered a bug in third party framework we use in some places of our code called qb, which is a fluent query builder for CFML. Since it obscures the actual SQL statements being executed, I didn't realize it was casting all integers as floats in the actual SQL statement being executed, which was leading to coercion happening in the query, which was causing terriblly inefficient query plans. It took us a while to notice the issue because even with the coercion, things were usually really fast. However, sometimes we'd be bitten by slowness, but flushing the query's cache plan would resolve the issue. We just thought were getting hit by some cache poisioning issues that was the root cause. It wasn't until I actually took a deep dive and really started analysing things that I realized what was going on.