Press "Enter" to skip to content

Curated SQL Posts

Starting Points for Query Tuning

Published 2026-07-08 by Kevin Feasel

Deborah Melkin shares some tips:

This one is really timely for me as I just started a new job. Performance tuning was part of the interview process so I’m really excited to dive back into doing more of that day-to-day. In fact, I just got added to the email reports with the top SQL results for the worst performers. Here’s some of what I’ll start looking at in that list and why:

Click through for Deborah’s red flag list. Of note, a red flag is not necessarily a bad thing. But it does merit further inspection and comment. For example, there may be specific instances in which join hints are necessary—you know you’re joining from a very small filtered subset to grab a tiny percentage of a bigger table (and you have an appropriate index on said bigger table), and so you slap on a LOOP join hint because the optimizer keeps trying to sort and merge join. But it’s worth explaining why and figuring out if there’s a better way, especially considering the consequences of slapping on that join hint.

Comments closed

Proper Disdain for ANSI-89 Join Format

Published 2026-07-08 by Kevin Feasel

Andy Brownsword has it together:

It’s a legacy pattern, and thankfully it’s rare to see these in the wild nowadays.

The legacy OUTER JOIN syntax (*= and =*) which used to accompany these was deprecated, and finally removed in *checks watch* SQL Server 2012, so that’s one less reason to see the aging syntax.

Every time I see this format, I despise it. Andy explains exactly why. We’ve had better options for more than 30 years, yet people still choose to write code this way.

Comments closed

Pain Points for a Query

Published 2026-07-07 by Kevin Feasel

Vlad Drumea comes up with a list:

This is my list of “main suspects” that make me instantly think a query is bad as soon as I see at least one of them.

Note, this is just based on the query text alone, seeing the execution plan is an instant confirmation.

Now, without further ado and in no specific order:

Click through for the list. There are some good items on it.

Comments closed

Monitoring the Refresh of a Semantic Model

Published 2026-07-07 by Kevin Feasel

Reitse Eskens checks the logs:

As you’ve probably heard and read before, monitoring your Fabric environment as a whole is quite important. It really does help to know what’s going on.
Now, one thing I’ve learned over all these years is that report users do quite like their data to be as fresh and up to date as possible. And, when the data seems stale, they tend to ask questions.

Read on for some notes covering how to refresh a semantic model, when you might want to, how to automate it, and how to monitor the refresh process.

Comments closed

Tabular Editor CLI 0.6.0 Release

Published 2026-07-07 by Kevin Feasel

Ruben Van de Voorde announces a new update:

Since announcing the Tabular Editor CLI, we’ve been hard at work polishing the CLI and bashing the bugs we found, thanks to your help. We deeply appreciate all the input we received so far through GitHub, talking to you at events, comments on these blogs, and all other channels you engage with us (leave yours at the bottom of this page). Keep it coming!

We’re now at a point where we feel ready to share the updated version with you: version 0.6.0.

This is still in a limited public preview, so it’s free until the end of September. After that point, it becomes a paid product.

Comments closed

The Pain of Functions Wrapping Columns in a WHERE Clause

Published 2026-07-07 by Kevin Feasel

Rebecca Lewis answers a question:

This post is part of T-SQL Tuesday #200, hosted this month by Brent Ozar. The prompt: “When I’m looking at a query, I bet it’s bad if I see ____.”

Easy. I didn’t even have to think about it. When I open a stored procedure and see a function wrapped around a column in the WHERE clause, I groan. Out loud. Because more often than not, it means the predicate is non-SARGable, and non-SARGable means your indexes just became very expensive shelf decorations.

That is a pretty good answer, yes. Almost nothing good comes from wrapping columns with functions in the WHERE clause or as part of a join criterion.

Comments closed

A Primer on OneLake Security

Published 2026-07-07 by Kevin Feasel

James Serra takes us through the different security models in Microsoft Fabric:

The idea behind Fabric OneLake Security (which GA’d on April 2026) is to centralize data access controls at the data layer, rather than configuring security separately for every Fabric experience. You define security once, close to the data in OneLake, using roles that can control access at the folder, table/object, row, and column levels through object-level security (also called Table-level and folder-level security), row-level security (RLS), and column-level security (CLS). Those rules are then enforced by supported Fabric engines and access paths, such as Lakehouse, Spark notebooks, the SQL analytics endpoint in user identity mode, and Power BI Direct Lake semantic models. Downstream experiences that go through those governed paths, such as Power BI reports or Excel connected through the semantic model, inherit the same secured view of the data.

However, OneLake security is not the native security model for every data location in Fabric.

Read on to see which components use what security models, as well as some hints as to the vision for Microsoft Fabric’s ultimate security model.

Comments closed

A Primer on Microsoft Fabric for SQL Server Professionals

Published 2026-07-07 by Kevin Feasel

Kevin Chant gives the low-down on Microsoft Fabric:

This post covers how you can spread your SQL Server wings with Microsoft Fabric in 2026. As part of a long-running series of posts about spreading your SQL Server wings with the Microsoft Intelligent Data Platform.

Just after Microsoft Fabric was publicly announced during Microsoft Build 2023, I published a post that covered spreading your SQL Server wings with Microsoft Fabric.

A lot has changed since then. Including Microsoft Fabric becoming generally available and the introduction of more workloads. Since Data Days is currently taking place, I decided to publish an updated version.

There’s a lot that has changed in the product, meaning that if your experience with it was how it looked in early 2024, it’s a different world now.

Comments closed

When Additional Data Doesn’t Shrink Confidence Intervals

Published 2026-07-06 by Kevin Feasel

John Cook follows Betteridge’s Law of Headlines:

In general, new information reduces your uncertainty regarding whatever you’re estimating. The posterior distribution becomes more concentrated as more data are collected.

That’s what happens “in general” but does it necessarily happen every time you get new data? Conceivably if you get surprising data, data that is very unlikely given your current prior, posterior uncertainty might increase.

Click through for an example, as well as a pair of good comments on the post.

Comments closed