AI SQL Tuner

Comprehensive Guide to SQL Server Tuning

Introduction: Why SQL Server Tuning Matters

SQL Server remains the backbone of mission-critical applications, from high-velocity OLTP systems to complex analytical data warehouses. As workloads grow in scale and complexity, tuning SQL Server for optimal performance is no longer optional—it is essential for ensuring reliability, responsiveness, and cost efficiency. This comprehensive guide serves as the authoritative pillar page for SQL Server tuning, designed for database professionals, architects, and performance engineers. It covers every major aspect of SQL Server optimization, from operating system fundamentals to advanced indexing strategies, and highlights how AI SQL Tuner can automate and enhance each step.

For deeper diagnostics, explore the SQL Server Health Check and Sample Health Check Recommendations.

Operating System Fundamentals: Multitasking and Process State Management

The Disparity Between Disk and CPU Speeds: Enabling Multitasking

Modern operating systems are built to maximize CPU utilization, especially given the vast speed disparity between CPUs and disk subsystems. CPUs execute billions of instructions per second, while disk I/O operations are orders of magnitude slower. This gap enables multitasking—even on single-CPU systems—by allowing the operating system to switch between processes whenever one becomes blocked on slow I/O operations. Multiprogramming ensures that while one process waits for disk or network I/O, the CPU can be allocated to another ready process, thus keeping the system responsive and efficient.

Multitasking is implemented through context switching, where the OS saves the state of the currently running process and loads the state of another process. This can be triggered by hardware interrupts, time-slicing (preemptive multitasking), or voluntary yielding (cooperative multitasking). Preemptive multitasking, used by most modern OSes, ensures that no single process monopolizes the CPU, improving overall system responsiveness.

Process States and Transitions: The Finite State Machine Model

Processes in an operating system transition through several well-defined states, typically modeled as a finite state machine (FSM). The most common states include:

New: The process is being created.
Ready: Loaded into memory, waiting for CPU allocation.
Running: Actively executing on the CPU.
Blocked/Waiting: Waiting for I/O or another resource.
Terminated: Finished execution or killed.
Suspend Ready/Blocked: Swapped out of memory due to resource constraints.

Transitions between these states are governed by events such as scheduling decisions, I/O completion, or process termination. For example, a process moves from Ready to Running when the scheduler assigns it the CPU, and from Running to Blocked when it requests I/O. The FSM model provides a rigorous framework for understanding and predicting process behavior, which is crucial for diagnosing performance bottlenecks and deadlocks in SQL Server environments.

For real-world examples of OS‑level bottlenecks, see the Comprehensive SQL Server Health Check.

SQL OS: Thread and Task Architecture Compared to Traditional Operating Systems

SQL OS Overview

SQL Server runs as a service atop the host operating system but implements its own internal operating system layer—known as SQL OS—to manage threads, memory, and I/O with database-specific optimizations. SQL OS abstracts away many host OS details, providing a cooperative scheduling model, custom memory management, and fine-grained I/O control tailored for database workloads.

Worker Threads: SQL Server creates worker threads to execute tasks. Each query or batch request is mapped to one or more tasks, which are then assigned to worker threads.
Schedulers: SQL OS maintains a scheduler per logical CPU, managing the assignment of worker threads to CPUs. The scheduler enforces a quantum (typically 4 ms) for each thread, after which it yields to allow other threads to run.
Cooperative Scheduling: Unlike the host OS’s preemptive model, SQL OS uses cooperative (non-preemptive) scheduling. Threads voluntarily yield after their quantum or when waiting for resources, reducing context switching overhead and improving throughput for database workloads.

Comparison: SQL OS vs. Traditional Operating System

Feature	SQL OS (SQL Server)	Traditional OS (Windows/Linux)
Scheduling	Cooperative, quantum-based	Preemptive, time-slice or event
Thread Management	Worker threads, mapped to CPUs	OS threads, managed by kernel
Memory Management	Buffer pool, custom allocators	Virtual memory, paging, swapping
I/O Handling	Direct file access, async I/O	File system, block device drivers
Process States	RUNNING, RUNNABLE, SUSPENDED	Running, Ready, Blocked, etc.

