More Cores, Faster Cores or a Better Query?

In short

Your workload decides whether many cores or fast cores are better, not the data sheet. A single query that runs serially only gets faster with a faster core. More cores help parallel queries and many concurrent sessions, but not without limit and not linearly.

Before you decide on cores, ask what the CPU is working on today. In our lab, 5 percent of the calls consumed 84 percent of the CPU. Doubling the core count brought 43 percent more throughput; the improved query on the old hardware brought 3.6 times as much.

A real CPU bottleneck does not show up in a single number. Long response times alone do not prove it, and neither does the share of signal wait time alone. Only several metrics together give a reliable picture.

The picture: the supermarket checkout

Picture the CPU as the checkout area of a supermarket. Each core is a checkout, and each query is a customer with a cart.

• A faster cashier speeds up every single customer. That is a faster core.
• More checkouts shorten the line, but not the time each customer spends at the checkout. That is more cores for many concurrent queries.
• One big cart, split across several checkouts, is done sooner. Splitting and merging it costs extra work, though. That is a parallel query.
• An overloaded cart blocks a checkout for a long time, no matter how many there are. That is the inefficient query that consumes most of the CPU.

With this picture, the three experiments are easy to read.

In the picture: faster cashier, split cart

Experiment 1: one query, more cores

In the picture: more checkouts

Experiment 2: many sessions, more cores

That 12 cores brought hardly more than 8 is specific to this lab host. Our cores are virtual CPUs under Hyper-V. More virtual CPUs do not automatically mean more physical computing power, for example when they share hyperthreads, clock speed or cache of the host. We have not isolated the exact cause.

In the picture: more checkouts or overloaded cart

Experiment 3: more cores or a better query?

How to recognize a real CPU bottleneck

In the lab we raised the load step by step from 1 to 32 concurrent sessions, on 4 cores. From 16 sessions on, the CPU was at 99 percent, throughput stalled at 922 queries per second, and response times grew with every additional session. For comparison, a completely different case: queries that waited for a lock took 2 seconds while CPU utilization was 0.6 percent. More cores would not have changed anything there.

This yields five metrics that you should look at together:

Two traps. The share of signal wait time in total wait time is not a good measure on its own. With pure compute work there are hardly any other waits; in our lab the share was close to 100 percent at only 26 percent CPU utilization. And an average utilization below 100 percent does not rule out a queue: with a few permanently active connections, two queries at times ran on the same scheduler in our lab while three others stayed empty. That is why it pays to look per scheduler.

The following queries only read the values; we tested them on SQL Server 2017 to 2025. Run them while the problem is occurring. The second one filters out harmless background waits; otherwise it shows high values even on an idle server. Because many tasks wait at the same time, signal wait time per second can be greater than 1,000 milliseconds. For orientation, here are the values per second and core from our lab: about 0.3 ms with a single session, around 440 ms at 75 percent utilization, around 1,080 ms at full saturation. The third one reads the plan cache; on very large systems it can take a few seconds. The values in the plan cache start at the last restart or at the time a plan entered the cache.

Read-only – changes nothing in your database

-- Read-only: queue per scheduler (snapshot)
SELECT scheduler_id, cpu_id,
       current_tasks_count, runnable_tasks_count, active_workers_count
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE'
ORDER BY scheduler_id
OPTION (MAXDOP 1);

-- Read-only: signal wait time per second and per core over 10 seconds,
-- excluding harmless background waits (same list as in the guide, not exhaustive)
IF OBJECT_ID('tempdb..#before') IS NOT NULL DROP TABLE #before;
SELECT wait_type, signal_wait_time_ms
INTO #before
FROM sys.dm_os_wait_stats
OPTION (MAXDOP 1);

WAITFOR DELAY '00:00:10';

DECLARE @cores int = (SELECT COUNT(*) FROM sys.dm_os_schedulers
                      WHERE status = N'VISIBLE ONLINE');
SELECT cores = @cores,
       signal_ms_per_second = SUM(n.signal_wait_time_ms - v.signal_wait_time_ms) / 10.0,
       signal_ms_per_second_per_core = SUM(n.signal_wait_time_ms - v.signal_wait_time_ms) / 10.0 / @cores
