<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Rafiqul Islam</title>
    <description>The latest articles on DEV Community by Rafiqul Islam (@rafiqul_islam_11657f0816b).</description>
    <link>https://dev.to/rafiqul_islam_11657f0816b</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4220269%2Fa7b6205d-6517-45a8-bd16-2c4bbeacf57f.jpg</url>
      <title>DEV Community: Rafiqul Islam</title>
      <link>https://dev.to/rafiqul_islam_11657f0816b</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/rafiqul_islam_11657f0816b"/>
    <language>en</language>
    <item>
      <title>What is MAXDOP?</title>
      <dc:creator>Rafiqul Islam</dc:creator>
      <pubDate>Sun, 01 Nov 2026 10:38:50 +0000</pubDate>
      <link>https://dev.to/rafiqul_islam_11657f0816b/what-is-maxdop-2b5h</link>
      <guid>https://dev.to/rafiqul_islam_11657f0816b/what-is-maxdop-2b5h</guid>
      <description>&lt;p&gt;&lt;strong&gt;MAXDOP&lt;/strong&gt; stands for &lt;strong&gt;Maximum Degree of Parallelism&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;In plain English, it is a setting in SQL Server that answers a simple question: &lt;strong&gt;"How many CPU cores are allowed to work together on a single heavy query?"&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The Analogy: Moving Heavy Boxes&lt;/strong&gt;&lt;br&gt;
Imagine you have to move 1,000 heavy boxes into a warehouse.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;- MAXDOP = 1 (No Parallelism):&lt;/strong&gt; You assign &lt;strong&gt;only 1 person&lt;/strong&gt; to move all the boxes. It will take a long time because they have to do everything alone.&lt;br&gt;
&lt;strong&gt;- MAXDOP = 4 (Parallel Processing):&lt;/strong&gt; You assign &lt;strong&gt;4 people&lt;/strong&gt; as a team. They split the work and finish the job four times faster.&lt;br&gt;
&lt;strong&gt;- MAXDOP = 0 (Unlimited / Default):&lt;/strong&gt; You tell the workers, "Use as many people as you want!" If you have 32 CPU cores available, a single giant query might suddenly hijack &lt;strong&gt;all 32 cores&lt;/strong&gt; to move its boxes.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Why Does It Matter?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;If MAXDOP is set incorrectly, it can cause major performance issues:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;1. The Hogging Problem (MAXDOP too high):&lt;/strong&gt; If one heavy query grabs all the CPU cores, other users trying to run quick searches will get stuck waiting because no CPU power is left for them. The server can freeze or slow down globally.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;2. The Sluggish Query Problem (MAXDOP too low):&lt;/strong&gt; If a massive report needs help from multiple cores to run fast, but MAXDOP restricts it to just 1 core, that report will crawl.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The Goal&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Finding the sweet spot! Database administrators usually adjust MAXDOP so that big queries get enough team help to run fast, but not so much that they starve other users on the server.&lt;/p&gt;

</description>
      <category>database</category>
      <category>performance</category>
      <category>sql</category>
    </item>
    <item>
      <title>SQL Server Parameter Sniffing...</title>
      <dc:creator>Rafiqul Islam</dc:creator>
      <pubDate>Sun, 01 Nov 2026 10:14:43 +0000</pubDate>
      <link>https://dev.to/rafiqul_islam_11657f0816b/sql-server-parameter-sniffing-48h8</link>
      <guid>https://dev.to/rafiqul_islam_11657f0816b/sql-server-parameter-sniffing-48h8</guid>
      <description>&lt;p&gt;&lt;strong&gt;SQL Server Parameter Sniffing&lt;/strong&gt; happens when SQL Server tries to be clever and fast, but ends up accidentally hurting performance.&lt;/p&gt;

&lt;p&gt;To put it simply: &lt;strong&gt;It is when SQL Server creates a shortcut based on the first value it sees, and then uses that same shortcut for everyone else—even if it is a terrible fit for them.&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;A Real-World Analogy: The Pizza Delivery Route&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Imagine you work at a pizza shop and a delivery driver asks: "What is the fastest route to deliver an order?"&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;
&lt;strong&gt;The First Order:&lt;/strong&gt; The first customer lives &lt;strong&gt;right next door&lt;/strong&gt; (2 minutes away). You tell the driver: "Just take your bicycle. It's the fastest way."&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;The Problem:&lt;/strong&gt; The driver memorizes that strategy. But the next order is for a customer who lives 10 miles away on the other side of town.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;The Sniffing Issue:&lt;/strong&gt; Instead of looking at the new address and realizing they need a car, the driver blindly uses the old strategy—&lt;strong&gt;they try to ride the bicycle 10 miles&lt;/strong&gt;. It takes forever!&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;In this analogy:&lt;br&gt;
• The "Parameter" is the delivery address.&lt;br&gt;
• "Sniffing" is looking at that address to decide the route.&lt;br&gt;
• &lt;strong&gt;The Bug&lt;/strong&gt; is locking in that route for all future deliveries, no matter how far away they are.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;How it Happens in SQL Server&lt;/strong&gt;&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;
&lt;strong&gt;The First Run:&lt;/strong&gt; When you run a stored procedure for the very first time, SQL Server looks at ("sniffs") the parameter value you passed in (e.g. CustomerID = 5). Based on that specific value, it builds a specific map (called an execution plan) for how to fetch the data.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Caching the Plan:&lt;/strong&gt; SQL Server saves this map in its memory so it doesn't have to waste time building a new one next time.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;The Subsequent Runs:&lt;/strong&gt; Later, another user runs the exact same procedure, but passes a completely different parameter value (e.g. CustomerID = 999999).&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;The Performance Hit:&lt;/strong&gt; SQL Server reuses the old map. If the first query needed to scan just a few rows, but the second query needs to scan millions, the old map will perform terribly, causing the query to freeze or run very slowly.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;&lt;strong&gt;How to Fix It&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;If parameter sniffing is causing your queries to slow down randomly, database administrators usually fix it using a few standard approaches:&lt;br&gt;
• &lt;strong&gt;WITH RECOMPILE:&lt;/strong&gt; Tells SQL Server to ignore the old map and build a fresh one every single time the query runs.&lt;br&gt;
• &lt;strong&gt;OPTIMIZE FOR:&lt;/strong&gt; Forces SQL Server to build a map based on a typical, average parameter value rather than whatever happens to run first.&lt;br&gt;
• &lt;strong&gt;Local Variables:&lt;/strong&gt; Copying the parameter into a local variable inside the stored procedure, which tricks SQL Server into not sniffing the initial value at all.&lt;/p&gt;

</description>
      <category>database</category>
      <category>performance</category>
      <category>sql</category>
    </item>
  </channel>
</rss>
