Christopher Olsen, Author at DMC, Inc.

SQL Server Performance Tuning: When a Join Isn’t a Join

Christopher Olsen — Wed, 15 Jul 2026 11:00:00 +0000

Recently I was deploying an update to a client’s system and ran into a performance issue with the SQL script to apply database changes, an issue that hadn’t shown up in the test environment. I had to troubleshoot the slow query on the spot and solve it quickly. The cause of the problem turned out to be a useful demonstration of some important nuances in database performance.

In this article, you’ll learn the difference between logical and physical joins, the factors SQL Server considers when deciding how to execute a join, and two approaches to resolving a slow SQL query.

The Query

Here’s the SQL query that was running slowly. I’ve changed the table names and column names to obscure details about my client. After 5 minutes of running the query without finishing, I decided to abort it and troubleshoot it.

SELECT
    v.CustomerID,
    COUNT(v.ID) AS NumberOfVisits
FROM Customers AS c
INNER JOIN Visits AS v ON c.ID = v.CustomerID
WHERE v.VisitDate BETWEEN '2024-01-01' AND '2024-02-01'
GROUP BY v.CustomerID

It’s a simple query: it just joins customers to visits and selects the number of visits that each customer made within the date range specified.

It’s important to note that the customers table is tiny, about 4,000 rows, and the visits table is large, several hundred million rows, so it’s understandable for this query to be performance-intensive. This exact query performed very fast in staging, but there was very little data for that date range in staging, so it makes sense for it to perform differently.

What really confused me is that this query was a glorified copy-paste from a query that we had been using in production to run ad-hoc reports. When we ran it, it was dealing with production-scale data, so why did this version perform so poorly?

The Execution Plan

The first step to troubleshooting a slow SQL query is to get an actual execution plan (if you can). This will show you exactly what steps SQL Server took to execute your query, and runtime stats such as how much time and CPU each step took, how many rows were returned by each step, etc.

In SQL Server Management Studio (SSMS), press CTRL+M, then run your query. By default, this shows the execution plan only after the query finishes, which can be an issue for very slow queries. If you don’t want to wait, you can press CTRL + M and click the button near the top of SSMS labeled “Include Live Query Statistics”. This not only shows you the execution plan right away, but it also shows you the runtime stats (rows read, elapsed time of each step, etc.) in real time, so it updates as you watch it.

I can’t share the screenshot of the execution plan from production, but here’s what it looked like in a development environment when I ran it later. Table and column names have been changed to obscure client details.

I was profoundly surprised by this execution plan because there’s no physical join operator, despite the fact that there’s a logical join in the SQL query.

When you go to a restaurant and order steak au poivre, you don’t give the waiter instructions to cook it (“crush some peppercorns, pat the steak dry, set the grill to medium-high…”). You just ask for steak au poivre, maybe specify medium-rare, and the chef makes it happen.

SQL is the same way. SQL is a declarative language. When we write a SELECT query, we’re not writing instructions for how to get the data; we’re declaring what data we want. SQL Server needs to make decisions about how to execute it, such as which indexes to use or whether to go parallel.

Similarly, when we write any kind of JOIN in a SQL query, what we’re writing is a logical join. Examples include INNER JOIN, LEFT OUTER JOIN, RIGHT OUTER JOIN, CROSS JOIN. SQL Server needs to figure out how to make your join happen, and it will do that by using one of several physical join operators. The most common physical join operators are Nested Loops, Hash Match, and Merge Join, so every execution plan you look at for queries involving logical joins will include at least one of those three operators.

When a Logical Join Does Not Require a Physical Join

Our slow SQL query is an exception to that rule. Our query clearly has a logical join (INNER JOIN) between two tables, but the SQL Server chooses an execution plan with no physical joins.

Why?

The first thing that came to mind is that the SQL query, despite joining the Customers table and the Visits table, only includes fields from the Visits table in the SELECT clause, WHERE clause, and GROUP BY clause. We’re not using any fields from the Customers table other than its ID field as the join key.

That’s part of the explanation, but it doesn’t explain all of it. The whole point of an INNER JOIN is to return only the records that have matches in both tables. So, even though we’re only SELECTing fields from one table, SQL Server still has to determine whether a given key value is present in both tables. How can it do that without performing a physical join?

