Đặc thù SQL Server và Performance
1. Index — kiến thức cốt lõi
Hai loại chính
-- 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
- 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!).
- 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 (
Gender2 giá trị,Status3 giá trị). - Bảng heavy INSERT (mỗi insert tăng index maintenance).
"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
-- ❌ 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ĩa | Khi gặp thì sao |
|---|---|---|
| Table Scan | Đọc toàn bộ bảng | Thiếu index? Hoặc bảng nhỏ. |
| Clustered Index Scan | Đọc toàn bộ clustered | Tương tự — full scan |
| Clustered Index Seek | Tra cứu qua index ✅ | Tốt |
| Index Seek (non-clustered) | Tra non-clustered ✅ | Tốt |
| Key Lookup | Sau seek, lookup về clustered để lấy thêm cột | Dấu hiệu cần covering index |
| Hash Match | JOIN bằng hash | OK cho dataset lớn, nóng RAM. |
| Nested Loops | JOIN row-by-row | Tốt cho outer nhỏ + inner indexed |
| Merge Join | JOIN 2 nguồn đã sort | Tốt khi cả 2 đã sorted. |
| Sort | Sắp xếp | Đắt với data lớn — xem có thể tránh? |
"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
- ✅ Có index trên cột WHERE/JOIN/ORDER BY?
- ✅ Tránh
SELECT *— chỉ chọn cột cần (phá covering, tốn băng thông). - ✅ WHERE sargable (không function lên cột)?
- ✅ JOIN trên cột cùng kiểu dữ liệu (tránh implicit conversion).
- ✅ Dùng
EXISTSthayINvới subquery lớn. - ✅ Dùng
UNION ALLthayUNIONnếu không cần dedupe. - ✅ Pagination dùng OFFSET/FETCH thay vì lấy tất rồi cắt.
- ✅ Update statistics định kỳ.
- ✅ Defrag/rebuild index khi fragmentation > 30%.
- ✅ 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
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;
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 Server | Postgres / MySQL | |
|---|---|---|
| Identifier quote | [Name] | "Name" |
| Auto-increment | IDENTITY(1,1) | SERIAL (PG), AUTO_INCREMENT (MySQL) |
| String | N'text' (Unicode), 'ascii' | 'text' (UTF-8 default) |
| Limit | TOP N, OFFSET ... FETCH | LIMIT N OFFSET M |
| Now | SYSUTCDATETIME(), GETDATE() | NOW(), CURRENT_TIMESTAMP |
| Concat | + hoặc CONCAT() | ` |
| Boolean | BIT (0/1) | BOOLEAN |
| Default schema | dbo. | public. (PG), không có (MySQL) |
| Batch sep | GO (SSMS only) | ; thường |
| IF | IF ... BEGIN ... END | CASE WHEN |
| Schema in DB | DB có nhiều schema | DB ≈ 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 disk | Tối ưu cho SSD NVMe |
| Quy mô | Giới hạn bởi RAM | Tỷ vector (billion-scale) |
| Độ trễ | Microseconds | Milliseconds (vẫn cực nhanh) |
| Chi phí hạ tầng | RAM đắt | SSD 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 ý
Use-case thực tế
"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ằngVECTOR_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àm | Trước 2025 | SQL Server 2025 |
|---|---|---|
| Index JSON path | Computed column + regular index | JSON Index trực tiếp |
| Maintenance | Phải maintain computed column | Tự động — index hiểu JSON structure |
| Performance | Phải parse JSON lúc query | Index đã chứa giá trị tại path |
| Flexibility | Mỗi path = 1 computed column | 1 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'
);
"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:
- Mỗi row lock chiếm một lượng memory nhất định trong Lock Manager.
- Khi memory pressure cao (nhiều lock cùng lúc), engine escalate row locks thanh page lock, th?m chi table lock.
- 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ạnh | Trước 2025 | SQL Server 2025 |
|---|---|---|
| Lock escalation | Bật mặc định | Tắt mặc định |
| Memory / lock | ~64 bytes | ~32 bytes (giảm ~50%) |
| Row lock → table lock | Xảy ra thường xuyên | Hầu như không xảy ra |
| Concurrency | Bị giới hạn | Cao hơn đáng kể |
| Blocking chain | Dài, khó debug | Ngắ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
-- 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;
"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 ADR | Có ADR (2025) |
|---|---|---|
| Crash recovery | Vài giờ với TempDB lớn | Vài phút |
| Rollback transaction lớn | Tốn thời gian bằng thời gian chạy | Gần như tức thì |
| TempDB contention | Cao | Giảm đáng kể |
| Availability | Chờ recovery xong mới online | Online 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
# 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án | Tỉ lệ nén | Tốc độ nén | CPU usage |
|---|---|---|---|
| MS_XPRESS | Trung bình | Nhanh | Thấp |
| ZSTD (2025) | Tốt hơn 20-30% | Nhanh hơn | Trung 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
-- 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
| OS | SQL Server 2022 | SQL Server 2025 |
|---|---|---|
| Red Hat 8.x | Co | Co |
| Red Hat 9.x | Khong | Co |
| Ubuntu 20.04 | Co | Co |
| Ubuntu 22.04 | Co | Co |
| Ubuntu 24.04 | Khong | Co |
| Container | Co | Co + 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.
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
Azure SQL DB Hyperscale mở rộng
| Cấu hình | Trước 2025 | 2025 |
|---|---|---|
| vCores tối đa | 128 vCores | 160 và 192 vCores |
| Storage tối đa | 100 TB | 100 TB |
| Read replicas | 30 | 30 |
| Vector search | Khong | Co (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 pattern và external 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;
"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_endpointvới built-in retry, và quản lý model quaCREATE 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;
20. Performance Benchmarks — con số thực tế (SQL Server 2025)
Kỷ lục performance mới
| Benchmark | Kết quả | Cấu hình |
|---|---|---|
| 10TB TPC-H | Kỷ lục thế giới mới | AMD EPYC + HPE Superdome |
| 3TB Price-Performance | Cải thiện 4% so với gen trước | TPC-H price/performance |
| OLTP throughput | Tang 15-25% | Optimized Locking + IQP |
| Vector search @ 1B | Millisecond latency | DiskANN trên NVMe SSD |
| Columnstore compression | 10-15x compression | So với rowstore |
| Backup speed ZSTD | Nhanh 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)
| Metric | HNSW (in-memory) | DiskANN (SQL 2025) |
|---|---|---|
| RAM required | ~1.2 TB | ~120 GB (10x ít hơn) |
| Query latency (p99) | 0.5 ms | 3 ms |
| Recall@10 | 98% | 97% |
| Index build time | 8 giờ | 3 giờ |
| Storage cost (ước tính) | ~$15K RAM | ~$500 SSD |
"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."