Our API started slowing down after a recent data migration. Profiling shows most time is spent inside Dapper queries, and I suspect parameter sniffing on the SQL Server side. We're using SqlParameter objects with Dapper, but I don't know if there's a Dapper-specific setting to mitigate this.

Has anyone run into this? I know SQL Server caches execution plans based on the first parameter values, which can backfire when the distribution is skewed. Are there query hints I should be adding, or is this purely a database-level concern that I should tune with OPTION (RECOMPILE)?

Also, does Dapper's default behavior of creating a new DbParameter for every call interact badly with connection pooling? I want to make sure I'm not accidentally defeating the pool by instantiating parameters in a tight loop.

Looking for real-world tuning tips, not just textbook explanations.