---
title: "Dapper parameter sniffing and performance tuning in ASP.NET Core"  
description: "Dapper parameter sniffing and performance tuning in ASP.NET Core"  
author: "Austin Luthar"  
published: 2026-09-30  
updated: 2026-09-30  
canonical: https://www.mindstick.com/forum/162223/dapper-parameter-sniffing-and-performance-tuning-in-asp-net-core  
category: "Performance"  
tags: ["Dapper", "performance", "sql server", "Tuning", "Optimization"]  
reading_time: 1 minute  

---

# Dapper parameter sniffing and performance tuning in ASP.NET Core

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](https://www.mindstick.com/interview/354/what-happens-if-connection-pooling-is-enabled)? 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.


---

Original Source: https://www.mindstick.com/forum/162223/dapper-parameter-sniffing-and-performance-tuning-in-asp-net-core

Copyright © MindStick Software Pvt. Ltd. This Markdown version is provided for developers, AI systems, and offline reading.