SQL Server

Đặc thù SQL Server và Performance

Đặc thù SQL Server 2025 — JSON, Vector Index (DiskANN), Optimized Locking, RegEx, temporal table. Index, execution plan, tuning, query optimization, AI integration, benchmarks.

1. Index — kiến thức cốt lõi

Hai loại chính

Clustered
1 cái / bảng
Sắp xếp vật lý dữ liệu theo key. Bảng có clustered = B-tree với leaf chứa luôn data. Mặc định PRIMARY KEY = clustered.
Non-clustered
Nhiều cái / bảng
Cấu trúc B-tree riêng, leaf trỏ về row gốc qua row locator (clustered key hoặc RID nếu heap).
-- Clustered (chỉ 1 cái — thường là PK)
CREATE CLUSTERED INDEX IX_Orders_Date ON Orders(OrderDate);

-- Non-clustered
CREATE INDEX IX_Orders_CustomerId ON Orders(CustomerId);

-- Composite — thứ tự cột RẤT QUAN TRỌNG (left-most prefix)
CREATE INDEX IX_Orders_Cust_Date ON Orders(CustomerId, OrderDate);

-- Covering — INCLUDE thêm cột để query không cần seek về bảng
CREATE INDEX IX_Orders_Cover ON Orders(CustomerId)
INCLUDE (OrderDate, Total, Status);

-- Filtered — chỉ index 1 phần dữ liệu
CREATE INDEX IX_Orders_Active ON Orders(CustomerId)
WHERE Status <> 'Cancelled';

-- Unique
CREATE UNIQUE INDEX IX_Users_Email ON Users(Email);

-- Drop
DROP INDEX IX_Orders_CustomerId ON Orders;

Khi nào tạo / khi nào tránh

Nên index:
  • Cột thường ở WHERE, JOIN, ORDER BY, GROUP BY.
  • Cột có selectivity cao (nhiều giá trị distinct).
  • Foreign key columns (SQL Server không tự tạo!).
KHÔNG nên index:
  • Bảng nhỏ (vài nghìn row) — scan đầy bảng có khi nhanh hơn.
  • Cột thay đổi rất thường xuyên (UPDATE phải cập nhật cả index).
  • Selectivity thấp (Gender 2 giá trị, Status 3 giá trị).
  • Bảng heavy INSERT (mỗi insert tăng index maintenance).
Câu PV cốt lõi:"Index hoạt động ra sao?"

"Index là cấu trúc B-tree với key sorted. Khi WHERE/JOIN trên cột có index, engine seek qua B-tree để tìm row, độ phức tạp O(log n) thay vì O(n) full scan. Trade-off: index tốn space và làm chậm INSERT/UPDATE/DELETE vì phải maintain B-tree."

Composite index — quy tắc left-most prefix

CREATE INDEX IX_Orders_ABC ON Orders(A, B, C);

-- Index dùng được:
WHERE A = ?
WHERE A = ? AND B = ?
WHERE A = ? AND B = ? AND C = ?

-- Index KHÔNG dùng được (hoặc dùng không hiệu quả):
WHERE B = ?               -- bỏ qua A
WHERE A = ? AND C = ?     -- skip B
WHERE C = ?               -- chỉ có cột cuối

Sargable vs Non-sargable

Non-sargable = query mà engine không dùng được index dù có. Vì áp hàm/biểu thức lên cột:
-- ❌ Function lên cột → full scan
WHERE YEAR(OrderDate) = 2026
WHERE UPPER(Email) = 'A@B.COM'
WHERE Total + Tax > 100

-- ✅ Sargable — engine dùng được index
WHERE OrderDate >= '2026-01-01' AND OrderDate < '2027-01-01'
WHERE Email = 'a@b.com'        -- nếu collation CI thì không cần UPPER
WHERE Total > 100 - Tax

Bẫy phỏng vấn rất hay: "Tại sao WHERE YEAR(OrderDate) = 2026 chậm dù có index?" — câu trả lời là non-sargable.

2. Execution Plan — đọc cách nào?

Trong SSMS, bật Actual Execution Plan (Ctrl+M) trước khi chạy query. Hoặc dùng SET STATISTICS IO ON; SET STATISTICS TIME ON;.

Các operator quan trọng