SQL OS is optimized for high concurrency and low-latency access to data, with mechanisms such as buffer pool management, latch-free metadata tables, and custom I/O scheduling. This allows SQL Server to outperform generic OS scheduling for database workloads, especially under heavy load or high parallelism.

To understand how AI SQL Tuner interprets SQL OS signals, see:

User Guide

AI SQL Tuner Product Overview

Sizing Guidance for SQL Server Deployments

CPU Selection: High Single-Core Performance for OLTP

For OLTP workloads, single-core performance is paramount. OLTP queries are typically short, frequent, and sensitive to latency. CPUs with high clock speeds and strong single-threaded performance deliver the best results, as many OLTP operations are not easily parallelized. Hyper-threading (SMT) can improve throughput, but the base single-core speed remains the most critical factor.

Recommendation: Choose CPUs with the highest available single-core performance, even if total core count is moderate.

AI SQL Tuner identifies CPU pressure and slow query patterns in Fix Slow SQL Queries.

RAM-to-CPU Ratio Recommendations

Memory sizing is crucial for SQL Server performance. The buffer pool should be large enough to cache hot data, reducing disk I/O. For OLTP workloads, a common guideline is to allocate RAM at least equal to the size of the active dataset, plus additional memory for query workspace and system overhead.

General Rule: Allocate 85% of total server memory to SQL Server, leaving 15% for the OS and other processes. If the server is also running other processes aside from the SQL Server Engine, for example, SSAS, SSIS or SSRS, reduce the allocation.
OLTP: Prioritize buffer pool size; aim for 4 to 8 GB RAM per CPU core.
DW/Analytics: Larger RAM pools support bigger scans and aggregations; ratios may be higher.

Disk Configuration Best Practices

Disk I/O is often the bottleneck in SQL Server performance. Best practices include:

Use SSDs or NVMe drives for data, log, and tempdb files to minimize latency.
Separate data, log, and tempdb files onto distinct physical disks or storage pools to avoid contention¹³¹²⁸.
RAID 10 is recommended for data files for both performance and redundancy; RAID 1 for transaction logs.
Preallocate file sizes to avoid autogrow delays, especially for transaction logs and tempdb.

Tempdb Configuration Best Practices

Tempdb is a global workspace for temporary objects, version stores, and internal operations. Misconfiguration can lead to severe contention and performance degradation.

Number of Data Files: For ≤8 logical CPUs, use one tempdb data file per CPU. For >8 CPUs, start with 8 files and increase by multiples of 4 if contention persists.
Equal Sizing: All tempdb data files should have the same initial size and autogrow settings.
Place tempdb on fast storage (SSD/NVMe), ideally on a dedicated disk.
Enable instant file initialization for faster growth operations.
Monitor for allocation contention (PAGELATCH_UP waits) and adjust file count as needed.

For examples of tempdb‑related findings, see the Health Check Recommendations.

Best Practices for Running SQL Server on Virtual Machines (VMware Guidance)

VMware vSphere and VCF: Key Considerations

Virtualizing SQL Server offers flexibility, scalability, and cost savings, but requires careful sizing and configuration⁸.

Right-Sizing: Allocate only the resources needed for the workload. Over-provisioning vCPUs or memory increases overhead and can degrade performance.
vCPU Allocation: Do not assign more vCPUs than physical cores available on the host. For high-performance workloads, match vCPU count to physical core count.
Memory Sizing: Avoid memory overcommitment at the ESXi host level. Use SQL Server DMVs to monitor actual memory usage.
NUMA Awareness: SQL Server is NUMA-aware; ensure VM memory and vCPU allocation aligns with physical NUMA nodes to avoid cross-node latency.
Storage Separation: Place SQL Server binaries, data, log, and tempdb files on separate VMDKs/datastores. For critical databases, maintain 1:1 mapping between VMDKs and LUNs.
Use VMware Paravirtualized SCSI (PVSCSI) Controllers for data and log disks to optimize I/O.
Monitor and Adjust: Continuously monitor resource usage and adjust allocations as workload changes.

