English version
SQL Server is easier to reason about when you separate the request path from the storage path. A query does not go straight from an application to a table. It moves through the protocol layer, the relational engine, the optimizer, and the storage engine before rows are returned to the client.
That mental model is useful for performance work because execution plans, logical reads, buffer cache behavior, locks, and transaction logs all belong to different parts of the system.
At a high level, a SQL Server request follows this flow:
- The client connects to SQL Server.
- The protocol layer receives the request.
- The relational engine parses, validates, optimizes, and executes the query.
- The storage engine reads or writes the required data pages.
- The result is sent back to the client.
The protocol layer is the communication boundary. Shared memory can be used when the client and SQL Server run on the same machine. TCP/IP is the common choice when the application server and database server are separate. Named pipes can be used for process communication inside a LAN-style environment.
SQL Server also uses TDS, or Tabular Data Stream, as the protocol for sending requests and result sets between the client and the server. When an application sends a query and receives rows, that exchange is represented internally as TDS packet flow.
The relational engine, also called the query processor, decides how a query should run. It parses SQL text, checks validity, builds candidate execution plans, compares estimated cost, and runs the selected plan. Operators such as scans, seeks, joins, and estimated subtree cost are tied to decisions made in this layer.
The query optimizer does not know the future. It estimates cardinality and cost from statistics and metadata. If estimated rows and actual rows are far apart, the selected plan can be inefficient even when the query is logically correct.
The storage engine handles the physical work. It reads and writes data pages through components such as access methods, the buffer manager, the transaction manager, and the lock manager. When a query needs data, the storage engine checks memory first and then disk if the page is not already cached.
The buffer manager caches data pages, not final query output. A repeated query may run faster because the pages it needs are already in memory, but SQL Server still may need to evaluate predicates, join rows, sort data, or enforce transaction semantics again.
Transactions, locks, and logs are part of the same operational path. Even a simple UPDATE has to find the page, acquire the needed lock, write log records, modify the page, and keep the operation commit- or rollback-safe.
The practical lesson is simple: SQL Server architecture is the base layer for tuning. If you know which engine component owns which responsibility, execution plans and I/O metrics become much easier to interpret.
Korean notes
SQL Server를 단순히 query를 실행하는 DB로만 보면 성능 문제를 이해하기 어렵다. Query가 들어오면 protocol layer를 지나 relational engine에서 계획을 만들고, storage engine이 실제 data page를 읽는다.
예전 Velog에 정리했던 MSSQL Server Architecture 노트를 다시 블로그용으로 다듬었다.
SQL Server architecture를 보는 큰 흐름
SQL Server는 크게 다음 흐름으로 볼 수 있다.
- Client가 SQL Server에 연결한다.
- Protocol layer를 통해 request가 전달된다.
- Relational engine이 query를 parse, optimize, execute한다.
- Storage engine이 필요한 page를 읽고 쓴다.
- 결과가 다시 client로 돌아간다.
이 흐름을 알면 execution plan, logical reads, buffer cache 같은 개념이 어디에 붙는지 이해하기 쉬워진다.
Protocol layer
Protocol layer는 client와 SQL Server가 통신하는 부분이다. SQL Server는 여러 protocol을 제공한다.
Shared memory
Client와 SQL Server가 같은 machine 안에서 실행될 때 사용할 수 있다. 같은 집 안에서 말로 대화하는 것처럼, network를 거치지 않고 local communication을 한다고 이해하면 된다.
TCP/IP
Client와 SQL Server가 서로 다른 machine에 있을 때 가장 일반적으로 사용하는 protocol이다. Application server와 DB server가 분리되어 있다면 보통 TCP/IP 기반으로 통신한다.
Named pipes
Named pipes는 LAN 환경에서 사용할 수 있는 protocol이다. 같은 네트워크 안에서 process 사이 통신을 제공한다.
TDS
TDS는 Tabular Data Stream의 약자다. SQL Server와 client 사이에서 request와 result set을 주고받기 위한 protocol이다.
Application이 query를 보내고 결과를 받는 과정은 내부적으로 TDS packet 흐름으로 볼 수 있다.
Relational engine
Relational engine은 Query Processor라고도 부른다. SQL Server가 user query를 받아 어떤 방식으로 실행할지 결정하는 핵심 영역이다.
Relational engine은 다음 작업을 담당한다.
- SQL text를 parse한다.
- query가 유효한지 확인한다.
- 여러 execution plan 후보를 만든다.
- cost를 비교해서 plan을 선택한다.
- 선택한 plan을 실행한다.
실행 계획에서 Estimated Subtree Cost, join type, scan, seek 같은 정보는 relational engine의 optimizer 판단과 연결된다.
Query optimizer
Optimizer는 가능한 여러 실행 방법 중에서 비용이 낮다고 판단한 plan을 선택한다.
중요한 점은 optimizer가 실제 미래를 아는 것이 아니라 statistics와 metadata를 보고 추정한다는 것이다. 그래서 estimated row와 actual row가 크게 차이 나면 plan이 나빠질 수 있다.
Storage engine
Storage engine은 실제 data page를 읽고 쓰는 영역이다. Relational engine이 데이터를 요청하면 storage engine이 buffer pool이나 disk에서 page를 찾는다.
Storage engine 관점에서 중요한 구성 요소는 다음과 같다.
- Access methods
- Buffer manager
- Transaction manager
- Lock manager
Buffer manager
Buffer manager는 data page를 memory에 올려두고 관리한다. SQL Server가 data page를 cache한다고 할 때 이 영역과 연결된다.
Query output을 그대로 cache하는 것이 아니라 data page를 cache한다는 점이 중요하다. 같은 query를 다시 실행했을 때 빨라지는 이유는 필요한 page가 buffer cache에 남아 있기 때문일 수 있다.
Transaction, lock, log
Storage engine은 transaction의 일관성도 관리한다. Data 변경이 발생하면 lock, log, transaction state가 함께 움직인다.
UPDATE 하나를 실행하더라도 단순히 row만 바뀌는 것이 아니라 다음 일이 같이 일어난다.
- 필요한 page를 찾는다.
- lock을 잡는다.
- log를 기록한다.
- page를 수정한다.
- commit 또는 rollback 가능 상태를 유지한다.
정리
SQL Server architecture는 성능 튜닝의 바탕이다.
- Protocol layer는 client와 SQL Server의 통신을 담당한다.
- TDS는 SQL Server와 client가 tabular data를 주고받는 protocol이다.
- Relational engine은 query를 parse, optimize, execute한다.
- Optimizer는 statistics와 cost를 기반으로 plan을 고른다.
- Storage engine은 실제 page를 읽고 쓰며 transaction과 lock을 관리한다.
- Buffer manager는 data page cache를 담당한다.