OperatorÝ nghĩaKhi gặp thì sao
Table ScanĐọc toàn bộ bảngThiếu index? Hoặc bảng nhỏ.
Clustered Index ScanĐọc toàn bộ clusteredTương tự — full scan
Clustered Index SeekTra cứu qua index ✅Tốt
Index Seek (non-clustered)Tra non-clustered ✅Tốt
Key LookupSau seek, lookup về clustered để lấy thêm cộtDấu hiệu cần covering index
Hash MatchJOIN bằng hashOK cho dataset lớn, nóng RAM.
Nested LoopsJOIN row-by-rowTốt cho outer nhỏ + inner indexed
Merge JoinJOIN 2 nguồn đã sortTốt khi cả 2 đã sorted.
SortSắp xếpĐắt với data lớn — xem có thể tránh?
Câu PV:"Key Lookup là gì? Khi nào xuất hiện?"

"Khi non-clustered index không bao phủ đủ cột query cần, engine sau seek phải nhảy về clustered để lấy cột thêm. Nhiều Key Lookup = chậm. Fix bằng covering index (thêm INCLUDE)."

Statistics & cost

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

SELECT * FROM Orders WHERE CustomerId = 1;

-- Output:
-- Table 'Orders'. Scan count 1, logical reads 8, physical reads 2, ...
-- CPU time = 0 ms,  elapsed time = 12 ms.

logical reads = số page (8KB) phải đọc — chỉ số quan trọng nhất để so sánh trước/sau optimize.

3. Query optimization checklist

  1. ✅ Có index trên cột WHERE/JOIN/ORDER BY?
  2. ✅ Tránh SELECT * — chỉ chọn cột cần (phá covering, tốn băng thông).
  3. ✅ WHERE sargable (không function lên cột)?
  4. ✅ JOIN trên cột cùng kiểu dữ liệu (tránh implicit conversion).
  5. ✅ Dùng EXISTS thay IN với subquery lớn.
  6. ✅ Dùng UNION ALL thay UNION nếu không cần dedupe.
  7. ✅ Pagination dùng OFFSET/FETCH thay vì lấy tất rồi cắt.
  8. ✅ Update statistics định kỳ.
  9. ✅ Defrag/rebuild index khi fragmentation > 30%.
  10. ✅ Dùng AsNoTracking() từ EF Core khi chỉ đọc.

Defrag index

-- Xem fragmentation
SELECT * FROM sys.dm_db_index_physical_stats(
    DB_ID('LearnSqlServer'), NULL, NULL, NULL, 'DETAILED');

-- Reorganize (5–30%)
ALTER INDEX IX_Orders_CustomerId ON Orders REORGANIZE;

-- Rebuild (> 30% — lock dài)
ALTER INDEX IX_Orders_CustomerId ON Orders REBUILD;

-- Update statistics
UPDATE STATISTICS Orders WITH FULLSCAN;

4. Parameter sniffing — bug kinh điển

Parameter sniffing = lần đầu chạy stored proc, engine cache plan dựa trên parameter đó. Lần sau với parameter khác, plan có thể bị tệ.Triệu chứng: proc lúc nhanh lúc chậm bất thường.

Cách fix:

-- 1. OPTIMIZE FOR
SELECT * FROM Orders
WHERE CustomerId = @CustomerId
OPTION (OPTIMIZE FOR (@CustomerId UNKNOWN));

-- 2. RECOMPILE — sinh plan mới mỗi lần gọi
SELECT * FROM Orders
WHERE CustomerId = @CustomerId
OPTION (RECOMPILE);

-- 3. SQL Server 2025: OPPO (Optional Parameter Plan Optimization) tự xử lý
ALTER DATABASE SCOPED CONFIGURATION
    SET OPTIONAL_PARAMETER_PLAN_OPTIMIZATION = ON;   -- 2025 only

Câu PV nâng cao (Junior+): giải thích được parameter sniffing là điểm cộng lớn.

5. JSON trong SQL Server (2025 nâng cấp)

Kiểu JSON first-class (2025 mới)

CREATE TABLE Events (
    Id INT IDENTITY PRIMARY KEY,
    Payload JSON                       -- 2025 mới
);

INSERT INTO Events (Payload)
VALUES (N'{ "type": "click", "user": "alice", "tags": ["promo", "email"] }');

Query JSON

-- Path
SELECT
    JSON_VALUE(Payload, '$.type') AS EventType,
    JSON_VALUE(Payload, '$.user') AS Username,
    JSON_QUERY(Payload, '$.tags') AS Tags
FROM Events;

-- OPENJSON — biến JSON thành table
SELECT *
FROM OPENJSON(
    N'[{"id":1,"name":"A"},{"id":2,"name":"B"}]'
)
WITH (
    id INT '$.id',
    name NVARCHAR(50) '$.name'
);

-- Modify
UPDATE Events
SET Payload = JSON_MODIFY(Payload, '$.processed', 1)
WHERE Id = 1;