Reference Table: VM Sizing Examples

vCPU	RAM (GB)	Use Cases
8	32-64	OLTP, small DW
16	64-128	Large DW, HTAP
32	128-256	Enterprise DW

This table summarizes recommended VM sizing configurations for SQL Server workloads on VMware vSphere, emphasizing the alignment of vCPU count, RAM, and virtual NUMA nodes with the targeted use cases. The number of vNUMA nodes corresponds to the VM’s vCPU allocation and memory to optimize NUMA alignment and minimize cross-node latency, which is critical for high-performance OLTP, analytical data warehousing, and hybrid transactional/analytical processing (HTAP) workloads【†8†】.

For OLTP and small data warehouse (DW) workloads, 8 vCPUs paired with 32 GB RAM and 1 vNUMA node provide balanced compute and memory resources with minimal NUMA overhead.
For large DW and HTAP workloads, scaling up to 16 vCPUs with 128 GB RAM and 2 vNUMA nodes ensures sufficient parallelism and memory capacity for complex analytics while maintaining NUMA locality.
For enterprise-class DW environments, 32 vCPUs, 256 GB RAM, and 4 vNUMA nodes support extremely high concurrency, large buffer pools, and parallel processing, delivering top-tier performance at scale.

Proper VM configuration along these guidelines helps avoid performance bottlenecks caused by over- or under-provisioning and NUMA misalignment, ensuring VMware-hosted SQL Server instances achieve near-native physical server efficiency.

Key Configuration Settings: Parallelism, Memory, and TempDB

Parallelism

MAXDOP (Max Degree of Parallelism): Limits the number of CPUs used for parallel queries. For OLTP, set MAXDOP to the number of physical cores in a single NUMA node (typically ≤8). For DW workloads, higher values may be appropriate.
Cost Threshold for Parallelism: Default is 5; increase to 20–50 for OLTP to prevent small queries from running in parallel and consuming excessive CPU²⁰¹⁹.

Workload	MAXDOP	Cost Threshold
OLTP	8	20–50
DW	16+	5–20

Analysis: Setting MAXDOP too high can cause CPU spikes and slow down other queries. Always tune queries first before increasing parallelism. For DW, parallelism is beneficial for large scans and aggregations, but monitor for CXPACKET waits and adjust as needed.

Max Server Memory Settings

SQL Server dynamically manages memory, but setting appropriate limits is critical.

Max Server Memory: Set to 80–90% of total system RAM, leaving 10–20% for the OS and other applications.
Min Server Memory: Ensures SQL Server retains a baseline amount of memory, useful in multi-instance or virtualized environments.
Do not set min and max to the same value; allow SQL Server to manage memory dynamically.

OLTP: Prioritize buffer pool size for caching hot data. DW: Larger memory pools support bigger scans and aggregations.

Tempdb Configuration: OLTP vs. Data Warehouse

OLTP: Tempdb is used for version stores, triggers, and temporary tables. Prioritize fast storage and sufficient data files to avoid contention.
DW: Tempdb handles large sorts, hash joins, and index operations. May require more data files and larger initial sizes.

Best Practices:

Monitor tempdb usage and adjust file count and size as needed.
Enable tempdb space governance in SQL Server 2025 to cap usage per workload group.

AI SQL Tuner automatically checks for misconfigurations in its Server Health Check.

Coding Best Practices: RBAR, Cursors, and Set-Based Alternatives

RBAR (Row By Agonizing Row): Performance Implications

RBAR refers to SQL code that processes data one row at a time, typically using loops or cursors. While easy to understand, RBAR patterns are performance killers in SQL Server²³.