The answer is the foreign key reference that enforces the relationship between these two tables. Specifically, we have a foreign key on the Visits table on the CustomerID field, referencing the ID field of the Customers table. This foreign key enforces that no record can exist in the Visits table without a corresponding record in the Customers table.

So, let’s look at this from SQL Server’s perspective:

The user is asking me to perform an INNER JOIN.
He’s asking me to filter and group based on fields from only one of the tables.
He’s only asking for fields from that same table.
I know for a fact that all records in Visits have a corresponding Customer record.
Why the heck would I bother with a physical join? I’ll just read from the Visits table and ignore Customers.

Physical joins can be memory-intensive and time-consuming. Generally, if we can avoid a physical join, we’ll get our results faster. So, the execution plan makes sense.

This isn’t just theory, either. I tested it in a development environment by removing the foreign key and running the SQL query. As expected, the execution plan included a physical join. Adding the foreign key constraint back to that field and running the query again resulted once more in an execution plan with no joins.

Why Is the Query Slow If We’re Avoiding a Join?

Now that we’ve identified why the execution plan has no physical join, let’s circle back to the problem at hand: the query is slow. Why is it slow, and how do we fix it?

Let’s take another look at the execution plan, specifically the first step.

SQL Server is choosing to do an index scan. That means it starts at the very “top” of the index and reads through it to the end. It chose this index, “IX_Visits_CustomerID_VisitDate,” because it includes all the fields our query needs. This index contains a couple of fields of each row, which means SQL Server can fit more rows on a single page of data, allowing it to read more rows per page.

However, the order of the keys in this index is hurting performance. CustomerID is the first key, and VisitDate is the second key. That means the rows in the index are sorted first by CustomerID, then by VisitDate. If it was the other way around, all the rows that match our WHERE clause would be right next to each other in the index and SQL Server would be able to do a “seek” to read only the minimal pages it needs to get the data we’re asking for.

Solution 1: Add a New Index

The most obvious solution is to add a new index with VisitDate as the first key and CustomerID as the second. Here’s the resulting execution plan:

Even in this development environment, where the data is much smaller, this resulted in a 100x speed boost—the query finished in about 0.1 seconds instead of 10 seconds.

However, indexes aren’t free, especially on large tables. The more indexes you have on a table, the longer it takes to write to that table when rows are updated or inserted. This table already has more indexes than I’d like, so I’d prefer to avoid adding a new one.

Additionally, this query runs once a month as part of an automated report, so it feels silly to add a whole index just to make this one query faster.

When we solve a slow query by adding, modifying, or removing indexes, that’s called “index tuning”.

Solution 2: Change the Query

In general, if you can make a query faster by rewriting the query rather than adding indexes, you should do so. I ran the old version of the query that was previously used to generate the ad-hoc reports and found that it used a physical join operator. The reason was simple: the original query joined the Visits table to a temp table representing Customers rather than the table itself. The Visits table obviously did not have a foreign key reference to this temp table, so it was forced to perform a physical join.

For the new version of the query, I forced a physical join by selecting a field from the Customers table instead of the Visits table:

SELECT
    c.ID AS CustomerID,
    COUNT(v.ID) AS NumberOfVisits
FROM Customers AS c
INNER JOIN Visits AS v ON c.ID = v.CustomerID
WHERE v.VisitDate BETWEEN '2024-01-01' AND '2024-02-01'
GROUP BY c.ID

In this version of the query, I’m using the Customers table’s ID field for both the GROUP BY and one of the fields in the SELECT, while still using fields from the Visits table in the WHERE clause and the SELECT clause. This forces SQL Server to do a physical join, and the execution plan looks like this:

In my development environment, the query takes 0.455. In production, it takes a couple of seconds, which is fast enough for our purposes. It runs as part of an automated report and must complete within 30 seconds to avoid timeouts.

Let’s zoom in on that physical join operator:

SQL Server chose the Nested Loops join. This physical join operator is very fast and efficient when you have a small result set on one side of the join compared to the result set on the other side. We have just a few thousand rows in our Customers table and a couple hundred million rows in our Visits table, so Nested Loops is the right choice.

The way this join works is that SQL Server loops through the smaller data set, the Customers table, and for each row, performs a seek on the Visits table to get the rows corresponding to that CustomerID value. These seeks are fast because CustomerID is the first key in the index.

Because this version of the query meets our performance needs without requiring a change to the database’s structure (e.g., by adding an index), it’s the solution we chose.