6. Native RegEx (2025 mới)

-- Trước 2025 phải dùng CLR. Giờ built-in.
SELECT Email FROM Users
WHERE REGEXP_LIKE(Email, '^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$');

SELECT REGEXP_REPLACE('Hello World 2026', '\d+', 'XXXX');
-- 'Hello World XXXX'

SELECT REGEXP_SUBSTR(Description, '[A-Z]{2,}') FROM Articles;

7. Temporal Table — versioning tự động

CREATE TABLE Products (
    Id INT IDENTITY PRIMARY KEY,
    Name NVARCHAR(200) NOT NULL,
    Price DECIMAL(18, 2),
    ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START NOT NULL,
    ValidTo   DATETIME2 GENERATED ALWAYS AS ROW END   NOT NULL,
    PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.ProductsHistory));

-- Mỗi UPDATE tự động lưu version cũ vào ProductsHistory

-- Query data ngày 2026-01-01
SELECT * FROM Products
    FOR SYSTEM_TIME AS OF '2026-01-01';

-- Tất cả version từng tồn tại
SELECT * FROM Products
    FOR SYSTEM_TIME ALL
WHERE Id = 1;
⭐ Temporal Table cực mạnh cho audit log, undo, compliance. Đáng học cho fresher muốn nổi bật.

8. Columnstore Index — cho analytics

-- Cho bảng analytics rất lớn, query aggregate
CREATE CLUSTERED COLUMNSTORE INDEX CCI_Sales ON Sales;

-- Hoặc non-clustered columnstore (OLTP có lẫn analytics)
CREATE NONCLUSTERED COLUMNSTORE INDEX NCCI_Sales ON Sales(Year, Month, Total);

Compress ~10x, query aggregate nhanh 10–100x so với rowstore. Trade-off: chậm cho single-row lookup.

9. Partitioning

-- Partition function chia theo year
CREATE PARTITION FUNCTION pf_OrderYear (INT)
AS RANGE LEFT FOR VALUES (2023, 2024, 2025);

CREATE PARTITION SCHEME ps_OrderYear
AS PARTITION pf_OrderYear ALL TO ([PRIMARY]);

CREATE TABLE Orders (
    Id INT, Year INT, ...
) ON ps_OrderYear(Year);

Dùng khi bảng cực lớn (> 100M row) cần archive theo thời gian, hoặc query luôn filter theo partition key.

10. SQL Server đặc thù — nhớ để khỏi confused khi sang Postgres/MySQL