Symptoms: High CPU usage, excessive reads, lock escalation, deadlocks, and slow stored procedures.
Common Sources: Cursors, WHILE loops, scalar UDFs called per row, triggers with row-based logic.

Impact: RBAR neutralizes SQL Server’s set-based engine optimizations, crippling throughput and scalability.

Cursors: Impact and Alternatives

Cursors allow row-by-row processing but are generally discouraged for large datasets due to performance overhead²⁴²⁵.

Best Practice: Replace cursors with set-based operations (JOINs, MERGE, GROUP BY, window functions).
Exceptions: Use fast-forward cursors for small, read-only operations where set-based logic is unwieldy.

Set-Based Rewrite Example:

UPDATE s
SET s.QuantityAvailable = s.QuantityAvailable - w.QtyUsed
FROM Stockline s
INNER JOIN WorkOrderParts w ON s.PartId = w.Id;

This replaces hundreds of row-level updates with a single statement, reducing locks and reads.

Summary Table: RBAR vs. Set-Based

Pattern	RBAR Example	Set-Based Alternative	Performance Impact
Cursor Loop	WHILE/FETCH NEXT	JOIN/MERGE	Set-based is 10–100x faster
Scalar UDF	SELECT Id, dbo.Func(Id)	CROSS APPLY, JOIN	Set-based avoids per-row calls
Trigger	EXEC ValidateRow @Id	Bulk INSERT/UPDATE	Set-based supports bulk ops

AI SQL Tuner identifies RBAR and other antipatterns in:

Code Review Tuning Goal
T‑SQL Code Review Example

Transaction Control and Management: RCSI and Locking Mechanisms

Read Committed Snapshot Isolation (RCSI): Benefits and Trade-Offs

RCSI is a database option that changes the behavior of the default READ COMMITTED isolation level from locking to row versioning²⁶.

Benefits: Dramatically reduces blocking and deadlocks by allowing readers to access a consistent snapshot of data without waiting for writers.
Trade-Offs: Increases tempdb usage due to version store growth. Long-running transactions can cause tempdb bloat and risk out-of-space errors.

Best Practice: Monitor tempdb version store usage and avoid long-running transactions under RCSI. Use tempdb space governance to cap usage per workload group²².

AI SQL Tuner highlights blocking and deadlock patterns and provides recommendations for RCSI in:

Fix Deadlocks
Fix SQL Server Deadlocks Blog

Locking Mechanisms and Types of Locks

SQL Server uses locks to maintain ACID properties and concurrency²⁷²⁸.

Shared (S) Lock: Allows concurrent reads; blocks writers.
Exclusive (X) Lock: Prevents other transactions from reading or writing.
Update (U) Lock: Used during updates to prevent deadlocks.
Intent Locks (IS, IX, SIX): Indicate intention to acquire locks at lower granularity.
Schema Locks (Sch-M, Sch-S): Protect schema modifications and stability.
Bulk Update, Key Range Locks: Used for bulk operations and serializable isolation.

Analysis: Use the lowest necessary isolation level and lock granularity to maximize concurrency. Monitor lock waits and escalation using DMVs.

Indexing Strategies: B-Tree, Columnstore, and Advanced Index Types

B-Tree Indexes: Fundamentals

Most SQL Server indexes are B-Trees (technically B+ trees), providing efficient seeks and range scans.

Clustered Index: Defines the physical order of rows; only one per table. Leaf pages contain actual data.
Nonclustered Index: Separate structure with pointers to data rows. Multiple nonclustered indexes can exist per table.
INCLUDE Columns: Add non-key columns to the leaf level, allowing fully covered queries without expanding the key definition.

Best Practice: Choose a narrow, unique, ever-increasing key for clustered indexes. Use nonclustered indexes for frequently queried columns.

Columnstore Indexes: Batch Mode and Analytics

Columnstore indexes store data column-wise, enabling high compression and batch mode execution for analytics workloads³¹.

