sqlserver-query-patterns

Optimize SQL Server queries, design indexes, and refactor stored procedures.

5|Updated Apr 4, 2026
One-click install
npx skills add https://github.com/iamBrzDev/enterprise-agent-skills --skill sqlserver-query-patterns
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: sqlserver-query-patterns
Source: https://github.com/iamBrzDev/enterprise-agent-skills/tree/main/skills/sqlserver-query-patterns
Command: npx skills add https://github.com/iamBrzDev/enterprise-agent-skills --skill sqlserver-query-patterns

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Slow queries, inefficient indexing, and poorly written stored procedures cause high resource usage, long response times, and unreliable reporting in SQL Server and Azure SQL environments. This Skill provides a pragmatic, checklist-driven approach to identify bottlenecks, remove common anti-patterns (for example SELECT *, non-sargable filters, cursors, and NOLOCK misuse), and recommend indexing and query refactors to restore predictable performance.

Core Features & Use Cases

  • Index strategy and maintenance guidance including when to rebuild vs reorganize and how to create covering or filtered indexes to eliminate key lookups.
  • Query and stored procedure refactoring patterns: set-based replacements for cursors, pagination with OFFSET/FETCH, CTEs for aggregation, and templates for robust procedures.
  • Diagnostics and tooling: how to read estimated and actual execution plans, identify operators with high cost, and use DMVs to find missing or unused indexes.
  • Use Case: Troubleshoot a slow reporting stored procedure that scans a large orders table, propose index changes, and provide a refactored query that supports pagination and a total-count window function.

Quick Start

Analyze the slow stored procedure usp_GetOrdersByCustomer, identify query plan bottlenecks, recommend index and schema adjustments, and produce a refactored T-SQL query with pagination and safety checks.

Frequently Asked Questions about sqlserver-query-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I optimize slow SQL Server queries and reduce high resource consumption?

Optimize slow SQL Server queries by analyzing execution plans to find high-cost operators, replacing cursors with set-based T-SQL patterns, and designing covering or filtered indexes to eliminate key lookups and reduce resource consumption.

How do I read a SQL Server execution plan to find missing indexes?

Read a SQL Server execution plan by identifying operators with high cost and using dynamic management views to find missing or unused indexes. This diagnostic process reveals where to add covering indexes to prevent full table scans and improve query performance.

Does this query optimization approach work with Azure SQL and T-SQL stored procedures?

Yes, this query optimization approach works with both SQL Server and Azure SQL when refactoring T-SQL stored procedures. It applies set-based patterns, pagination with OFFSET/FETCH, and safety practices like SET NOCOUNT ON to improve procedure reliability and execution speed.

What is the best way to fix a non-sargable filter causing a table scan in T-SQL?

Fix a non-sargable filter in T-SQL by removing functions from indexed columns in your WHERE clause, enabling the query optimizer to use index seeks instead of full table scans and restoring predictable query performance.

When should I use a filtered index instead of a covering index in SQL Server?

Use a filtered index in SQL Server when you need to optimize a specific subset of data, whereas a covering index is better when you need to include all columns referenced in a query to eliminate key lookups entirely and speed up reporting aggregations.

Why does my SQL Server reporting stored procedure scan a large table even with indexes present?

A SQL Server reporting stored procedure scans a large table even with indexes present when the query uses non-sargable filters, NOLOCK misuse, or lacks a covering index. Refactoring to set-based T-SQL and adding appropriate indexes resolves the bottleneck.