SQL Server has a feature called Query Store that maintains a history of all execution plans generated for each query over time. Unlike examining the current plan in cache with SHOWPLAN or execution plan tools, Query Store lets you see every plan the optimizer has chosen historically, allowing you to compare performance across plan changes and investigate regressions.
The following examples assume that Query Store is enabled on your database.
If you’ve spent any time working with SQL Server, you’ve almost certainly run into the “Violation of UNIQUE KEY constraint” error.
It’s one of those errors that can show up in a few different ways depending on how your data flows into the database. Sometimes it’s a data quality issue. Sometimes it’s a race condition. Sometimes it’s just a gap in the logic that nobody caught until production. Whatever the cause, there are quite a few different ways to handle it. Some reactively, some proactively. This article walks through the main ones.
If you’re getting SQL Server error 13683 stating “Invalid JSON paths in JSON index“, it sounds like you could be specifying overlapping paths in your JSON index definition.
A JSON index cannot contain overlapping paths.
To fix this, remove the overlap from the specified paths that make up the index definition.
JSON_CONTAINS() is a new function introduced in SQL Server 2025 that lets you check whether a value exists at a specific path in a JSON document. It returns an integer. This is 1 if the value is found, 0 if not, and NULL if any argument is null or the path doesn’t exist. That makes it a natural fit for WHERE clauses when you’re filtering rows based on JSON content.
It’s currently in preview (although this will almost certainly change soon) and only available from SQL Server 2025.
SQL Server added native JSON support back in SQL Server 2016, and as of SQL Server 2025, it officially introduced a dedicated JSON data type. If you’re on an older version, you’ve probably been storing JSON in NVARCHAR(MAX) columns and parsing it with functions like JSON_VALUE() and OPENJSON(). That still works, but the new JSON type gives you validation, better storage, and cleaner semantics.
And along with the JSON type, we get some new JSON related features. Let’s take a quick walk through.
The query plan cache (also called the plan cache or procedure cache) is an area of SQL Server’s memory that stores compiled execution plans for queries and stored procedures. When you execute a query, SQL Server compiles it into an execution plan (basically, a set of instructions for retrieving and processing data). Now, instead of recompiling that plan every time the same query runs, SQL Server stores it in the plan cache for reuse.
This caching mechanism significantly improves performance. Compiling a query plan requires CPU time and resources. The optimizer must analyze statistics, evaluate indexes, consider join orders, and make numerous decisions about the most efficient execution strategy. By caching plans, SQL Server avoids repeating this work for queries that execute repeatedly.
The basic syntax for adding a column in SQL Server is just two lines. But there are enough edge cases to really throw you off guard if you’re not careful. Your actual code will depend on things like, how you define the column, whether the table already has data, what constraints you need, etc. In the real world, there’s quite a bit more to know than just two lines.
This guide walks through all the common scenarios so you have a solid reference regardless of what you’re trying to do.
When you’re managing multiple products across different sales channels or regions, raw data tables don’t usually cut it. You need to see everything at once. For example, which products are crushing it online but underperforming in retail, or which regions are driving growth while others stagnate. A product performance matrix gives you that bird’s-eye view, turning rows of transaction data into a grid that shows patterns instantly.
If you’re getting SQL Server error 2744 that reads “Multiple identity columns specified for table…“, it looks like you’re trying to define a table to have more than one identity column.
SQL Server restricts identity columns to just one per table. If you try to add another one, you’ll get the above error.
The easiest way to address this issue is to leave the table with one identity table and be done with it. But that might not always be practical. Maybe you need a column that increments a different value than the identity column. Fortunately, there are ways of doing that.
JSON has become a common format for data exchange, and SQL Server’s built-in JSON support makes it straightforward to work with JSON data directly in your queries. But what happens when you need to pivot JSON data – transforming nested structures or array elements into a columnar format for reporting or analysis?
SQL Server provides functions like OPENJSON(), JSON_VALUE(), and JSON_QUERY() that let you extract and manipulate JSON data. Combined with standard pivoting techniques, you can reshape JSON data into whatever format you need. This can be particularly useful when you’re receiving JSON from APIs, storing semi-structured data, or working with configuration data that doesn’t fit neatly into traditional tables.