Benefits: Batch mode processes ~900 rows at once, segment elimination, high compression, reduced I/O.
Use Case: Ideal for data warehouses and large scans; not recommended for OLTP tables with frequent updates.

Hybrid Tables: SQL Server supports tables with both B-tree and columnstore indexes, allowing mixed workloads.

Maintenance: Use REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON) and periodic REBUILDs for columnstore indexes.

Index Types Comparison Table

Index Type	Structure	Use Case	Pros	Cons
Clustered	B-tree, data leaf	Primary key, range scans	Fast seeks, sorts	Only one per table
Nonclustered	B-tree, pointers	Secondary queries	Multiple per table, flexible	Key lookups for missing cols
Columnstore	Columnar, segments	Analytics, DW	Compression, batch mode	Not ideal for OLTP updates
INCLUDE Columns	B-tree, extra cols	Covering queries	Avoids key expansion	Larger index size
Filtered	Subset of rows	Niche optimization	Smaller, faster for subset	Not used for all queries

Learn more about AI SQL Tuner’s index recommendations in:

Advanced Hardware and Configuration Topics

NUMA, CPU Affinity, and Scheduler Considerations

Non-Uniform Memory Access (NUMA) architectures divide memory into nodes associated with specific CPUs. SQL Server is NUMA-aware and can optimize memory and thread allocation accordingly¹⁷¹⁸⁸.

Best Practice: Align SQL Server memory and vCPU allocation with physical NUMA nodes. Avoid imbalanced NUMA configurations, which can cause cross-node latency and inefficient query plans.
CPU Affinity: Use affinity masks to bind SQL Server threads to specific CPUs if needed, but avoid conflicting OS and SQL Server settings.

In-Memory OLTP Hardware Sizing

In-Memory OLTP (Hekaton) tables reside fully in memory. Ensure sufficient physical memory for both memory-optimized tables and buffer pool for disk-based tables.

Guideline: Memory-optimized tables should not exceed 256 GB per database. Log drives should be low-latency SSDs; data checkpoint files can use high-performance spindles.

Resource Governor and Tempdb Space Governance

SQL Server 2025 introduces tempdb space governance via Resource Governor, allowing DBAs to cap tempdb usage per workload group²².

Configuration: Set GROUP_MAX_TEMPDB_DATA_MB or GROUP_MAX_TEMPDB_DATA_PERCENT per workload group.
Benefits: Prevents runaway queries from filling tempdb and crashing the instance. Enables fair multi-tenancy and reliable batch windows.

SQL Server on Azure VM: Storage and Tempdb Best Practices

Running SQL Server on Azure VMs introduces unique storage considerations.

Use Premium SSD v2 or Ultra Disks for data and log files to achieve submillisecond latency.
Place tempdb on the ephemeral D:\ SSD for best performance; reconfigure on VM restart as needed.
Separate data, log, and tempdb files onto distinct disks and use Storage Spaces for striping.
Set host caching to read-only for data disks and none for log disks.
Monitor IOPS and throughput using Azure Monitor metrics.

How AI SQL Tuner Supports Each Tuning Area

AI SQL Tuner leverages artificial intelligence and machine learning to automate and enhance SQL Server tuning across all major domains.

Automated Tuning and Workload Analysis

Query Performance Monitoring: Analyzes query execution plans, identifies bottlenecks, and recommends index and configuration changes.
Index Management: Recommends index creates, drops, and modifications based on workload patterns.

Configuration Recommendations

Parallelism Tuning: Suggests optimal MAXDOP and cost threshold settings based on observed query patterns and hardware topology.
Memory Management: Recommends max server memory and buffer pool settings, accounting for OS and other application needs.
Tempdb Optimization: Advises on file count, sizing, and placement, and monitors for allocation contention.

Coding and Indexing Best Practices

RBAR Detection: Flags row-by-row patterns and suggests set-based rewrites, including sample code transformations.
Cursor Analysis: Identifies inefficient cursor usage and recommends set-based alternatives.
Index Health Checks: Spots missing and unused indexes and recommends maintenance tasks.