When we solve a slow query by rewriting or tweaking the query text itself, as we did here, that’s called “query tuning”.

The Takeaway

What have we learned? We can take away the following lessons about SQL Server:

SQL Server does not always need to perform a physical join to execute a logical join.
Foreign key references, or lack thereof, can impact whether SQL Server performs a physical join.
If you only use fields from one table in your SELECT, WHERE, ORDER BY, or GROUP BY clauses, SQL Server might not bother with a physical join.
When trying to speed up a slow query, you should first try to rewrite the query before resorting to adding or changing indexes.
Sometimes an unusual solution is the best one. In rare cases, adding a join can improve performance.

This was a deep dive into a fascinating detail of how SQL Server decides when to do a physical join and how that impacts performance.

If you rely on SQL Server or Azure SQL for your business-critical applications, you need database experts who can calmly work under pressure to solve tricky problems like the one described in this article.

Have an upcoming project? DMC can help your team take the next step.

Take your database performance to the next level with engineering solutions from DMC and learn more about Digital Workspace Solutions.

The post SQL Server Performance Tuning: When a Join Isn’t a Join appeared first on DMC, Inc..

Next.js 16 + Material UI Setup Guide for App Router + RSC: Dev Diary #2

Christopher Olsen — Mon, 01 Jun 2026 11:00:00 +0000

In Part 1 of this two-part series, we walked through scaffolding a brand-new React application with Next.js. The result was a bare bones application with no styling to speak of. Early in any web application project, you have an important decision to make: are you going to build the look and feel of your app from scratch with custom CSS and JavaScript, or are you going to leverage a third-party solution to achieve a more professional-looking UI than you would with a custom solution and with less development effort? Most people choose the latter, and we will too.

At DMC, our preferred UI library is Material UI, a component library maintained by Google. I first used Material UI nearly a decade ago, before it even reached version 1.0. Since then, the library has evolved significantly and now includes first-class support for Next.js and React Server Components. In this post, we’ll walk through how to add Material UI to a new Next.js 16 application. At the time of writing, Material UI v9.0.0 is the version in use.

Installing the NPM Packages for Material UI

First, run the following command to install the core Material UI packages using Yarn:

yarn add @mui/material @emotion/react @emotion/styled

yarn add @mui/material @emotion/react @emotion/styled

The Material UI documentation recommends installing @fontsource/roboto to use the Roboto font in your application. However, at the time of writing this post, that package causes the TypeScript server in my project to crash, resulting in the loss of IntelliSense support in Visual Studio Code. Because of this, I recommend skipping that package. Later in this post, we’ll import the Roboto font using a different approach.

Next, run the following command to install the packages required to integrate Material UI with Next.js App Router:

yarn add @mui/material-nextjs @emotion/cache

yarn add @mui/material-nextjs @emotion/cache

Setting Up a Material UI Theme

One of Material UI’s most useful features is its customizable themes. Material UI includes a default theme that can be extensively customized—everything from spacing, color palettes, and even border radius can be modified based on your design sensibilities.

For this application, we’ll primarily use the default Material UI theme while enabling built-in light/dark mode functionality. We can initialize the theme using the createTheme() function:

// src/theme.tsx
"use client";
import { createTheme } from "@mui/material/styles";

const theme = createTheme({
  typography: {
    fontFamily: "var(--font-roboto)",
  },
  cssVariables: {
    colorSchemeSelector: "class",
  },
  colorSchemes: {
    dark: true,
  },
});

export default theme;

// src/theme.tsx
"use client";
import { createTheme } from "@mui/material/styles";

const theme = createTheme({
  typography: {
    fontFamily: "var(--font-roboto)",
  },
  cssVariables: {
    colorSchemeSelector: "class",
  },
  colorSchemes: {
    dark: true,
  },
});

export default theme;

This theme configuration does three things:

Sets Roboto as the default font family for all Typography components.
Enables dark mode support. Light mode is enabled by default.
Enables CSS variables and configures the colorSchemeSelector to use CSS classes.

The final configuration helps prevent SSR flickering, which can occur because the server cannot detect a user’s preferred color mode during the initial render. With this setup, Material UI applies either a light or dark class to the element on the client side and uses CSS variables to apply the appropriate theme colors. This approach provides a smoother transition between server-side rendering and client-side hydration while maintaining support for light and dark themes.