SQL ServerPostgres / MySQL
Identifier quote[Name]"Name"
Auto-incrementIDENTITY(1,1)SERIAL (PG), AUTO_INCREMENT (MySQL)
StringN'text' (Unicode), 'ascii''text' (UTF-8 default)
LimitTOP N, OFFSET ... FETCHLIMIT N OFFSET M
NowSYSUTCDATETIME(), GETDATE()NOW(), CURRENT_TIMESTAMP
Concat+ hoặc CONCAT()`
BooleanBIT (0/1)BOOLEAN
Default schemadbo.public. (PG), không có (MySQL)
Batch sepGO (SSMS only); thường
IFIF ... BEGIN ... ENDCASE WHEN
Schema in DBDB có nhiều schemaDB ≈ schema

11. Vector Index & DiskANN — tìm kiếm vector (SQL Server 2025)

SQL Server 2025 giới thiệu Vector Index dùng thuật toán DiskANN (Disk-based Approximate Nearest Neighbor) của Microsoft — cho phép tìm kiếm similarity search trên dữ liệu vector ngay trong SQL Server, không cần vector database riêng.

DiskANN là gì?

DiskANN là thuật toán ANN do Microsoft Research phát triển, tối ưu cho SSD-based storage. Khác với HNSW (Hierarchical Navigable Small World) phải giữ toàn bộ index trong RAM, DiskANN lưu graph trên disk và chỉ load phần cần thiết vào memory khi query.

Tiêu chíHNSW (in-memory)DiskANN (SQL Server 2025)
Bộ nhớGiữ toàn bộ graph trong RAMÍt hơn ~90% RAM so với HNSW
Lưu trữKhông tối ưu cho diskTối ưu cho SSD NVMe
Quy môGiới hạn bởi RAMTỷ vector (billion-scale)
Độ trễMicrosecondsMilliseconds (vẫn cực nhanh)
Chi phí hạ tầngRAM đắtSSD rẻ hơn nhiều

Cú pháp tạo Vector Index

-- Bước 1: Tạo bảng với cột vector
-- Dùng kiểu VECTOR(n) — n là số dimensions (vd: OpenAI ada-002 = 1536)
CREATE TABLE ProductEmbeddings (
    ProductId INT PRIMARY KEY,
    ProductName NVARCHAR(200),
    Embedding VECTOR(1536)
);

-- Bước 2: Tạo vector index
CREATE VECTOR INDEX IX_Product_Vector
ON ProductEmbeddings(Embedding)
WITH (DISTANCE_METRIC = 'cosine');   -- cosine | euclidean | dot

-- Bước 3: Query similarity search
DECLARE @QueryEmbedding VECTOR(1536) = 0x...;

SELECT TOP 5
    ProductName,
    VECTOR_DISTANCE(Embedding, @QueryEmbedding, 'cosine') AS Similarity
FROM ProductEmbeddings
ORDER BY Similarity
OFFSET 0 ROWS FETCH NEXT 5 ROWS ONLY;

Hạn chế hiện tại và lưu ý

Hạn chế quan trọng: Sau khi tạo vector index, bảng trở thành read-only. Microsoft đang có bản fix trong Cumulative Update sắp tới. Khi phỏng vấn cần nêu được điểm này — thể hiện bạn đã thực sự dùng thử và cập nhật.

Use-case thực tế

Câu PV 2026:"Làm semantic search trong SQL Server thì dùng gì?"

"SQL Server 2025 có Vector Index với DiskANN. Lưu embedding vào cột VECTOR(n), tạo index với distance metric phù hợp (cosine/euclidean/dot), query bằng VECTOR_DISTANCE. DiskANN tiết kiệm ~90% RAM so với in-memory HNSW, chạy được billion-scale trên SSD với millisecond latency. Hạn chế hiện tại là bảng read-only sau khi tạo index — cần lưu ý trong thiết kế."

Các use-case chính:

  • Semantic Search: Tìm sản phẩm/bài viết theo ý nghĩa, không phải keyword.
  • Image Similarity: Tìm ảnh tương tự dựa trên embedding từ model vision.
  • Recommendation: Gợi ý sản phẩm dựa trên vector similarity.
  • RAG (Retrieval-Augmented Generation): Hybrid search kết hợp full-text + vector trong cùng một query.

12. JSON Index — index chuyên biệt cho cột JSON (SQL Server 2025 Preview)

SQL Server 2025 giới thiệu JSON Index — loại index mới được thiết kế riêng cho cột JSON, cho phép đánh index trên các path cụ thể bên trong JSON document. Hiện đang trong giai đoạn Preview.

So sánh với cách cũ

Cách làmTrước 2025SQL Server 2025
Index JSON pathComputed column + regular indexJSON Index trực tiếp
MaintenancePhải maintain computed columnTự động — index hiểu JSON structure
PerformancePhải parse JSON lúc queryIndex đã chứa giá trị tại path
FlexibilityMỗi path = 1 computed column1 index cover nhiều path
-- Cách cũ: computed column + index thường (vẫn hoạt động)
ALTER TABLE Events ADD EventType AS JSON_VALUE(Payload, '$.type');
CREATE INDEX IX_EventType ON Events(EventType);

-- SQL Server 2025: JSON Index (Preview)
CREATE JSON INDEX IX_Events_Payload
ON Events(Payload)
WITH (
    JSON_PATH '$.type',
    JSON_PATH '$.user',
    JSON_PATH '$.timestamp'
);
Câu PV:"JSON Index khác gì computed column + regular index?"

"JSON Index hiểu cấu trúc JSON natively — engine không cần parse lại document mỗi lần query. Một index có thể cover nhiều path, không cần tạo riêng computed column cho từng path. Nhược điểm duy nhất: đang trong giai đoạn Preview, chưa khuyến khích cho production."

13. Optimized Locking — tính năng performance quan trọng nhất SQL Server 2025

Đây có lẽ là tính năng performance quan trọng nhất cho OLTP workload trong SQL Server 2025, với throughput cải thiện 15-25%.

Vấn đề truyền thống

Trong SQL Server trước 2025:

  1. Mỗi row lock chiếm một lượng memory nhất định trong Lock Manager.
  2. Khi memory pressure cao (nhiều lock cùng lúc), engine escalate row locks thanh page lock, th?m chi table lock.
  3. Lock escalation = gi?m concurrency, tang blocking, gi?m throughput.
Row locks (chi tiết, nhiều concurrency)
       |
       | Lock escalation khi memory pressure
       v
Page locks (thô hơn, ít concurrency hơn)
       |
       v
Table lock (chặn tất cả transaction khác)

SQL Server 2025 thay đổi gì

Khía cạnhTrước 2025SQL Server 2025
Lock escalationBật mặc địnhTắt mặc định
Memory / lock~64 bytes~32 bytes (giảm ~50%)
Row lock → table lockXảy ra thường xuyênHầu như không xảy ra
ConcurrencyBị giới hạnCao hơn đáng kể
Blocking chainDài, khó debugNgắn hơn nhiều
-- Kiểm tra lock escalation setting trên bảng (2025: thường đã OFF)
SELECT name, is_lock_escalation_disabled
FROM sys.tables
WHERE name = 'Orders';

-- Monitor locks hiện tại
SELECT
    request_session_id AS SPID,
    resource_type,
    resource_description,
    request_mode,
    request_status
FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID('LearnSqlServer');

LAQ — Lock After Qualification

LAQ (Lock After Qualification) là cải tiến lớn nhất trong Optimized Locking. Engine áp WHERE filter trước, lock sau — thay vì lock tất cả row trong range rồi mới filter.Trước 2025: Scan range -> Lock tất cả row trong range -> Apply WHERE -> Trả kết quả 2025 với LAQ: Scan range -> Apply WHERE -> Chỉ lock row qualify -> Trả kết quảKết quả: giảm lock contentions đáng kể, đặc biệt với query có WHERE chọn lọc cao trên bảng lớn.
-- Query này trong 2025 với LAQ:
-- Chỉ lock những row có Status = 'Pending' AND Amount > 1000
-- Thay vì lock toàn bộ range scan như trước đây
UPDATE Orders
SET Processed = 1
WHERE Status = 'Pending' AND Amount > 1000;
Câu PV Senior:"Optimized Locking trong SQL Server 2025 hoạt động thế nào?"

"Ba thay đổi chính: (1) Lock escalation tắt mặc định, giảm table-level blocking. (2) Memory mỗi lock giảm ~50%, cho phép nhiều row lock đồng thời hơn. (3) LAQ — lock chỉ áp dụng sau WHERE filter, giảm lock contentions. Tổng thể: OLTP throughput tăng 15-25%, đặc biệt với workload nhiều concurrent transactions."

14. TempDB cải tiến (SQL Server 2025)

Resource Governance cho TempDB

SQL Server 2025 cho phép giới hạn dung lượng TempDB theo từng workload group — ngăn một query "đói" TempDB làm ảnh hưởng toàn bộ instance. Đây là tính năng quan trọng cho môi trường multi-tenant hoặc có nhiều workload khác nhau.

-- Giới hạn TempDB space cho workload group "ReportUsers"
ALTER WORKLOAD GROUP ReportUsers
WITH (
    REQUEST_MAX_MEMORY_GRANT_PERCENT = 25,
    REQUEST_MAX_CPU_TIME_SEC = 300,
    GROUP_MAX_TEMPDB_SPACE_MB = 20480   -- 2025 mới: giới hạn 20GB
);

ADR cho TempDB (Accelerated Database Recovery)

Tiêu chíKhông ADRCó ADR (2025)
Crash recoveryVài giờ với TempDB lớnVài phút
Rollback transaction lớnTốn thời gian bằng thời gian chạyGần như tức thì
TempDB contentionCaoGiảm đáng kể
AvailabilityChờ recovery xong mới onlineOnline nhanh hơn
-- Bật ADR cho database (ảnh hưởng cả TempDB behavior)
ALTER DATABASE LearnSqlServer
SET ACCELERATED_DATABASE_RECOVERY = ON;

tmpfs trên Linux containers

⭐ Trên Linux containers, SQL Server 2025 hỗ trợ đặt TempDB trên tmpfs (RAM disk). Kết hợp với ADR, TempDB không còn là bottleneck cho containerized workloads. Đây là điểm cộng khi phỏng vấn vị trí DevOps/Cloud Engineer.
# Docker run với tmpfs cho TempDB
docker run -d \
  --name sql2025 \
  -e 'ACCEPT_EULA=Y' \
  -e 'MSSQL_SA_PASSWORD=YourStr0ngP@ss' \
  --tmpfs /var/opt/mssql/tempdb:rw,noexec,nosuid,size=4g \
  -p 1433:1433 \
  mcr.microsoft.com/mssql/server:2025-latest

15. Backup & Restore cải tiến (SQL Server 2025)

ZSTD Compression — nén nhanh hơn, nhỏ hơn

SQL Server 2025 thêm thuật toán nén ZSTD (Zstandard) bên cạnh MS_XPRESS truyền thống.

Thuật toánTỉ lệ nénTốc độ nénCPU usage
MS_XPRESSTrung bìnhNhanhThấp
ZSTD (2025)Tốt hơn 20-30%Nhanh hơnTrung bình
-- Backup với ZSTD compression (2025)
BACKUP DATABASE LearnSqlServer
TO DISK = N'D:\Backups\LearnSqlServer_2025.bak'
WITH COMPRESSION, COMPRESSION_ALGORITHM = ZSTD;

Backup trên Secondary AG Replica

2025 mới: Có thể chạy FULL và DIFFERENTIAL backup trên secondary replica của Availability Group — offload hoàn toàn backup workload khỏi primary. Trước 2025 chỉ hỗ trợ COPY_ONLY backup trên secondary.
-- Chạy full backup trên secondary replica (2025)
-- Không còn bị giới hạn COPY_ONLY
BACKUP DATABASE LearnSqlServer
TO DISK = N'\\BackupServer\Share\LearnSqlServer_Full.bak'
WITH COMPRESSION, COMPRESSION_ALGORITHM = ZSTD;

ABORT_QUERY_EXECUTION

Khi kill một session đang chạy query nặng, SQL Server 2025 có option mới để dừng query execution ngay lập tức thay vì phải chờ rollback toàn bộ transaction.

-- Kill với abort query execution (2025)
KILL 54 WITH ABORT_QUERY_EXECUTION;

16. SQL Server on Linux 2025

Hỗ trợ OS mở rộng

OSSQL Server 2022SQL Server 2025
Red Hat 8.xCoCo
Red Hat 9.xKhongCo
Ubuntu 20.04CoCo
Ubuntu 22.04CoCo
Ubuntu 24.04KhongCo
ContainerCoCo + tmpfs tempdb

Container optimization

# SQL Server 2025 container: cgroup v2 + tmpfs tempdb
docker run -d \
  --name sql2025 \
  --cgroup-parent=/sqlserver.slice \     # cgroup v2 support
  --tmpfs /var/opt/mssql/tempdb:size=8g \
  -e 'ACCEPT_EULA=Y' \
  -e 'MSSQL_SA_PASSWORD=YourStr0ngP@ss' \
  -p 1433:1433 \
  mcr.microsoft.com/mssql/server:2025-latest

PolyBase trên Linux

SQL Server 2025 trên Linux hỗ trợ đầy đủ PolyBase — truy vấn dữ liệu từ nhiều nguồn (Hadoop, Azure Blob, S3-compatible, ODBC) bằng T-SQL.

-- PolyBase: query file CSV/Parquet trên S3 từ SQL Server Linux
CREATE EXTERNAL DATA SOURCE MyS3
WITH (
    LOCATION = 's3://my-bucket/',
    CREDENTIAL = S3Credential
);

SELECT * FROM OPENROWSET(
    BULK 'sales/2025/*.parquet',
    DATA_SOURCE = 'MyS3',
    FORMAT = 'PARQUET'
) AS Sales;

Active Directory Integration

SQL Server 2025 trên Linux có cải thiện đáng kể về AD integration — hỗ trợ Kerberos constrained delegation, group-managed service accounts (gMSA), và automatic keytab rotation.

Câu PV DevOps:"SQL Server 2025 trên Linux khác gì 2022?" — Điểm khác chính: cgroup v2, tmpfs tempdb, PolyBase đầy đủ, AD integration cải thiện (gMSA, auto keytab), hỗ trợ RHEL 9 & Ubuntu 24.04.

17. Azure SQL & Cloud Integration (2025)

SQL MCP Server Endpoint (Public Preview)

Đây là tính năng quan trọng cho AI Agent ecosystem. SQL MCP Server cho phép AI agents (Claude, ChatGPT, Copilot...) kết nối trực tiếp vào SQL database qua giao thức Model Context Protocol (MCP).

AI Agent (Claude / GPT / Copilot)
       |
       | MCP Protocol (standardized)
       v
SQL MCP Server
       |
       v
Azure SQL DB / SQL Server 2025
Xu hướng 2026: SQL MCP Server là cầu nối giữa AI agent và database. Thay vì viết REST API trung gian, agent có thể trực tiếp query, explore schema, và học từ data qua giao thức chuẩn. Đây là điểm nhấn khi phỏng vấn vị trí Architect hoặc Data Engineer.

Azure SQL DB Hyperscale mở rộng

Cấu hìnhTrước 20252025
vCores tối đa128 vCores160 và 192 vCores
Storage tối đa100 TB100 TB
Read replicas3030
Vector searchKhongCo (với quantization)

Cost optimization

Savings Plan 1 năm           -> Tiết kiệm đến 35%
Azure Hybrid Benefit         -> Dùng on-prem license, giảm thêm
Reserved Capacity 3 năm       -> Tiết kiệm nhất
Azure Arc enabled SQL Server -> Tiết kiệm đến 20% + Entra ID auth

Microsoft Fabric Database Hub

Database Hub trong Microsoft Fabric (early access 2025) cho phép quản lý và query nhiều SQL database từ một giao diện duy nhất, tích hợp với Fabric's OneLake và Copilot.

Fabric Database Hub
├── Azure SQL DB
├── SQL Server on-prem (qua Azure Arc)
├── Fabric SQL Database (SaaS)
└── OneLake shortcut -> query trực tiếp từ Lakehouse

18. AI Integration Architecture (SQL Server 2025)

SQL Server 2025 tích hợp sâu với AI workflow thông qua RAG patternexternal model management.

Kiến trúc RAG với SQL Server

+------------------------------------------------------+
|                    RAG Architecture                   |
|                                                       |
|  +----------+    +-----------+    +----------------+  |
|  |  User    |--->| SQL Server|--->|  AI Service    |  |
|  |  Query   |    |           |    |  (Azure OpenAI)|  |
|  +----------+    | - Data    |    +-------+--------+  |
|                  | - Vector  |<-----------+           |
|                  |   Index   |   embedding response    |
|                  +-----------+                        |
|                                                       |
|  1. User query -> SQL Server                          |
|  2. sp_invoke_external_rest_endpoint -> AI service    |
|  3. AI returns embedding / completion                 |
|  4. SQL Server dùng vector index tìm relevant data    |
|  5. Trả kết quả kèm context cho user                  |
+------------------------------------------------------+

sp_invoke_external_rest_endpoint

-- Gọi Azure OpenAI từ T-SQL để tạo embedding
DECLARE @response NVARCHAR(MAX);

EXEC sp_invoke_external_rest_endpoint
    @url = 'https://my-openai.openai.azure.com/openai/deployments/text-embedding-3-small/embeddings?api-version=2024-02-01',
    @method = 'POST',
    @headers = '{"Content-Type":"application/json", "api-key":"xxx"}',
    @payload = N'{"input": "Sản phẩm điện thoại Samsung Galaxy"}',
    @response = @response OUTPUT;

-- Parse embedding từ response và dùng để vector search
-- SELECT ... ORDER BY VECTOR_DISTANCE(Embedding, @ParsedEmbedding, 'cosine')

CREATE EXTERNAL MODEL

-- Đăng ký AI model như database object
CREATE EXTERNAL MODEL InvoiceClassifier
WITH (
    MODEL_PROVIDER = 'AZURE_OPENAI',
    MODEL_NAME = 'gpt-4o',
    ENDPOINT = 'https://my-openai.openai.azure.com',
    API_VERSION = '2024-10-21',
    CREDENTIAL = MyAzureCredential
);

-- Gọi model như function trong T-SQL
SELECT
    InvoiceId,
    PREDICT(InvoiceClassifier, InvoiceText) AS Category
FROM Invoices;

Retry logic tích hợp

-- SQL Server 2025 tự retry khi gọi external API
EXEC sp_invoke_external_rest_endpoint
    @url = 'https://api.example.com/classify',
    @method = 'POST',
    @payload = N'{"text": "..."}',
    @retry_count = 3,
    @retry_interval_ms = 1000,
    @response = @response OUTPUT;

A/B Testing với nhiều model version

-- Đăng ký nhiều version của cùng model
CREATE EXTERNAL MODEL SentimentV1
WITH (MODEL_PROVIDER = 'AZURE_OPENAI', MODEL_NAME = 'gpt-4o', ENDPOINT = '...', CREDENTIAL = MyCredential);

CREATE EXTERNAL MODEL SentimentV2
WITH (MODEL_PROVIDER = 'AZURE_OPENAI', MODEL_NAME = 'gpt-4.1', ENDPOINT = '...', CREDENTIAL = MyCredential);

-- A/B test: 50% traffic mỗi model
DECLARE @model SYSNAME = IIF(ABS(CHECKSUM(NEWID())) % 2 = 0, 'SentimentV1', 'SentimentV2');
SELECT PREDICT(@model, ReviewText) AS Sentiment FROM Reviews;
Câu PV Architect/Lead:"Làm sao tích hợp AI vào SQL Server app?"

"SQL Server 2025 hỗ trợ RAG pattern natively: lưu embeddings trong cột VECTOR, tạo vector index với DiskANN, gọi AI service qua sp_invoke_external_rest_endpoint với built-in retry, và quản lý model qua CREATE EXTERNAL MODEL. Toàn bộ pipeline chạy trong T-SQL — không cần middleware, không cần vector database riêng."

19. Monitoring & Observability (SQL Server 2025)

DMV cập nhật cho tính năng mới

-- Vector query metrics trong Query Store (2025 mới)
SELECT
    qsq.query_id,
    qsqt.query_sql_text,
    qsq.count_vector_searches,
    qsq.avg_vector_search_duration_ms,
    qsq.avg_vector_distance_compute_ms
FROM sys.query_store_query AS qsq
JOIN sys.query_store_query_text AS qsqt
    ON qsq.query_text_id = qsqt.query_text_id
WHERE qsq.count_vector_searches > 0
ORDER BY qsq.avg_vector_search_duration_ms DESC;

-- Lock escalation events (theo dõi Optimized Locking)
SELECT
    counter_name,
    cntr_value
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Locks%'
  AND counter_name IN (
      'Lock Escalations/sec',
      'Average Wait Time (ms)',
      'Number of Deadlocks/sec'
  );

-- TempDB usage theo workload group (2025 mới)
SELECT
    wg.name AS workload_group,
    wg.total_tempdb_usage_kb,
    wg.max_tempdb_space_kb
FROM sys.dm_resource_governor_workload_groups AS wg;

SSMS 22 Performance Dashboard

SSMS 22 đi kèm Performance Dashboard cập nhật cho SQL Server 2025:

  • Tab Vector Search — thống kê vector index usage, latency distribution.
  • Tab Locking — hiển thị lock escalation events, LAQ hit rate.
  • Tab External API — theo dõi latency và error rate của sp_invoke_external_rest_endpoint.

Query Store cho AI-augmented queries

-- Kiểm tra query có gọi external endpoint không
SELECT
    q.query_id,
    t.query_sql_text,
    q.count_external_api_calls,
    q.avg_external_api_duration_ms,
    q.avg_external_api_retry_count
FROM sys.query_store_query q
JOIN sys.query_store_query_text t ON q.query_text_id = t.query_text_id
WHERE q.count_external_api_calls > 0
ORDER BY q.avg_external_api_duration_ms DESC;
Tip phỏng vấn: Khi được hỏi về monitoring SQL Server 2025, hãy nhắc đến Query Store cho AI queriesvector search metrics — thể hiện bạn cập nhật tính năng mới nhất, không chỉ dùng DMV cũ.

20. Performance Benchmarks — con số thực tế (SQL Server 2025)

Kỷ lục performance mới

BenchmarkKết quảCấu hình
10TB TPC-HKỷ lục thế giới mớiAMD EPYC + HPE Superdome
3TB Price-PerformanceCải thiện 4% so với gen trướcTPC-H price/performance
OLTP throughputTang 15-25%Optimized Locking + IQP
Vector search @ 1BMillisecond latencyDiskANN trên NVMe SSD
Columnstore compression10-15x compressionSo với rowstore
Backup speed ZSTDNhanh hơn 30-50%So với MS_XPRESS

Chi tiết OLTP improvement

Optimized Locking (riêng):            +10-15% throughput
Intelligent Query Processing (IQP):    +5-10% throughput
Kết hợp cả hai:                        +15-25% throughput
+-----------------------------------------------------+
Giảm lock waits:                      -40% đến -60%
Giảm deadlocks:                       -20% đến -30%

DiskANN vs HNSW benchmark (1B vectors, 768 dimensions)

MetricHNSW (in-memory)DiskANN (SQL 2025)
RAM required~1.2 TB~120 GB (10x ít hơn)
Query latency (p99)0.5 ms3 ms
Recall@1098%97%
Index build time8 giờ3 giờ
Storage cost (ước tính)~$15K RAM~$500 SSD
Câu PV:"SQL Server 2025 nhanh hơn bao nhiêu so với 2022?"

"OLTP workload cải thiện 15-25% nhờ Optimized Locking + IQP. Backup nhanh hơn 30-50% với ZSTD compression. Vector search đạt millisecond latency trên billion-scale dataset với DiskANN, tốn ít RAM hơn 10x so với HNSW. Crash recovery từ hours xuống minutes với ADR cho TempDB. Đây là bản SQL Server có bước nhảy performance lớn nhất trong 5 năm."

© 2026 .NET Fresher Guide. All rights reserved.

Về Trang Web

Hướng dẫn toàn diện để chuẩn bị phỏng vấn vị trí .NET Fresher với nội dung từ lý thuyết đến thực hành.