In last week's Query Exercise, we added a user-defined function to the Users table to check whether their WebsiteUrl was valid or not. I noted that even with an index on Reputation, SQL Server 2022 simply ignored the index, did a table scan, and spent 2 minutes of time calling the user-defined function on a row-by-row basis.
Take any size of the Stack Overflow database and check out the WebsiteUrl column of the Users table:
Sometimes it's null, sometimes it's an empty string, sometimes it's populated but the URL isn't valid.
I'm not talking just about Microsoft SQL Server specifically here, nor T-SQL. Let's zoom out a little and think bigger picture for a second: is the SQL language itself a problem?
Sometimes when I talk to client developers, they gripe about the antiquated language.
For this week's Query Exercise, I asked you to write a better query than ChatGPT wrote. Your goal was to find the best days and times to post questions on Stack Overflow.
I found it interesting that a lot of the initial answers focused on the times when there were the most questions, or which questions were the most highly upvoted. For me, the best time to post a question is when you have the highest likelihood of getting the right answer, quickly.
What are the best days of the week and times of the day to post a question at StackOverflow.com? It seems like a simple question, but it's surprisingly nuanced. I asked ChatGPT's latest version, 4o, and its answer made me laugh out loud. First off, the T-SQL is terrible: it creates a completely unnecessary temp…
In last week's post, I gave you a trigger that populated a history table with all changes to the Users.AboutMe column. It was your job to write a T-SQL query that turned these Users_Changes audit table rows:
Into the full before & after data for each change, like the earlier query from the blog post:
Your challenge for this week was to find out who keeps mangling the contents of the AboutMe column in the Stack Overflow database.
Conceptually, there are a lot of ways we can track when data changes: Change Tracking, Change Data Capture, temporal tables, auditing, and I'm sure I'm missing more. But for me, there are a couple of key concerns when we need to track specific changes in a high-throughput environment:
For this week's Query Exercise, your challenge is to find out who keeps messing up the rows in the Users table.
Take any size version of the Stack Overflow database, and the Users table looks like this:
For this month's T-SQL Tuesday, Pinal Dave asked us if AI has helped us with our SQL Server jobs. For me, there's been one instant, clear win: code reviews. I usually keep a browser tab open with ChatGPT 4, and I paste this in as a starting point: You are an experienced, diligent database developer…
I didn't say that - Guy Glantser did.
Guy Glantser is an Israeli SQL Server guru with a ton of great presentations on YouTube. I've had the privilege of hanging out with him in person a bunch of times over the year, and I'll always get excited to do it again. He's not just smart, but he's friendly and funny as hell.
This week's query exercise asked you to find two kinds of locations in the Stack Overflow database:
Locations populated with users who seem to be really helpful, meaning, they write really good answers
Locations where people seem to need the most help, meaning, they ask a lot of questions, but they do not seem to be answering those of their neighbors
For this week's query exercise, let's start with a brief query to get a quick preview of what we're dealing with:
[crayon-6a79ccc9bad61652047051/]
That query has a few problems, but hold that thought for a moment. (You're going to have to solve those problems, but I just wanted to show you the sample data at first to give you a rough idea of what we're dealing with.)
Your query exercise for this week was to write a query to find users created in the last 90 days, with a reputation higher than 50 points, from highest reputation to lowest. Because everyone's Stack Overflow database might be slightly different, we had to start by finding the "end date" for our query. I'm working with the 2018-06 export that I use in my training classes, so here's my end date:
For this week's Query Exercise, we're working with the Stack Overflow database, and our business users have asked us to find the new superstars. They're looking for the top 1000 users who were created in the last 90 days, who have a reputation higher than 50 points, from highest reputation to lowest. In your Stack…
In last week's Query Exercise, our developers had a query that wasn't going as fast as they'd like:
[crayon-6a79ccc9bc664987490800/]
The query had an index, but SQL Server was refusing to use the index - even though the query would do way less logical reads if it used the index. You had 3 questions to answer:
Our developers have come to us with a problem query that isn't as fast as they'd like. Using any Stack Overflow database:
[crayon-6a79ccc9bd0ef413624724/]
It has an index, but SQL Server refuses to use that index in the execution plan:
If we force the index with a query hint, we do indeed get dramatically lower logical reads. In my particular database's case, the clustered index scan is 141,573 logical reads - but scanning the DisplayName index alone is just 38,641 logical reads.
Your challenge for last week was to take this Stack Overflow database query to show the top-ranking users in the most popular location:
[crayon-6a79ccc9bdc74926319965/]
And make it read less pages only by tuning the query? You weren't allowed to make index or server changes, and you weren't allowed to hard code the location in the query since it might change over time.
The Core of the Problem
The main problem is that when we run a statement (like SELECT), SQL Server:
For this month's T-SQL Tuesday, I asked y'all to write about the most recent ticket or issue that you closed. (If you want to see other peoples' posts, you can check out the comments on that invite post, or wait til next week and I'll publish a wrap-up of everyone's answers.)
A past client emailed me with a performance emergency. Things had been going just fine, and then out of nowhere, things suddenly slowed down.
Your challenge for this week is to tune a query. Say Stack Overflow has a dashboard that shows the top-ranking users in their most popular location. It's even got an index to support it:
[crayon-6a79ccc9be278565228475/]
You can test it with any version of the Stack Overflow database. To test it, we'll turn on a couple of tuning options:
[crayon-6a79ccc9be280514532476/]
The actual execution plan does use our index - not just once, but twice:
In the last Query Exercise discussion, we hit a performance wall when we were trying to quickly find questions with a specific tag. We threw up our hands and said it's time to make database changes, but we had a few restrictions: We have a lot of existing code that uses the Posts.Tags column That…