Hardware and Virtualization Insights

NUMA and Affinity Analysis: Detects imbalanced NUMA configurations and recommends rebalancing for optimal resource use.
VM Sizing Guidance: Monitors resource usage and suggests right-sizing for virtualized environments.

Continuous Learning and Adaptation

AI-Driven Recommendations: Learns from millions of databases to refine tuning actions, adapting to changing workloads over time.
Safe, Reliable Automation: Scripts are provided to easily apply changes. They can be applied to non-productions systems first or deployed during low utilization periods

Conclusion: The Future of SQL Server Tuning with AI SQL Tuner

SQL Server tuning is a multifaceted discipline, requiring expertise in operating system fundamentals, database architecture, hardware sizing, configuration, coding, transaction management, and indexing. As workloads become more complex and dynamic, manual tuning alone cannot keep pace. AI SQL Tuner represents the next evolution in database optimization, automating best practices, learning from global workloads, and delivering safe, reliable performance improvements.

By following the guidance in this page and leveraging AI SQL Tuner’s automated capabilities SQL Server professionals can ensure their databases remain fast, resilient, and cost-effective, whether running on-premises, in virtualized environments, or in the cloud.

Explore AI SQL Tuner’s automated tuning features today to unlock peak SQL Server performance for your mission-critical workloads.

Start optimizing today:

Key Takeaways:

Multitasking and process state management are foundational for SQL Server’s high concurrency.
SQL OS provides database-optimized scheduling, memory, and I/O handling.
Sizing guidance emphasizes high single-core CPU performance, sufficient RAM, and fast, separated storage.
Tempdb configuration and governance are critical for stability and concurrency.
Virtualization requires right-sizing, NUMA awareness, and storage separation.
Parallelism, memory, and tempdb settings must be tuned for workload type.
Coding best practices favor set-based operations over RBAR and cursors.
RCSI improves concurrency but requires tempdb monitoring.
Indexing strategies must balance B-tree and columnstore approaches for OLTP and DW.
AI SQL Tuner automates tuning, workload analysis, and configuration, adapting to changing environments.

References

Computer multitasking – Wikipedia. https://en.wikipedia.org/wiki/Computer_multitasking

States of a Process in Operating Systems – GeeksforGeeks. https://www.geeksforgeeks.org/operating-systems/states-of-a-process-in-operating-systems/

MSSQL SERVER: Schedulers and Threads – Database Math. https://databasemath.com/2021/04/23/mssql-server-schedulers-and-threads/

Understanding SQL Server Schedulers, Workers and Tasks. https://www.mssqltips.com/sqlservertip/4403/understanding-sql-server-schedulers-workers-and-tasks/

Microsoft SQL Server CPU configuration – NetApp. https://docs.netapp.com/us-en/ontap-apps-dbs/mssql/mssql-cpu-configuration.html

Architecting Microsoft SQL Server on VMware Cloud Foundation®. https://www.vmware.com/docs/architecting-mssql-vcf

Setting up memory and resources to improve MS SQL Server performance. https://sqlserverrecovery.org/database-performance-how-to-configure-ms-sql-for-business/setting-up-memory-and-resources-to-improve-ms-sql-server-performance/

Performance Tuning Series – Memory Management | SQL Freelancer Blog. https://www.sqlfreelancer.com/blog/performance-tuning-series-memory-management/

Min and Max memory configurations in SQL Server Database instances. https://www.sqlshack.com/min-and-max-memory-configurations-in-sql-server-database-instances/

Performance Tuning Series – Storage Optimization: Maximizing Disk …. https://www.sqlfreelancer.com/blog/performance-tuning-series-storage-optimization-maximizing-disk-performance/

Place Data and Log Files on Separate Drives – SQL Server. https://learn.microsoft.com/en-us/sql/relational-databases/policy-based-management/place-data-and-log-files-on-separate-drives?view=sql-server-ver17