FROM sys.dm_os_wait_stats AS n
JOIN #before AS v ON v.wait_type = n.wait_type
WHERE n.wait_type NOT LIKE N'SLEEP[_]%'
  AND n.wait_type NOT LIKE N'BROKER[_]%'
  AND n.wait_type NOT LIKE N'XE[_]%'
  AND n.wait_type NOT LIKE N'QDS[_]%'
  AND n.wait_type NOT LIKE N'HADR[_]%'
  AND n.wait_type NOT LIKE N'PARALLEL[_]REDO[_]%'
  AND n.wait_type NOT IN (
      N'AZURE_IMDS_VERSIONS', N'CHECKPOINT_QUEUE', N'CHKPT', N'CLR_AUTO_EVENT', N'CLR_MANUAL_EVENT',
      N'CLR_SEMAPHORE', N'DBMIRROR_DBM_EVENT', N'DBMIRROR_EVENTS_QUEUE',
      N'DBMIRROR_WORKER_QUEUE', N'DBMIRRORING_CMD', N'DIRTY_PAGE_POLL',
      N'DISPATCHER_QUEUE_SEMAPHORE', N'EXECSYNC', N'FSAGENT',
      N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX', N'KSOURCE_WAKEUP',
      N'LAZYWRITER_SLEEP', N'LOGMGR_QUEUE', N'MEMORY_ALLOCATION_EXT',
      N'ONDEMAND_TASK_QUEUE', N'PREEMPTIVE_OS_FLUSHFILEBUFFERS',
      N'PREEMPTIVE_XE_GETTARGETSTATE', N'PVS_PREALLOCATE',
      N'PWAIT_ALL_COMPONENTS_INITIALIZED', N'PWAIT_DIRECTLOGCONSUMER_GETNEXT',
      N'PWAIT_EXTENSIBILITY_CLEANUP_TASK', N'REDO_THREAD_PENDING_WORK',
      N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESERVED_MEMORY_ALLOCATION_EXT', N'RESOURCE_QUEUE', N'SERVER_IDLE_CHECK',
      N'SNI_HTTP_ACCEPT', N'SOS_WORK_DISPATCHER', N'SP_SERVER_DIAGNOSTICS_SLEEP',
      N'SQLTRACE_BUFFER_FLUSH', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
      N'SQLTRACE_WAIT_ENTRIES', N'VDI_CLIENT_OTHER', N'WAIT_FOR_RESULTS',
      N'WAITFOR', N'WAITFOR_TASKSHUTDOWN', N'WAIT_XTP_CKPT_CLOSE',
      N'WAIT_XTP_HOST_WAIT', N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG', N'WAIT_XTP_RECOVERY')
OPTION (MAXDOP 1);

-- Read-only: the ten queries with the most CPU time since plan creation
SELECT TOP (10)
       cpu_ms_total = qs.total_worker_time / 1000,
       executions = qs.execution_count,
       cpu_ms_per_execution = qs.total_worker_time / 1000.0 / qs.execution_count,
       cpu_share_percent = 100.0 * qs.total_worker_time
                           / SUM(qs.total_worker_time) OVER (),
       query_text = SUBSTRING(st.text, qs.statement_start_offset / 2 + 1, 200)
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY qs.total_worker_time DESC
OPTION (MAXDOP 1);

For high CPU load, the guide SQL Server Slow Under Load walks you from symptom to cause.

Many cores or fast cores?

The experiments suggest a mapping by workload profile. It does not replace measuring your own workload, but it shows what to look for.

Three things that influence the decision

• Licenses. SQL Server generally uses per-core licensing. Every additional core therefore costs more than hardware. Standard Edition also uses only a limited number of cores; more on that in the section on edition in the upgrade decision guide. Your licensing partner can confirm licensing questions for you. We don't sell licenses and therefore advise without a revenue interest.
• Virtualization. A virtual CPU is not a physical core. Whether additional virtual CPUs bring computing power depends on what the host underneath provides. Our lab shows that the gain can become small beyond a certain point.
• Tomorrow's workload. A query that runs serially today can run in parallel after a change, and vice versa. Cores are a decision for years; queries change with every release.

Frequently asked questions

Method and limits

All measurements come from our lab series of Oct 23, 2026: SQL Server 2022 CU27 Developer in a Linux container, virtual CPUs under Hyper-V on an Intel Xeon at 2.4 GHz, all assigned CPUs in one NUMA node, 6 GiB of maximum SQL Server memory. Synthetic data with 10 million rows in memory, identical statistics. Each variant ran in five measurement windows after a warm-up phase; the values given are medians. Variants whose windows differed from each other by more than ten percent were repeated with longer windows. The load generator ran on separate CPUs and was never the bottleneck.

This is a lab, not a customer environment. We did not change the clock speed; statements about faster cores are conclusions from the serial measurement. The curve beyond 8 cores applies to this host. Two variants with a few permanently active sessions varied widely because queries were distributed unevenly across the schedulers; we used them only as an indication. For the 8-core variant in Experiment 3, the medians of two measurement series were close together, but the spread within one series was above ten percent.

Further reading