Color Mode Picker

Speaking of color mode (light/dark), it can be nice to offer users a way to switch between light mode and dark mode. With the way we’ve configured our theme, Material UI will automatically set the color mode based on the user’s system preference, set in their web browser. So if a user has configured “dark” mode in Chrome, for example, when they visit our application, they’ll automatically get the dark-mode version of our UI.

Some users may want dark mode specifically for our application and light mode elsewhere, so to provide that flexibility, we’ll build a simple color mode selector. For this, we’ll use the tools Material UI provides, including input and label components, along with tools for customizing them.

// colorThemePicker.tsx
"use client";
import FormControl from "@mui/material/FormControl";
import Select, { SelectChangeEvent } from "@mui/material/Select";
import MenuItem from "@mui/material/MenuItem";
import { useColorScheme } from "@mui/material/styles";
import { FormLabel } from "@mui/material";

export default function ColorThemePicker() {
  const { mode, setMode } = useColorScheme();
  if (!mode) {
    return null;
  }
  const handleChange = (event: SelectChangeEvent) => {
    setMode(event.target.value as "system" | "light" | "dark");
  };

  return (
    <FormControl
      sx={{
        display: "flex",
        flexDirection: "row",
        alignItems: "center",
        gap: 1,
      }}
    >
      <FormLabel id="theme-select-label">Theme</FormLabel>
      <Select
        labelId="theme-select-label"
        aria-labelledby="theme-select-label"
        id="theme-select"
        value={mode}
        label="Theme"
        onChange={handleChange}
        sx={{ minWidth: "10rem" }}
      >
        <MenuItem value="system">System</MenuItem>
        <MenuItem value="light">Light</MenuItem>
        <MenuItem value="dark">Dark</MenuItem>
      </Select>
    </FormControl>
  );
}

// colorThemePicker.tsx
"use client";
import FormControl from "@mui/material/FormControl";
import Select, { SelectChangeEvent } from "@mui/material/Select";
import MenuItem from "@mui/material/MenuItem";
import { useColorScheme } from "@mui/material/styles";
import { FormLabel } from "@mui/material";

export default function ColorThemePicker() {
  const { mode, setMode } = useColorScheme();
  if (!mode) {
    return null;
  }
  const handleChange = (event: SelectChangeEvent) => {
    setMode(event.target.value as "system" | "light" | "dark");
  };

  return (
    
      sx={{
        display: "flex",
        flexDirection: "row",
        alignItems: "center",
        gap: 1,
      }}
    >
      "theme-select-label">Theme
      
        labelId="theme-select-label"
        aria-labelledby="theme-select-label"
        id="theme-select"
        value={mode}
        label="Theme"
        onChange={handleChange}
        sx={{ minWidth: "10rem" }}
      >
        "system">System
        "light">Light
        "dark">Dark
      
    
  );
}

I’ll explain this from the top down.

We need a piece of state to track the user’s color mode selection: light, dark, or system (whatever they’ve selected in their browser settings). We also need a setter for that state so that we can update it based on the user’s actions. For that, we use a hook provided by Material UI: useColorScheme(). The mode returned by this hook is always undefined on the first render, so we handle that with a simple falsiness check:

if(!mode) {
  return null;
}

if(!mode) {
  return null;
}

Next, we have our return statement where we declare the UI that this component should render. We’re making use of a few components from Material UI:

The latter two are kind of self-explanatory if you have a basic background in HTML. FormControl is a nice-to-have component that manages some state related to the input element that it wraps, such as focused state, filled state, error state, required state, etc.

Something I want to point out is the use of the sx prop on the FormControl component. This is a CSS-in-JS styling solution from Material UI, intended for one-off customization. Our application has precisely one color theme picker, so it easily fits the definition of a one-off customization. You can read more about this system in the Material UI documentation.

The purpose served by our use of the sx prop here is to apply some flexbox CSS properties to our FormControl to make its child elements (the FormLabel and Select components) appear side by side instead of displaying the form label above the select component.

<FormControl
  sx={{
    display: "flex",
    flexDirection: "row",
    alignItems: "center",
    gap: 1,
  }}
>/


  sx={{
    display: "flex",
    flexDirection: "row",
    alignItems: "center",
    gap: 1,
  }}
>/

Under the hood, a CSS selector is generated and applied to the rendered DOM element, and a