tempdb Database – SQL Server | Microsoft Learn. https://learn.microsoft.com/en-us/sql/relational-databases/databases/tempdb-database?view=sql-server-ver17

Recommendations to reduce allocation contention – SQL Server. https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/recommendations-reduce-allocation-contention

Top 4 TempDB Best Practices for Optimal Performance – Red9. https://red9.com/blog/best-practices-for-the-sql-server-tempdb-files/

SQL Server: Clarifying The NUMA Configuration Information. https://techcommunity.microsoft.com/blog/sqlserversupport/sql-server-clarifying-the-numa-configuration-information/316753

SQL Server 2025: NUMA Affinity, Rebalanced & Reimagined – LinkedIn. https://www.linkedin.com/pulse/sql-server-2025-numa-affinity-rebalanced-reimagined-michael-fuller-idvle/

The Hidden Cost of MAXDOP: CPU Spikes, Query … – SQLServerCentral. https://www.sqlservercentral.com/articles/the-hidden-cost-of-maxdop-cpu-spikes-query-slowdowns-and-what-we-learned

Need Recommendations for MAXDOP and Cost Threshold for Parallelism in …. https://learn.microsoft.com/en-us/answers/questions/2103761/need-recommendations-for-maxdop-and-cost-threshold

Server Memory Configuration Options – SQL Server | Microsoft Learn. https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/server-memory-server-configuration-options?view=sql-server-ver17

Controlling TempDB Resources with Resource Governor in SQL Server 2025. https://www.sqltabletalk.com/?p=1171

Set-Based Operations vs RBAR in SQL: Why It Matters – LinkedIn. https://www.linkedin.com/pulse/set-based-operations-vs-rbar-sql-why-matters-darwin-pasco-hnkkc

Replace SQL Cursors with Set Based Operations – SQL Server Tips. https://www.mssqltips.com/sqlservertip/8002/replace-sql-cursors-with-set-based-operations-output-merge/

SQL Server Fast Cursors: Performance and Best Practices. https://tech-champion.com/data-science/sql-server-fast-cursors-performance-and-best-practices/

TempDB’s Version Store: The Risk of Long Transactions with RCSI …. https://databasehealth.com/tempdbs-version-store-the-risk-of-long-transactions-with-rcsi/

Types of Locks in SQL Server Baeldung on SQL. https://www.baeldung.com/sql/ms-sql-locks

Understanding Locking Levels in SQL Server Explained | MoldStud. https://moldstud.com/articles/p-locking-levels-in-sql-server-a-comprehensive-guide-to-shared-exclusive-and-update-locks

Clustered and Nonclustered Indexes – SQL Server. https://learn.microsoft.com/en-us/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-described?view=sql-server-ver17

Clustered and Non-Clustered Indexing – GeeksforGeeks. https://www.geeksforgeeks.org/sql/clustered-and-non-clustered-indexing/

SQL Server Columnstore, B-Tree and Hybrid Index Performance Comparison …. https://www.mssqltips.com/sqlservertip/4158/sql-server-columnstore-btree-and-hybrid-index-performance-comparison-for-data-warehouses/

Checkpoint Operation for Memory-Optimized Tables – SQL Server. https://learn.microsoft.com/en-us/sql/relational-databases/in-memory-oltp/checkpoint-operation-for-memory-optimized-tables?view=sql-server-ver17

Place tempdb on ephemeral storage for SQL Server on Azure VMs. https://github.com/MicrosoftDocs/sql-docs/blob/live/azure-sql/virtual-machines/windows/tempdb-ephemeral-storage.md

Automatic Tuning Overview – Azure SQL & SQL database in Fabric. https://learn.microsoft.com/en-us/azure/azure-sql/database/automatic-tuning-overview?view=azuresql

Optimizing Your Sql Database Workloads With Automatic Tuning on Azure. https://www.hugobarona.com/optimizing-your-sql-database-workloads-with-automatic-tuning-on-azure/