Knowledge Overview

About Me

I’m Ngo Quang Huy, a Software Engineer based in Hanoi, Vietnam. I have 4 years of professional experience building scalable, enterprise-level systems using .NET Core, SQL Server, and ReactJS — with a strong focus on Backend development.

My journey started at FPT Software, where I worked on a SaaS pension management system in the financial domain. As a Backend Engineer, I handled member management, payroll calculation, and report generation. For my contributions, I received the Best Performer award in 2024. After that, I joined another project at FPT Software, building a Monitoring and Alert System powered by Elasticsearch data.

Currently, I work at Optimizely — a Content Management System — as a Fullstack Engineer, though most of my work is still backend-focused. My main responsibility is customizing the CMS platform based on customer requirements.

I’m now looking for new opportunities where I can apply my backend skills, grow as an engineer, and take on new challenges. I believe that every project is a chance to improve, and I’m always ready to contribute my best. Glad to see with everyone, and I hope we have a great conversation ahead!

Giới thiệu

Tài liệu này tổng hợp kiến thức kỹ thuật theo lộ trình học tập dành cho Backend Developer, bao gồm 7 mảng công nghệ chính. Mỗi mảng được tổ chức từ nền tảng đến nâng cao, kèm code example thực tế.

Danh sách chủ đề

1. SQL Server

Kiến thức SQL Server từ nền tảng đến các tính năng doanh nghiệp.

2. C#/.NET

Lộ trình đầy đủ cho vị trí C#/.NET Developer, từ ngôn ngữ đến kiến trúc hệ thống.

Kiến trúc Phần mềm (Chi tiết)

3. ReactJS

React 18+ với functional components và hooks. Bao gồm state management, data fetching, và Next.js.

4. Elasticsearch

Elasticsearch 8+ với .NET client chính thức (Elastic.Clients.Elasticsearch).

5. Work Experience

Real-world projects and professional experience in enterprise software development.

Key Achievements

• Performance Optimization: Reduced pension calculation time by 90% through event-driven architecture and pre-calculation strategies.
• Report Generation: Cut report processing time by 50% using background jobs, message queues, and pre-generated JSON files.
• Fullstack Delivery: Led Google Maps integration in Optimizely CMS, bridging backend configuration with rich frontend UX.
• Recognition: Best Performer 2024 at FPT Software for backend optimization contributions.

6. Algorithms

Fundamental algorithms and data structures for problem-solving and technical interviews.

7. System Design

Scalable system design principles, architectural patterns, and real-world case studies.

Lộ trình học gợi ý

Cho người mới bắt đầu

1. C# Cơ bản → OOP → Async/Await & LINQ
2. SQL Server Nền tảng → Index & Hiệu suất
3. JSX & Rendering → Hooks Cơ bản

Cho .NET Developer

1. SOLID Principles → Design Patterns → Clean Architecture
2. EF Core → CQRS → Microservices
3. Elasticsearch Core Concepts → Query DSL

Chuẩn bị phỏng vấn

• Câu hỏi Phân biệt C#/.NET
• Transactions & Concurrency
• Performance Tuning
• System Design Case Studies
• Work Experience Q&A

SQL Server Roadmap

Chương này bao gồm toàn bộ kiến thức SQL Server từ cơ bản đến nâng cao, phù hợp cho mọi cấp độ từ Junior đến Senior.

Lộ trình học

1. Nền Tảng SQL Server

Kiến trúc, T-SQL cơ bản, kiểu dữ liệu, DDL, DML và truy vấn.

2. Index & Hiệu suất

Clustered/Non-Clustered Index, Execution Plans, Query Optimization, Statistics.

3. Lập trình T-SQL

Stored Procedures, Functions, Triggers, Views, CTEs, Window Functions.

4. Giao dịch & Đồng thời

ACID, Isolation Levels, Locking, Blocking, Deadlocks.

5. Bảo mật & Quản trị

Authentication, Permissions, Backup & Recovery, Agent Jobs, Monitoring.

6. Tính năng Nâng cao

Partitioning, JSON/XML, Temporal Tables, In-Memory OLTP, High Availability, CDC.

• Index Nâng Cao
• Query Optimization
• Execution Plans

1. Nền Tảng SQL Server

Giới thiệu

Phần này trình bày các kiến thức nền tảng về SQL Server và T-SQL, từ kiến trúc hệ thống đến các câu lệnh cơ bản nhất. Đây là nền tảng bắt buộc để hiểu sâu hơn về hiệu suất, indexing và các chủ đề nâng cao.

Nội dung chính

Kiến trúc SQL Server

• T-SQL Cơ bản & Kiến trúc - SQL Server Engine, database files, memory architecture, T-SQL fundamentals

Kiểu dữ liệu

• Kiểu Dữ liệu - Numeric, String, DateTime, Binary types; Unicode vs non-Unicode; type conversion

DDL - Data Definition Language

• DDL - CREATE/ALTER/DROP cho database objects, constraints, identity, sequences, temporal tables, indexes

DML - Data Manipulation Language

• DML - INSERT, UPDATE, DELETE, MERGE, BULK operations, OUTPUT clause, transactions

Câu hỏi phỏng vấn (Sắp xếp từ dễ đến khó)

Mức độ: Dễ (Junior)

1. SQL Server là gì? Sự khác biệt giữa SQL Server instance và database là gì?
2. Các file database trong SQL Server có những loại nào? (.mdf, .ndf, .ldf)
3. SELECT, WHERE, ORDER BY, GROUP BY khác nhau như thế nào về mục đích sử dụng?
4. HAVING và WHERE khác nhau như thế nào?
5. Sự khác biệt giữa INNER JOIN, LEFT JOIN, RIGHT JOIN, và FULL OUTER JOIN?
6. NULL trong SQL Server là gì? Cách xử lý NULL với IS NULL, ISNULL(), COALESCE()?
7. DISTINCT dùng để làm gì? Ví dụ thực tế?
8. Sự khác biệt giữa char và varchar? Giữa varchar và nvarchar?
9. int, bigint, smallint, tinyint khác nhau ở điểm gì?
10. PRIMARY KEY và UNIQUE constraint khác nhau như thế nào?
11. NOT NULL constraint hoạt động như thế nào?
12. DEFAULT constraint dùng để làm gì?
13. Câu lệnh INSERT INTO...VALUES cơ bản viết như thế nào?
14. Sự khác biệt giữa DELETE và TRUNCATE TABLE?
15. IDENTITY column là gì? Cú pháp khai báo như thế nào?

Mức độ: Trung bình (Mid-level)

16. CASE expression (simple và searched) hoạt động như thế nào? Ví dụ thực tế?
17. TOP N và OFFSET-FETCH khác nhau như thế nào? Cái nào nên dùng cho phân trang?
18. Các hàm xử lý chuỗi phổ biến: LEN, SUBSTRING, CHARINDEX, REPLACE, TRIM?
19. Sự khác biệt giữa GETDATE(), GETUTCDATE(), SYSDATETIME(), và SYSUTCDATETIME()?
20. DATEADD, DATEDIFF, DATEPART dùng như thế nào?
21. decimal vs float vs money - khi nào dùng cái nào? Tại sao không nên dùng float cho tiền tệ?
22. datetime vs datetime2 vs datetimeoffset - sự khác biệt và khi nào dùng?
23. CAST vs CONVERT vs TRY_CAST vs TRY_CONVERT - khác nhau như thế nào?
24. FOREIGN KEY constraint là gì? ON DELETE CASCADE hoạt động như thế nào?
25. CHECK constraint dùng để làm gì? Ví dụ thực tế?
26. UPDATE với JOIN viết như thế nào?
27. DELETE với JOIN viết như thế nào?
28. MERGE statement (upsert) dùng để làm gì? Cú pháp cơ bản?
29. OUTPUT clause trong DML dùng để làm gì?
30. Computed column là gì? Sự khác biệt giữa persisted và non-persisted?
31. Schemas trong SQL Server là gì? Tại sao nên dùng schemas thay vì tất cả trong dbo?

Mức độ: Khó (Senior)

32. SQL Server Buffer Pool hoạt động như thế nào? Tại sao memory management quan trọng?
33. Pages và Extents trong SQL Server là gì? Ảnh hưởng đến hiệu năng như thế nào?
34. Plan Cache hoạt động như thế nào? Parameter sniffing là gì và khi nào gây ra vấn đề?
35. Implicit conversion trong SQL Server là gì? Tại sao có thể gây ra index scan thay vì seek?
36. Temporal Tables (system-versioned) là gì? Use case thực tế?
37. SEQUENCE object so với IDENTITY column - ưu nhược điểm?
38. NEWID() vs NEWSEQUENTIALID() vs IDENTITY - khi nào dùng cái nào? Tác động đến index fragmentation?
39. BULK INSERT vs INSERT INTO...SELECT - khi nào dùng cái nào cho hiệu năng tốt nhất?
40. Set-based operations vs row-by-row (cursor) - vì sao nên tránh cursor trong SQL Server?
41. nvarchar(MAX) vs nvarchar(4000) - tác động đến hiệu năng và storage?
42. INDEX trong DDL - Clustered vs Nonclustered, khi nào tạo index trong CREATE TABLE và khi nào tách riêng?
43. Cascading referential actions (CASCADE, SET NULL, NO ACTION) - tác động đến performance với large datasets?

T-SQL Cơ bản

Kiến trúc SQL Server

Các thành phần chính của SQL Server Engine

SQL Server Engine được chia thành hai phần lớn: Relational Engine (hay Query Processor) và Storage Engine.

SQL Server Instance
├── Relational Engine (Query Processor)
│   ├── Command Parser       -- Phân tích cú pháp T-SQL
│   ├── Query Optimizer      -- Lựa chọn execution plan tối ưu
│   └── Query Executor       -- Thực thi execution plan
└── Storage Engine
    ├── Buffer Manager       -- Quản lý bộ nhớ (Buffer Pool)
    ├── Log Manager          -- Quản lý Transaction Log
    ├── Access Methods       -- B-tree traversal, heap scans
    └── Lock Manager         -- Quản lý locking và concurrency

Relational Engine (Query Processor)

Storage Engine

Database Files

SQL Server tổ chức dữ liệu trên disk theo 3 loại file:

-- Xem thông tin files của database hiện tại
SELECT 
    name,
    physical_name,
    type_desc,
    size * 8 / 1024 AS size_mb,
    max_size,
    growth
FROM sys.database_files;

Lưu ý: Log file (.ldf) ghi tuần tự (sequential write) nên nên đặt trên disk riêng với data files để tối ưu I/O.

Pages và Extents

Pages (Trang)

• Đơn vị lưu trữ nhỏ nhất trong SQL Server là page, kích thước cố định 8KB (8192 bytes).
• Mỗi page có header 96 bytes, còn lại ~8096 bytes để lưu data.
• Các loại page chính:

Extents (Nhóm trang)

• Extent = 8 pages liền kề = 64KB.
• Hai loại extent:

-- Xem số pages của từng table
SELECT 
    t.name AS table_name,
    p.rows,
    SUM(a.total_pages) * 8 AS total_kb,
    SUM(a.used_pages) * 8 AS used_kb
FROM sys.tables t
JOIN sys.indexes i ON t.object_id = i.object_id
JOIN sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
JOIN sys.allocation_units a ON p.partition_id = a.container_id
GROUP BY t.name, p.rows
ORDER BY total_kb DESC;

Memory Architecture

Buffer Pool

Buffer Pool là vùng nhớ lớn nhất trong SQL Server, được dùng để cache data pages đọc từ disk.

Memory (RAM)
└── Buffer Pool
    ├── Data Page Cache      -- Cache các 8KB data pages
    ├── Plan Cache           -- Cache các execution plans
    ├── Log Cache            -- Cache log records trước khi flush
    └── Other caches         -- Connection info, metadata, etc.

Nguyên tắc hoạt động:

1. SQL Server đọc page từ disk → lưu vào Buffer Pool
2. Lần sau đọc page đó → lấy trực tiếp từ RAM (không đọc disk)
3. Khi RAM đầy → dùng LRU (Least Recently Used) để evict pages cũ

-- Xem Buffer Pool usage
SELECT 
    database_id,
    COUNT(*) AS cached_pages,
    COUNT(*) * 8 / 1024 AS cached_mb
FROM sys.dm_os_buffer_descriptors
GROUP BY database_id
ORDER BY cached_pages DESC;

Plan Cache

Execution plans được cache lại để tái sử dụng:

-- Xem các plans đang được cache
SELECT 
    qs.execution_count,
    qs.total_elapsed_time / qs.execution_count AS avg_elapsed_us,
    SUBSTRING(qt.text, (qs.statement_start_offset/2) + 1,
        ((qs.statement_end_offset - qs.statement_start_offset)/2) + 1) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY qs.total_elapsed_time DESC;

SQL Server Instance vs Database

-- Xem thông tin instance
SELECT 
    @@SERVERNAME AS server_name,
    @@VERSION AS version,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('ProductVersion') AS product_version;

-- Xem các databases trong instance
SELECT name, state_desc, recovery_model_desc
FROM sys.databases
ORDER BY name;

T-SQL Cơ bản

SELECT, WHERE, ORDER BY

-- SELECT cơ bản
SELECT column1, column2, column3
FROM TableName;

-- Lấy tất cả cột (tránh dùng trong production)
SELECT * FROM Employees;

-- WHERE để lọc dữ liệu
SELECT EmployeeId, FullName, Salary
FROM Employees
WHERE DepartmentId = 5
  AND Salary > 50000
  AND HireDate >= '2020-01-01';

-- ORDER BY để sắp xếp
SELECT EmployeeId, FullName, Salary
FROM Employees
ORDER BY Salary DESC, FullName ASC;

GROUP BY và HAVING

-- GROUP BY - nhóm và tổng hợp
SELECT 
    DepartmentId,
    COUNT(*) AS employee_count,
    AVG(Salary) AS avg_salary,
    MAX(Salary) AS max_salary,
    MIN(Salary) AS min_salary
FROM Employees
GROUP BY DepartmentId;

-- HAVING - lọc trên kết quả aggregate (khác WHERE)
SELECT 
    DepartmentId,
    COUNT(*) AS employee_count,
    AVG(Salary) AS avg_salary
FROM Employees
WHERE IsActive = 1                    -- WHERE lọc trước GROUP BY
GROUP BY DepartmentId
HAVING COUNT(*) >= 5                  -- HAVING lọc sau GROUP BY
    AND AVG(Salary) > 60000
ORDER BY avg_salary DESC;

Thứ tự thực thi: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY

Aliases và DISTINCT

-- Column alias
SELECT 
    e.EmployeeId AS emp_id,
    e.FirstName + ' ' + e.LastName AS full_name,
    d.DepartmentName AS dept
FROM Employees e                      -- Table alias
JOIN Departments d ON e.DepartmentId = d.DepartmentId;

-- DISTINCT - loại bỏ hàng trùng lặp
SELECT DISTINCT DepartmentId FROM Employees;

-- DISTINCT với nhiều cột
SELECT DISTINCT DepartmentId, JobTitle 
FROM Employees
ORDER BY DepartmentId;

TOP và OFFSET-FETCH

-- TOP N - lấy N hàng đầu
SELECT TOP 10 EmployeeId, FullName, Salary
FROM Employees
ORDER BY Salary DESC;

-- TOP với PERCENT
SELECT TOP 10 PERCENT EmployeeId, FullName
FROM Employees;

-- TOP WITH TIES - bao gồm các hàng có giá trị bằng nhau
SELECT TOP 5 WITH TIES EmployeeId, Salary
FROM Employees
ORDER BY Salary DESC;

-- OFFSET-FETCH (SQL Server 2012+) - phân trang chuẩn
DECLARE @PageSize INT = 10;
DECLARE @PageNumber INT = 2;  -- Trang thứ 2

SELECT EmployeeId, FullName, Salary
FROM Employees
ORDER BY EmployeeId
OFFSET (@PageNumber - 1) * @PageSize ROWS
FETCH NEXT @PageSize ROWS ONLY;

Lưu ý: OFFSET-FETCH yêu cầu ORDER BY. Ưu tiên dùng OFFSET-FETCH thay vì TOP cho phân trang vì chuẩn hơn.

LIKE và Wildcard

-- % - khớp 0 hoặc nhiều ký tự
SELECT * FROM Employees WHERE LastName LIKE 'Smith%';    -- Bắt đầu bằng Smith
SELECT * FROM Employees WHERE Email LIKE '%@gmail.com';  -- Kết thúc bằng @gmail.com
SELECT * FROM Employees WHERE FullName LIKE '%Nguyen%';  -- Chứa Nguyen

-- _ - khớp đúng 1 ký tự
SELECT * FROM Products WHERE ProductCode LIKE 'A__';     -- A + 2 ký tự bất kỳ

-- [] - khớp 1 ký tự trong tập hợp
SELECT * FROM Employees WHERE LastName LIKE '[ABC]%';    -- Bắt đầu bằng A, B hoặc C

-- [^] - khớp 1 ký tự KHÔNG trong tập hợp
SELECT * FROM Employees WHERE LastName LIKE '[^ABC]%';   -- Không bắt đầu bằng A, B, C

-- Thoát ký tự đặc biệt với ESCAPE
SELECT * FROM Products WHERE Description LIKE '50\%' ESCAPE '\';  -- Chứa "50%"

Xử lý NULL

-- IS NULL / IS NOT NULL (không dùng = NULL)
SELECT * FROM Employees WHERE ManagerId IS NULL;
SELECT * FROM Employees WHERE ManagerId IS NOT NULL;

-- ISNULL(expression, replacement)  - SQL Server specific
SELECT 
    EmployeeId,
    ISNULL(MiddleName, '') AS middle_name,
    ISNULL(Phone, 'N/A') AS phone
FROM Employees;

-- COALESCE(val1, val2, ...) - trả về giá trị non-NULL đầu tiên (ANSI standard)
SELECT 
    EmployeeId,
    COALESCE(MobilePhone, OfficePhone, HomePhone, 'No phone') AS contact_phone
FROM Employees;

-- NULLIF(expr1, expr2) - trả về NULL nếu hai giá trị bằng nhau
-- Dùng để tránh chia cho 0
SELECT 
    Revenue,
    Cost,
    Revenue / NULLIF(Cost, 0) AS revenue_ratio
FROM FinancialData;

-- NULL trong aggregate functions (NULL bị bỏ qua)
SELECT 
    COUNT(*) AS total_rows,         -- Đếm tất cả hàng
    COUNT(Commission) AS has_commission, -- Đếm hàng có Commission != NULL
    AVG(Commission) AS avg_comm,    -- AVG bỏ qua NULL
    SUM(Commission) AS total_comm
FROM Employees;

CASE Expressions

-- Simple CASE (so sánh bằng)
SELECT 
    EmployeeId,
    FullName,
    Status,
    CASE Status
        WHEN 'A' THEN 'Active'
        WHEN 'I' THEN 'Inactive'
        WHEN 'T' THEN 'Terminated'
        ELSE 'Unknown'
    END AS status_description
FROM Employees;

-- Searched CASE (điều kiện logic)
SELECT 
    EmployeeId,
    FullName,
    Salary,
    CASE 
        WHEN Salary < 30000 THEN 'Entry Level'
        WHEN Salary BETWEEN 30000 AND 60000 THEN 'Mid Level'
        WHEN Salary BETWEEN 60001 AND 100000 THEN 'Senior Level'
        WHEN Salary > 100000 THEN 'Executive'
        ELSE 'Unknown'
    END AS salary_band
FROM Employees;

-- CASE trong ORDER BY
SELECT EmployeeId, FullName, Priority
FROM Tasks
ORDER BY 
    CASE Priority
        WHEN 'High' THEN 1
        WHEN 'Medium' THEN 2
        WHEN 'Low' THEN 3
        ELSE 4
    END;

-- CASE trong UPDATE
UPDATE Employees
SET Salary = Salary * 
    CASE 
        WHEN YearsOfService >= 10 THEN 1.10  -- Tăng 10%
        WHEN YearsOfService >= 5  THEN 1.07  -- Tăng 7%
        ELSE 1.05                            -- Tăng 5%
    END;

String Functions (Hàm xử lý chuỗi)

-- LEN - độ dài chuỗi (không tính trailing spaces)
SELECT LEN('Hello World');   -- 11
SELECT LEN('  Hello  ');     -- 9 (không tính 2 spaces cuối)

-- SUBSTRING(string, start, length) - cắt chuỗi (1-indexed)
SELECT SUBSTRING('Hello World', 7, 5);   -- 'World'
SELECT SUBSTRING(Email, 1, CHARINDEX('@', Email) - 1) AS username
FROM Employees;

-- CHARINDEX(pattern, string [, start]) - tìm vị trí chuỗi con
SELECT CHARINDEX('@', 'user@example.com');       -- 5
SELECT CHARINDEX('a', 'banana', 3);              -- 4 (bắt đầu tìm từ vị trí 3)

-- REPLACE(string, old, new) - thay thế
SELECT REPLACE('Hello World', 'World', 'SQL');   -- 'Hello SQL'
SELECT REPLACE(Phone, '-', '') AS cleaned_phone FROM Employees;

-- TRIM, LTRIM, RTRIM
SELECT TRIM('  Hello  ');    -- 'Hello'  (SQL Server 2017+)
SELECT LTRIM('  Hello  ');   -- 'Hello  '
SELECT RTRIM('  Hello  ');   -- '  Hello'
SELECT TRIM('x' FROM 'xxxHelloxxx');  -- 'Hello' (SQL Server 2017+)

-- UPPER, LOWER
SELECT UPPER('hello world');  -- 'HELLO WORLD'
SELECT LOWER('HELLO WORLD');  -- 'hello world'

-- CONCAT - nối chuỗi (NULL-safe)
SELECT CONCAT('Hello', ' ', 'World', '!');       -- 'Hello World!'
SELECT CONCAT(FirstName, ' ', LastName) AS full_name FROM Employees;

-- CONCAT_WS - nối với separator (SQL Server 2017+)
SELECT CONCAT_WS(', ', City, State, Country);    -- 'Hanoi, HN, Vietnam'

-- FORMAT - định dạng (costly, tránh dùng trong queries lớn)
SELECT FORMAT(12345.678, 'N2');          -- '12,345.68'
SELECT FORMAT(GETDATE(), 'dd/MM/yyyy');  -- '01/04/2026'
SELECT FORMAT(Salary, 'C', 'vi-VN');    -- Định dạng tiền VN

-- REPLICATE - lặp chuỗi
SELECT REPLICATE('*', 10);              -- '**********'

-- REVERSE
SELECT REVERSE('Hello');                -- 'olleH'

-- STRING_SPLIT (SQL Server 2016+)
SELECT value FROM STRING_SPLIT('a,b,c,d', ',');

-- LEFT, RIGHT
SELECT LEFT('Hello World', 5);          -- 'Hello'
SELECT RIGHT('Hello World', 5);         -- 'World'

-- PATINDEX - tìm pattern (hỗ trợ wildcard)
SELECT PATINDEX('%[0-9]%', 'abc123def');  -- 4 (vị trí số đầu tiên)

Date Functions (Hàm ngày tháng)

-- Hàm lấy ngày/giờ hiện tại
SELECT GETDATE();           -- datetime, local time
SELECT GETUTCDATE();        -- datetime, UTC time
SELECT SYSDATETIME();       -- datetime2(7), local time, cao hơn độ chính xác
SELECT SYSUTCDATETIME();    -- datetime2(7), UTC time
SELECT SYSDATETIMEOFFSET(); -- datetimeoffset, kèm timezone offset

-- DATEADD(part, number, date) - thêm/bớt thời gian
SELECT DATEADD(DAY, 30, GETDATE());           -- 30 ngày sau
SELECT DATEADD(MONTH, -3, GETDATE());         -- 3 tháng trước
SELECT DATEADD(YEAR, 1, '2025-01-01');        -- '2026-01-01'
SELECT DATEADD(HOUR, 2, GETDATE());           -- 2 giờ sau
SELECT DATEADD(MINUTE, -30, GETDATE());       -- 30 phút trước

-- DATEDIFF(part, start, end) - khoảng cách thời gian
SELECT DATEDIFF(DAY, '2025-01-01', '2026-01-01');   -- 365
SELECT DATEDIFF(MONTH, HireDate, GETDATE()) AS months_employed FROM Employees;
SELECT DATEDIFF(YEAR, BirthDate, GETDATE()) AS age FROM Employees;

-- DATEPART(part, date) - lấy phần của ngày
SELECT DATEPART(YEAR, GETDATE());    -- 2026
SELECT DATEPART(MONTH, GETDATE());   -- 4
SELECT DATEPART(DAY, GETDATE());     -- 1
SELECT DATEPART(WEEKDAY, GETDATE()); -- Ngày trong tuần (1=Sunday)
SELECT DATEPART(HOUR, GETDATE());    -- Giờ

-- DATENAME - tương tự DATEPART nhưng trả text
SELECT DATENAME(MONTH, GETDATE());   -- 'April'
SELECT DATENAME(WEEKDAY, GETDATE()); -- 'Wednesday'

-- DAY(), MONTH(), YEAR() - shorthand
SELECT DAY(GETDATE()), MONTH(GETDATE()), YEAR(GETDATE());

-- FORMAT với ngày (chậm hơn CONVERT, dùng cho display)
SELECT FORMAT(GETDATE(), 'dd/MM/yyyy');          -- '01/04/2026'
SELECT FORMAT(GETDATE(), 'yyyy-MM-dd HH:mm:ss'); -- '2026-04-01 10:30:00'

-- CONVERT với ngày (nhanh hơn FORMAT)
SELECT CONVERT(VARCHAR(10), GETDATE(), 103);   -- '01/04/2026' (dd/mm/yyyy)
SELECT CONVERT(VARCHAR(10), GETDATE(), 120);   -- '2026-04-01' (yyyy-mm-dd)
SELECT CONVERT(DATE, GETDATE());               -- Cắt phần time

-- EOMONTH - ngày cuối tháng (SQL Server 2012+)
SELECT EOMONTH(GETDATE());           -- Ngày cuối tháng hiện tại
SELECT EOMONTH('2026-02-01');        -- '2026-02-28'

-- DATEFROMPARTS, DATETIMEFROMPARTS (SQL Server 2012+)
SELECT DATEFROMPARTS(2026, 4, 1);       -- '2026-04-01'
SELECT DATETIMEFROMPARTS(2026, 4, 1, 10, 30, 0, 0);  -- '2026-04-01 10:30:00'

-- Ví dụ thực tế: tìm nhân viên thuê trong 90 ngày qua
SELECT EmployeeId, FullName, HireDate
FROM Employees
WHERE HireDate >= DATEADD(DAY, -90, GETDATE())
  AND HireDate < GETDATE();

Math Functions (Hàm toán học)

-- ROUND(number, decimal_places [, truncate])
SELECT ROUND(3.14159, 2);     -- 3.14
SELECT ROUND(3.145, 2);       -- 3.15 (round half up)
SELECT ROUND(3.145, 2, 1);    -- 3.14 (truncate, không round)

-- ABS - giá trị tuyệt đối
SELECT ABS(-42);               -- 42
SELECT ABS(3.14);              -- 3.14

-- CEILING - làm tròn lên (trần)
SELECT CEILING(3.1);           -- 4
SELECT CEILING(-3.9);          -- -3

-- FLOOR - làm tròn xuống (sàn)
SELECT FLOOR(3.9);             -- 3
SELECT FLOOR(-3.1);            -- -4

-- POWER(base, exponent)
SELECT POWER(2, 10);           -- 1024
SELECT POWER(3.0, 3);          -- 27.0

-- SQRT - căn bậc hai
SELECT SQRT(144);              -- 12.0

-- SQUARE
SELECT SQUARE(5);              -- 25

-- PI
SELECT PI();                   -- 3.14159265358979

-- LOG, LOG10, EXP
SELECT LOG(100);               -- Logarithm tự nhiên
SELECT LOG(100, 10);           -- Log base 10 = 2 (SQL Server 2012+)
SELECT LOG10(1000);            -- 3

-- SIGN - dấu của số
SELECT SIGN(-5);   -- -1
SELECT SIGN(0);    -- 0
SELECT SIGN(5);    -- 1

-- Ví dụ thực tế: tính commission
SELECT 
    EmployeeId,
    Sales,
    ROUND(Sales * 0.05, 2) AS commission,
    CEILING(Sales / 1000.0) AS bonus_units
FROM SalesData;

Aggregate Functions (Hàm tổng hợp)

-- COUNT
SELECT COUNT(*) AS total FROM Employees;              -- Đếm tất cả hàng (kể cả NULL)
SELECT COUNT(Email) AS has_email FROM Employees;      -- Đếm hàng có Email NOT NULL
SELECT COUNT(DISTINCT DepartmentId) AS dept_count FROM Employees;  -- Đếm distinct values

-- SUM
SELECT SUM(Salary) AS total_salary FROM Employees;
SELECT SUM(Salary) AS total_salary FROM Employees WHERE IsActive = 1;

-- AVG (bỏ qua NULL)
SELECT AVG(Salary) AS avg_salary FROM Employees;
-- Chú ý: AVG(int) trả về int! Dùng AVG(CAST(col AS decimal))
SELECT AVG(CAST(Score AS DECIMAL(10,2))) AS avg_score FROM Students;

-- MIN, MAX
SELECT MIN(Salary) AS min_salary, MAX(Salary) AS max_salary FROM Employees;
SELECT MIN(HireDate) AS first_hire, MAX(HireDate) AS last_hire FROM Employees;

-- Kết hợp với GROUP BY
SELECT 
    d.DepartmentName,
    COUNT(e.EmployeeId) AS headcount,
    MIN(e.Salary) AS min_salary,
    MAX(e.Salary) AS max_salary,
    AVG(e.Salary) AS avg_salary,
    SUM(e.Salary) AS total_payroll
FROM Departments d
LEFT JOIN Employees e ON d.DepartmentId = e.DepartmentId
GROUP BY d.DepartmentName
ORDER BY total_payroll DESC;

-- STRING_AGG - gộp chuỗi (SQL Server 2017+)
SELECT 
    DepartmentId,
    STRING_AGG(FullName, ', ') WITHIN GROUP (ORDER BY FullName) AS employees
FROM Employees
GROUP BY DepartmentId;

Joins (Phép kết bảng)

-- INNER JOIN - chỉ trả về hàng có khớp ở cả 2 bảng
SELECT e.EmployeeId, e.FullName, d.DepartmentName
FROM Employees e
INNER JOIN Departments d ON e.DepartmentId = d.DepartmentId;

-- LEFT JOIN - tất cả từ bảng trái, NULL với bảng phải nếu không khớp
SELECT e.EmployeeId, e.FullName, d.DepartmentName
FROM Employees e
LEFT JOIN Departments d ON e.DepartmentId = d.DepartmentId;

-- RIGHT JOIN - tất cả từ bảng phải
SELECT e.EmployeeId, e.FullName, d.DepartmentName
FROM Employees e
RIGHT JOIN Departments d ON e.DepartmentId = d.DepartmentId;

-- FULL OUTER JOIN - tất cả từ cả 2 bảng
SELECT e.EmployeeId, e.FullName, d.DepartmentName
FROM Employees e
FULL OUTER JOIN Departments d ON e.DepartmentId = d.DepartmentId;

-- CROSS JOIN - tích Descartes (n × m rows)
SELECT p.ProductName, c.ColorName
FROM Products p
CROSS JOIN Colors c;

-- SELF JOIN - bảng join với chính nó
SELECT 
    e.EmployeeId,
    e.FullName AS employee,
    m.FullName AS manager
FROM Employees e
LEFT JOIN Employees m ON e.ManagerId = m.EmployeeId;

-- Multi-table join
SELECT 
    o.OrderId,
    c.CustomerName,
    e.FullName AS salesperson,
    SUM(od.Quantity * od.UnitPrice) AS order_total
FROM Orders o
JOIN Customers c ON o.CustomerId = c.CustomerId
JOIN Employees e ON o.EmployeeId = e.EmployeeId
JOIN OrderDetails od ON o.OrderId = od.OrderId
GROUP BY o.OrderId, c.CustomerName, e.FullName;

Kiểu Dữ liệu trong SQL Server

1. Kiểu số (Numeric Types)

Integer Types

-- Ví dụ sử dụng
CREATE TABLE Products (
    ProductId    INT          NOT NULL,  -- PK thông thường
    CategoryId   TINYINT      NOT NULL,  -- Giả sử < 256 categories
    StockCount   SMALLINT     NOT NULL,  -- Tồn kho không quá 32767
    TotalOrders  BIGINT       NOT NULL DEFAULT 0  -- Có thể rất lớn
);

-- Tính toán có thể overflow nếu dùng sai type
SELECT 2000000000 + 2000000000;           -- Overflow với INT!
SELECT CAST(2000000000 AS BIGINT) + 2000000000;  -- OK

-- Kiểm tra giới hạn
SELECT 
    'tinyint'  AS type_name, CAST(255 AS TINYINT) AS max_val UNION ALL
    SELECT 'smallint', CAST(32767 AS SMALLINT) UNION ALL
    SELECT 'int',      CAST(2147483647 AS INT) UNION ALL
    SELECT 'bigint',   CAST(9223372036854775807 AS BIGINT);

Decimal/Numeric Types

DECIMAL(p, s) và NUMERIC(p, s) là synonyms, lưu số thập phân chính xác:

• p (precision): tổng số chữ số (1-38)
• s (scale): số chữ số sau dấu thập phân (0 đến p)

-- Dùng cho tiền tệ và số thập phân cần chính xác
DECLARE @price DECIMAL(10, 2);  -- Tối đa 99999999.99
DECLARE @rate  DECIMAL(5, 4);   -- Tối đa 9.9999 (ví dụ: tax rate)
DECLARE @qty   NUMERIC(18, 3);  -- Lượng với 3 chữ số thập phân

-- Ví dụ tính toán chính xác
SELECT CAST(0.1 AS DECIMAL(10,1)) + CAST(0.2 AS DECIMAL(10,1));  -- 0.3 chính xác
SELECT 0.1 + 0.2;  -- 0.300000000000... (float, không chính xác)

Float và Real

Cảnh báo: float và real là approximate - KHÔNG dùng cho tiền tệ, kế toán, hoặc bất kỳ tính toán nào cần độ chính xác tuyệt đối!

-- Vấn đề với float
SELECT CAST(0.1 AS FLOAT) + CAST(0.2 AS FLOAT);
-- Kết quả: 0.30000000000000004 (sai!)

-- Float thích hợp cho: tọa độ GPS, đo lường khoa học, phân tích thống kê
CREATE TABLE SensorData (
    ReadingId  INT PRIMARY KEY,
    Latitude   FLOAT NOT NULL,   -- GPS coordinates
    Longitude  FLOAT NOT NULL,
    Temperature REAL NOT NULL    -- Nhiệt độ, sai số nhỏ chấp nhận được
);

Money Types

-- money type
DECLARE @price MONEY = 19.99;
DECLARE @tax   MONEY = 0.10;
SELECT @price + @tax;  -- 20.09

-- Vấn đề với money: phép chia có thể mất độ chính xác
DECLARE @total MONEY = 100;
SELECT @total / 3;  -- 33.3333 (OK)
SELECT @total / 3 * 3;  -- 99.9999 (mất 0.0001!)

-- Khuyến nghị: dùng DECIMAL(19, 4) thay vì MONEY để có kiểm soát tốt hơn

2. Kiểu chuỗi (String Types)

Non-Unicode vs Unicode

char vs varchar

-- char(n): fixed-length, padding bằng spaces nếu ngắn hơn n
DECLARE @fixed CHAR(10) = 'Hello';
SELECT LEN(@fixed);    -- 5 (LEN bỏ trailing spaces)
SELECT DATALENGTH(@fixed);  -- 10 (luôn 10 bytes)

-- varchar(n): variable-length, không padding
DECLARE @var VARCHAR(10) = 'Hello';
SELECT LEN(@var);       -- 5
SELECT DATALENGTH(@var); -- 5

-- Khi nào dùng char: dữ liệu có độ dài cố định (mã code, country code)
CREATE TABLE Countries (
    CountryCode CHAR(2) NOT NULL,  -- Luôn đúng 2 ký tự: 'US', 'VN', 'JP'
    PhoneCode   CHAR(4),           -- '+84 ', '+1  '
    CountryName VARCHAR(100) NOT NULL
);

nvarchar vs varchar - Unicode

-- Dùng N prefix để tạo Unicode string literal
INSERT INTO Employees (FullName) VALUES (N'Nguyễn Văn An');  -- Đúng với dấu
INSERT INTO Employees (FullName) VALUES ('Nguyễn Văn An');   -- Có thể sai nếu column là nvarchar

-- Khi nào dùng nvarchar:
-- - Dữ liệu nhiều ngôn ngữ (tiếng Việt, tiếng Trung, Arabic, etc.)
-- - Tên người, địa chỉ
-- - Nội dung do user nhập

-- Khi nào dùng varchar:
-- - Codes, IDs, email addresses (ASCII-safe)
-- - Dữ liệu hệ thống không cần Unicode
-- - Tiết kiệm storage khi biết chắc chỉ dùng ASCII

-- So sánh storage
CREATE TABLE StorageDemo (
    col_varchar  VARCHAR(100)  = 'Hello',
    col_nvarchar NVARCHAR(100) = N'Hello'
);
-- varchar: 5 bytes
-- nvarchar: 10 bytes (2 bytes/ký tự)

varchar(MAX) và nvarchar(MAX)

-- Dùng cho dữ liệu text rất lớn (tới 2GB)
CREATE TABLE Articles (
    ArticleId INT PRIMARY KEY,
    Title     NVARCHAR(500) NOT NULL,
    Content   NVARCHAR(MAX),           -- Nội dung dài
    HtmlContent VARCHAR(MAX)           -- HTML content (ASCII)
);

-- Chú ý hiệu năng với MAX:
-- - Không thể là key trong index
-- - Storage khác: có thể lưu inline (nếu < 8000 bytes) hoặc LOB pages
-- - Dùng .WRITE() để update hiệu quả
UPDATE Articles
SET Content.WRITE(N' Thêm nội dung', DATALENGTH(Content)/2, 0)
WHERE ArticleId = 1;

text và ntext (Deprecated)

-- KHÔNG dùng nữa từ SQL Server 2005+
-- text: tương tự varchar(MAX) nhưng deprecated
-- ntext: tương tự nvarchar(MAX) nhưng deprecated

-- Nếu thấy trong code cũ, convert sang varchar(MAX)/nvarchar(MAX):
ALTER TABLE OldTable ALTER COLUMN OldTextCol NVARCHAR(MAX);

3. Kiểu ngày giờ (Date/Time Types)

-- datetime - loại cũ, tránh dùng cho code mới
DECLARE @dt DATETIME = '2026-04-01 10:30:00.000';

-- datetime2 - khuyến nghị thay datetime
DECLARE @dt2 DATETIME2(7) = '2026-04-01 10:30:00.1234567';  -- 7 decimal seconds
DECLARE @dt2s DATETIME2(0) = '2026-04-01 10:30:00';         -- Chỉ đến giây

-- date - chỉ cần ngày, không cần giờ
DECLARE @d DATE = '2026-04-01';
DECLARE @birthDate DATE = '1990-05-15';

-- time - chỉ cần giờ
DECLARE @t TIME(0) = '10:30:00';     -- Đến giây
DECLARE @t7 TIME(7) = '10:30:00.1234567';  -- Cao nhất

-- datetimeoffset - khi cần lưu timezone
DECLARE @dto DATETIMEOFFSET = '2026-04-01 10:30:00 +07:00';
SELECT SWITCHOFFSET(@dto, '+00:00');  -- Convert sang UTC

-- Ví dụ thực tế
CREATE TABLE Orders (
    OrderId       INT PRIMARY KEY,
    OrderDate     DATE NOT NULL,          -- Chỉ cần ngày
    DeliveryTime  TIME(0),                -- Chỉ cần giờ giao
    CreatedAt     DATETIME2(7) NOT NULL DEFAULT SYSDATETIME(),  -- Timestamp đầy đủ
    UpdatedAt     DATETIME2(7),
    ScheduledAt   DATETIMEOFFSET          -- Nếu có múi giờ
);

-- So sánh datetime vs datetime2
SELECT 
    CAST('2026-04-01' AS DATETIME) AS old_datetime,
    CAST('2026-04-01' AS DATETIME2) AS new_datetime2;
-- datetime: '2026-04-01 00:00:00.000'
-- datetime2: '2026-04-01 00:00:00.0000000'

4. Kiểu nhị phân (Binary Types)

-- Dùng cho: hình ảnh, files, hashes, encrypted data
CREATE TABLE Documents (
    DocumentId    INT PRIMARY KEY,
    FileName      NVARCHAR(255) NOT NULL,
    FileContent   VARBINARY(MAX),                    -- File content
    ContentHash   BINARY(32),                        -- SHA-256 hash (32 bytes)
    Thumbnail     VARBINARY(MAX)
);

-- Lưu hash của password (KHÔNG lưu plain text!)
-- Trong thực tế nên hash ở application layer, không ở SQL

-- HASHBYTES để tạo hash
SELECT HASHBYTES('SHA2_256', N'password123');  -- Trả về varbinary(32)

-- Convert hex string sang binary và ngược lại
SELECT CONVERT(VARCHAR(64), HASHBYTES('SHA2_256', N'test'), 2);  -- Hex string

5. Kiểu đặc biệt

bit

-- bit: 0, 1, hoặc NULL. SQL Server tối ưu lưu 8 bit columns vào 1 byte
CREATE TABLE Settings (
    SettingId  INT PRIMARY KEY,
    IsActive   BIT NOT NULL DEFAULT 1,
    IsDeleted  BIT NOT NULL DEFAULT 0,
    IsPublic   BIT NOT NULL DEFAULT 0,
    HasExpiry  BIT NOT NULL DEFAULT 0
    -- 4 bit columns ở trên dùng chỉ 1 byte storage
);

-- Convert từ string
SELECT CAST('true' AS BIT);   -- Error! BIT không nhận 'true'
SELECT CAST(1 AS BIT);         -- 1
SELECT CAST(0 AS BIT);         -- 0
SELECT IIF(SomeCondition, CAST(1 AS BIT), CAST(0 AS BIT));

uniqueidentifier (GUID)

-- Lưu GUID (128-bit)
CREATE TABLE Sessions (
    SessionId   UNIQUEIDENTIFIER NOT NULL DEFAULT NEWID(),
    UserId      INT NOT NULL,
    CreatedAt   DATETIME2 NOT NULL DEFAULT SYSDATETIME()
);

-- NEWID() - random GUID (gây index fragmentation vì random)
SELECT NEWID();  -- e.g., '6F9619FF-8B86-D011-B42D-00C04FC964FF'

-- NEWSEQUENTIALID() - sequential GUID (dùng làm PK clustered index tốt hơn)
-- Chỉ dùng được trong DEFAULT constraint
CREATE TABLE AuditLogs (
    LogId      UNIQUEIDENTIFIER PRIMARY KEY DEFAULT NEWSEQUENTIALID(),
    Action     NVARCHAR(100),
    CreatedAt  DATETIME2 DEFAULT SYSDATETIME()
);

-- So sánh NEWID() vs NEWSEQUENTIALID()
-- NEWID(): Hoàn toàn random, gây page splits khi INSERT nhiều
-- NEWSEQUENTIALID(): Tăng dần, giảm fragmentation như IDENTITY

-- Convert GUID sang string và ngược lại
DECLARE @id UNIQUEIDENTIFIER = NEWID();
SELECT CAST(@id AS VARCHAR(36));  -- '6F961...'
SELECT CAST('6F9619FF-8B86-D011-B42D-00C04FC964FF' AS UNIQUEIDENTIFIER);

xml

-- Lưu XML data với validation tùy chọn
CREATE TABLE Configurations (
    ConfigId  INT PRIMARY KEY,
    ConfigKey NVARCHAR(100),
    ConfigXml XML  -- Untyped XML
);

-- Insert XML
INSERT INTO Configurations VALUES (1, 'AppSettings', 
    '<settings><timeout>30</timeout><maxRetry>3</maxRetry></settings>');

-- Query XML với XQuery
SELECT 
    ConfigId,
    ConfigXml.value('(/settings/timeout)[1]', 'INT') AS timeout,
    ConfigXml.value('(/settings/maxRetry)[1]', 'INT') AS max_retry
FROM Configurations
WHERE ConfigKey = 'AppSettings';

-- XML methods: value(), query(), nodes(), exist(), modify()
DECLARE @xml XML = '<employees><emp id="1">Alice</emp><emp id="2">Bob</emp></employees>';

SELECT 
    emp.value('@id', 'INT') AS emp_id,
    emp.value('.', 'NVARCHAR(100)') AS emp_name
FROM @xml.nodes('/employees/emp') AS t(emp);

JSON (via OPENJSON - SQL Server 2016+)

-- SQL Server không có native JSON type, dùng NVARCHAR + OPENJSON
-- Validate JSON
SELECT ISJSON('{"name": "Alice", "age": 30}');  -- 1 (valid)
SELECT ISJSON('not json');  -- 0

-- JSON_VALUE - lấy scalar value
DECLARE @json NVARCHAR(MAX) = '{"name": "Alice", "age": 30, "city": "Hanoi"}';
SELECT JSON_VALUE(@json, '$.name');  -- 'Alice'
SELECT JSON_VALUE(@json, '$.age');   -- '30'

-- JSON_QUERY - lấy object hoặc array
DECLARE @json2 NVARCHAR(MAX) = '{"person": {"name": "Alice", "skills": ["SQL", "C#"]}}';
SELECT JSON_QUERY(@json2, '$.person');         -- '{"name": "Alice", "skills": [...]}'
SELECT JSON_QUERY(@json2, '$.person.skills');  -- '["SQL", "C#"]'

-- OPENJSON - parse JSON thành rows
SELECT *
FROM OPENJSON('{"orders": [{"id":1,"total":100}, {"id":2,"total":200}]}', '$.orders')
WITH (
    order_id    INT           '$.id',
    order_total DECIMAL(10,2) '$.total'
);

-- FOR JSON - convert query result sang JSON
SELECT EmployeeId, FullName, Salary
FROM Employees
FOR JSON AUTO;

SELECT EmployeeId, FullName, Salary
FROM Employees
FOR JSON PATH, ROOT('employees');

sql_variant

-- Có thể lưu nhiều kiểu dữ liệu khác nhau (tránh dùng nếu có thể)
DECLARE @v SQL_VARIANT;
SET @v = 42;
SELECT @v, SQL_VARIANT_PROPERTY(@v, 'BaseType');  -- 'int'
SET @v = 'Hello';
SELECT @v, SQL_VARIANT_PROPERTY(@v, 'BaseType');  -- 'varchar'

rowversion / timestamp

-- Tự động tăng khi row được INSERT/UPDATE, dùng cho optimistic concurrency
CREATE TABLE Products (
    ProductId   INT PRIMARY KEY,
    ProductName NVARCHAR(200),
    Price       DECIMAL(10,2),
    RowVer      ROWVERSION NOT NULL  -- Tự cập nhật, 8 bytes
);

-- timestamp là synonym của rowversion (deprecated alias)
-- Dùng để detect concurrency conflicts
SELECT ProductId, ProductName, CAST(RowVer AS BIGINT) AS version
FROM Products;

6. Unicode vs Non-Unicode

-- N prefix tạo Unicode literal
SELECT 'Xin chào';        -- Mất dấu nếu collation không hỗ trợ
SELECT N'Xin chào';       -- Unicode, luôn đúng

-- Collation ảnh hưởng đến sorting và comparison
SELECT * FROM sys.fn_helpcollations() WHERE name LIKE 'Vietnamese%';

-- Khai báo explicit collation
CREATE TABLE MultiLanguage (
    NameEn NVARCHAR(200) COLLATE Latin1_General_CI_AS,
    NameVn NVARCHAR(200) COLLATE Vietnamese_CI_AS
);

-- So sánh cross-collation cần COLLATE trong query
SELECT * FROM t1
JOIN t2 ON t1.Name = t2.Name COLLATE SQL_Latin1_General_CP1_CI_AS;

7. Implicit vs Explicit Conversion

CAST vs CONVERT vs TRY_CAST vs TRY_CONVERT

-- CAST - chuẩn ANSI SQL
SELECT CAST(42 AS VARCHAR(10));         -- '42'
SELECT CAST('2026-04-01' AS DATE);      -- 2026-04-01
SELECT CAST(3.14 AS INT);              -- 3 (truncation)

-- CONVERT - SQL Server specific, hỗ trợ format code cho ngày
SELECT CONVERT(VARCHAR(10), GETDATE(), 103);  -- '01/04/2026' (dd/mm/yyyy)
SELECT CONVERT(VARCHAR(10), GETDATE(), 120);  -- '2026-04-01' (yyyy-mm-dd)
SELECT CONVERT(VARCHAR(8),  GETDATE(), 112);  -- '20260401' (yyyymmdd)
SELECT CONVERT(INT, '42');

-- TRY_CAST - trả về NULL thay vì error nếu convert thất bại
SELECT TRY_CAST('abc' AS INT);          -- NULL (không báo lỗi)
SELECT TRY_CAST('42' AS INT);           -- 42

-- TRY_CONVERT - tương tự TRY_CAST với format code
SELECT TRY_CONVERT(DATE, '2026-13-01'); -- NULL (tháng 13 không tồn tại)
SELECT TRY_CONVERT(DATE, '2026-04-01'); -- 2026-04-01

-- Implicit conversion - SQL Server tự convert (CÓ THỂ GÂY VẤN ĐỀ!)
SELECT * FROM Employees WHERE EmployeeId = '42';
-- SQL Server convert '42' sang INT: OK nhưng có thể ảnh hưởng performance

-- Implicit conversion GÂY VẤN ĐỀ với indexes:
-- Nếu column là VARCHAR và bạn so sánh với INT, SQL Server phải convert TỪNG GIÁ TRỊ TRONG TABLE
-- -> Index không được dùng -> Table scan!
SELECT * FROM Employees WHERE VarcharId = 42;  -- BAD: convert mỗi row
SELECT * FROM Employees WHERE VarcharId = '42'; -- GOOD: dùng index

-- Kiểm tra implicit conversion với execution plan:
-- Tìm "CONVERT_IMPLICIT" trong execution plan để phát hiện vấn đề

Bảng Conversion

8. Data Type Best Practices

-- 1. Chọn kiểu nhỏ nhất phù hợp
-- BAD: dùng BIGINT cho tất cả
CREATE TABLE BadDesign (OrderId BIGINT, Status BIGINT, YearsExp BIGINT);

-- GOOD: chọn đúng kích thước
CREATE TABLE GoodDesign (
    OrderId   INT      NOT NULL,  -- Đủ cho hầu hết use cases
    Status    TINYINT  NOT NULL,  -- 0-255 là đủ cho status
    YearsExp  TINYINT  NOT NULL   -- 0-120 năm kinh nghiệm
);

-- 2. Không dùng float/real cho tiền tệ
-- BAD:
CREATE TABLE BadMoney (Price FLOAT);  -- Sai về độ chính xác!

-- GOOD:
CREATE TABLE GoodMoney (Price DECIMAL(19, 4));  -- Chính xác

-- 3. Luôn dùng nvarchar cho user-input text trong ứng dụng đa ngôn ngữ
CREATE TABLE UserProfiles (
    UserId    INT           PRIMARY KEY,
    UserName  VARCHAR(50)   NOT NULL,       -- Username: ASCII-safe
    FullName  NVARCHAR(200) NOT NULL,       -- Tên: cần Unicode
    Email     VARCHAR(320)  NOT NULL,       -- Email: ASCII-safe
    Bio       NVARCHAR(MAX)                 -- Bio: user input
);

-- 4. Dùng DATE thay DATETIME khi không cần time component
-- BAD: lưu ngày sinh với DATETIME
CREATE TABLE BadDates (BirthDate DATETIME);  -- Lưu '1990-05-15 00:00:00.000'

-- GOOD:
CREATE TABLE GoodDates (BirthDate DATE);  -- Chỉ '1990-05-15', tiết kiệm 5 bytes/row

-- 5. Dùng DATETIME2 thay DATETIME cho timestamps mới
-- datetime: range 1753+, precision 3.33ms, 8 bytes
-- datetime2: range 0001+, precision 100ns, 6-8 bytes
CREATE TABLE AuditLog (
    CreatedAt DATETIME2(7) NOT NULL DEFAULT SYSDATETIME()
);

-- 6. Tránh varchar(MAX) khi biết trước giới hạn
-- BAD: dùng MAX cho mọi thứ
CREATE TABLE BadVarchar (Name NVARCHAR(MAX), Code NVARCHAR(MAX));

-- GOOD: giới hạn phù hợp
CREATE TABLE GoodVarchar (
    Name NVARCHAR(200),    -- Tên người
    Code NVARCHAR(20),     -- Mã code ngắn
    Description NVARCHAR(2000),  -- Mô tả
    Content NVARCHAR(MAX)  -- Nội dung thực sự cần MAX
);

-- 7. NULL vs NOT NULL
-- Tránh allow NULL trừ khi thực sự cần thiết về mặt business logic
-- NULL gây phức tạp trong queries và có thể ảnh hưởng index efficiency

Bảng tổng hợp chọn kiểu dữ liệu

DDL - Data Definition Language

DDL (Data Definition Language) là tập hợp các câu lệnh SQL dùng để tạo, thay đổi, và xóa cấu trúc database objects (database, table, index, schema, v.v.). Các câu lệnh DDL chính: CREATE, ALTER, DROP, TRUNCATE.

1. Database Objects

CREATE DATABASE

-- Tạo database đơn giản
CREATE DATABASE SalesDB;

-- Tạo database với cấu hình chi tiết
CREATE DATABASE SalesDB
ON PRIMARY (
    NAME = 'SalesDB',                          -- Logical name
    FILENAME = 'D:\Data\SalesDB.mdf',          -- Physical file path
    SIZE = 1024 MB,                            -- Initial size
    MAXSIZE = 10240 MB,                        -- Maximum size
    FILEGROWTH = 512 MB                        -- Auto-growth increment
)
LOG ON (
    NAME = 'SalesDB_log',
    FILENAME = 'D:\Logs\SalesDB_log.ldf',
    SIZE = 256 MB,
    MAXSIZE = 4096 MB,
    FILEGROWTH = 128 MB
);

-- Sử dụng database
USE SalesDB;
GO

-- Xem danh sách databases
SELECT name, state_desc, recovery_model_desc, compatibility_level
FROM sys.databases
ORDER BY name;

ALTER DATABASE

-- Thay đổi recovery model
ALTER DATABASE SalesDB SET RECOVERY SIMPLE;
ALTER DATABASE SalesDB SET RECOVERY FULL;
ALTER DATABASE SalesDB SET RECOVERY BULK_LOGGED;

-- Thay đổi compatibility level
ALTER DATABASE SalesDB SET COMPATIBILITY_LEVEL = 160;  -- SQL Server 2022

-- Thêm data file vào filegroup
ALTER DATABASE SalesDB
ADD FILE (
    NAME = 'SalesDB_data2',
    FILENAME = 'D:\Data\SalesDB_data2.ndf',
    SIZE = 512 MB,
    FILEGROWTH = 256 MB
) TO FILEGROUP [PRIMARY];

-- Đặt database thành READ-ONLY
ALTER DATABASE SalesDB SET READ_ONLY;
ALTER DATABASE SalesDB SET READ_WRITE;

-- Đổi tên database
ALTER DATABASE SalesDB MODIFY NAME = SalesDatabase;

DROP DATABASE

-- Xóa database (KHÔNG THỂ HOÀN TÁC!)
DROP DATABASE SalesDB;

-- An toàn hơn: kiểm tra trước khi xóa
IF EXISTS (SELECT 1 FROM sys.databases WHERE name = 'SalesDB')
    DROP DATABASE SalesDB;

-- SQL Server 2016+
DROP DATABASE IF EXISTS SalesDB;

2. Tables (Bảng dữ liệu)

CREATE TABLE - Cơ bản

-- Cú pháp đầy đủ
CREATE TABLE Employees (
    -- Integer types
    EmployeeId    INT             NOT NULL,
    DepartmentId  INT             NULL,
    
    -- String types  
    FirstName     NVARCHAR(100)   NOT NULL,
    LastName      NVARCHAR(100)   NOT NULL,
    Email         VARCHAR(320)    NOT NULL,
    Phone         VARCHAR(20)     NULL,
    
    -- Numeric
    Salary        DECIMAL(15, 2)  NOT NULL DEFAULT 0,
    
    -- Date types
    BirthDate     DATE            NULL,
    HireDate      DATE            NOT NULL DEFAULT CAST(GETDATE() AS DATE),
    CreatedAt     DATETIME2(7)    NOT NULL DEFAULT SYSDATETIME(),
    UpdatedAt     DATETIME2(7)    NULL,
    
    -- Boolean
    IsActive      BIT             NOT NULL DEFAULT 1,
    
    -- Constraints (inline)
    CONSTRAINT PK_Employees PRIMARY KEY (EmployeeId),
    CONSTRAINT FK_Employees_Departments FOREIGN KEY (DepartmentId)
        REFERENCES Departments(DepartmentId),
    CONSTRAINT UQ_Employees_Email UNIQUE (Email),
    CONSTRAINT CHK_Employees_Salary CHECK (Salary >= 0),
    CONSTRAINT CHK_Employees_BirthDate CHECK (BirthDate IS NULL OR BirthDate < CAST(GETDATE() AS DATE))
);

Các loại Constraints

PRIMARY KEY

-- Column-level (single column)
CREATE TABLE Orders (
    OrderId INT NOT NULL CONSTRAINT PK_Orders PRIMARY KEY,
    ...
);

-- Hoặc viết ngắn gọn
CREATE TABLE Orders (
    OrderId INT PRIMARY KEY,
    ...
);

-- Table-level (composite key)
CREATE TABLE OrderDetails (
    OrderId    INT NOT NULL,
    ProductId  INT NOT NULL,
    Quantity   INT NOT NULL,
    UnitPrice  DECIMAL(10,2) NOT NULL,
    
    CONSTRAINT PK_OrderDetails PRIMARY KEY (OrderId, ProductId)
    -- Composite PK phải dùng table-level constraint
);

FOREIGN KEY

CREATE TABLE Orders (
    OrderId      INT  PRIMARY KEY,
    CustomerId   INT  NOT NULL,
    EmployeeId   INT  NULL,
    
    -- Column-level FK
    CustomerId INT REFERENCES Customers(CustomerId),
    
    -- Table-level FK với đặt tên rõ ràng (khuyến nghị)
    CONSTRAINT FK_Orders_Customers FOREIGN KEY (CustomerId)
        REFERENCES Customers(CustomerId)
        ON DELETE NO ACTION    -- Không xóa cascading
        ON UPDATE CASCADE,     -- Tự cập nhật khi Customer PK thay đổi
    
    CONSTRAINT FK_Orders_Employees FOREIGN KEY (EmployeeId)
        REFERENCES Employees(EmployeeId)
        ON DELETE SET NULL     -- Đặt NULL khi Employee bị xóa
        ON UPDATE CASCADE
);

UNIQUE Constraint

CREATE TABLE Users (
    UserId    INT  PRIMARY KEY,
    Username  NVARCHAR(50) NOT NULL,
    Email     VARCHAR(320) NOT NULL,
    SSN       CHAR(9) NULL,
    
    -- Single column unique
    CONSTRAINT UQ_Users_Username UNIQUE (Username),
    CONSTRAINT UQ_Users_Email UNIQUE (Email),
    
    -- Composite unique (NULL values được phép - nhiều NULLs không vi phạm UNIQUE)
    CONSTRAINT UQ_Users_SSN UNIQUE (SSN)
);

-- Filtered unique index (SQL Server) - unique chỉ với non-NULL values
CREATE UNIQUE INDEX UX_Users_SSN_NotNull 
ON Users (SSN) 
WHERE SSN IS NOT NULL;

CHECK Constraint

CREATE TABLE Products (
    ProductId   INT PRIMARY KEY,
    ProductName NVARCHAR(200) NOT NULL,
    Price       DECIMAL(10,2) NOT NULL,
    Stock       INT           NOT NULL,
    Category    NVARCHAR(50)  NOT NULL,
    Status      CHAR(1)       NOT NULL DEFAULT 'A',
    
    CONSTRAINT CHK_Products_Price   CHECK (Price > 0),
    CONSTRAINT CHK_Products_Stock   CHECK (Stock >= 0),
    CONSTRAINT CHK_Products_Status  CHECK (Status IN ('A', 'I', 'D')),  -- Active, Inactive, Discontinued
    CONSTRAINT CHK_Products_Name    CHECK (LEN(ProductName) >= 2)
);

DEFAULT Constraint

CREATE TABLE AuditLog (
    LogId       INT        PRIMARY KEY,
    TableName   NVARCHAR(128) NOT NULL,
    Action      CHAR(1)       NOT NULL,
    
    -- Default values
    CreatedAt   DATETIME2(7)  NOT NULL CONSTRAINT DF_AuditLog_CreatedAt DEFAULT SYSDATETIME(),
    CreatedBy   NVARCHAR(128) NOT NULL CONSTRAINT DF_AuditLog_CreatedBy DEFAULT SUSER_SNAME(),
    IsProcessed BIT           NOT NULL CONSTRAINT DF_AuditLog_IsProcessed DEFAULT 0,
    
    CONSTRAINT CHK_AuditLog_Action CHECK (Action IN ('I', 'U', 'D'))
);

3. ALTER TABLE

-- Thêm column mới
ALTER TABLE Employees ADD MiddleName NVARCHAR(100) NULL;

-- Thêm column với DEFAULT (cho rows hiện có)
ALTER TABLE Employees ADD 
    CreatedBy NVARCHAR(128) NOT NULL DEFAULT SUSER_SNAME(),
    IsDeleted BIT NOT NULL DEFAULT 0;

-- Thay đổi kiểu dữ liệu của column
ALTER TABLE Employees ALTER COLUMN Phone VARCHAR(30) NULL;
-- Chú ý: không thể ALTER column nếu có INDEX hoặc CONSTRAINT trên column đó

-- Xóa column
ALTER TABLE Employees DROP COLUMN MiddleName;

-- Thêm constraint
ALTER TABLE Employees 
    ADD CONSTRAINT CHK_Employees_Email CHECK (Email LIKE '%@%.%');

ALTER TABLE Employees 
    ADD CONSTRAINT FK_Employees_Departments 
    FOREIGN KEY (DepartmentId) REFERENCES Departments(DepartmentId);

-- Xóa constraint
ALTER TABLE Employees DROP CONSTRAINT CHK_Employees_Email;
ALTER TABLE Employees DROP CONSTRAINT FK_Employees_Departments;

-- Xóa default constraint
ALTER TABLE Employees DROP CONSTRAINT DF_Employees_CreatedAt;

-- Disable / Enable constraint tạm thời
ALTER TABLE Employees NOCHECK CONSTRAINT FK_Employees_Departments;
ALTER TABLE Employees CHECK CONSTRAINT FK_Employees_Departments;

-- Xóa bảng (KHÔNG THỂ HOÀN TÁC)
DROP TABLE IF EXISTS Employees;
DROP TABLE Employees;  -- Lỗi nếu table không tồn tại

4. Schemas (Lược đồ)

Schema là namespace logic để nhóm các database objects:

-- Tạo schema
CREATE SCHEMA Hr AUTHORIZATION dbo;
CREATE SCHEMA Sales;
CREATE SCHEMA Finance;

-- Tạo table trong schema
CREATE TABLE Hr.Employees (...);
CREATE TABLE Sales.Orders (...);
CREATE TABLE Finance.Invoices (...);

-- Move table sang schema khác
ALTER SCHEMA Sales TRANSFER dbo.OldOrdersTable;

-- Xem các schemas
SELECT schema_id, name, principal_id
FROM sys.schemas
ORDER BY name;

-- Xem objects trong schema
SELECT 
    s.name AS schema_name,
    o.name AS object_name,
    o.type_desc
FROM sys.objects o
JOIN sys.schemas s ON o.schema_id = s.schema_id
WHERE o.type IN ('U', 'V', 'P')  -- Tables, Views, Stored Procedures
ORDER BY s.name, o.name;

-- Drop schema (phải empty trước)
DROP SCHEMA Finance;

Best Practice: Dùng schemas để:

• Phân tách theo domain: Hr, Sales, Finance
• Phân quyền theo nhóm: GRANT trên schema thay vì từng table
• Tránh naming conflicts

5. Identity Columns và Sequences

IDENTITY

-- IDENTITY(seed, increment)
CREATE TABLE Products (
    ProductId   INT IDENTITY(1, 1) PRIMARY KEY,  -- Bắt đầu từ 1, tăng 1
    ProductName NVARCHAR(200) NOT NULL
);

-- INSERT không cần specify ProductId
INSERT INTO Products (ProductName) VALUES ('Widget A');
INSERT INTO Products (ProductName) VALUES ('Widget B');

-- Lấy giá trị IDENTITY vừa insert
SELECT SCOPE_IDENTITY();   -- Khuyến nghị: chỉ trong scope hiện tại
SELECT @@IDENTITY;          -- Trả về identity của lần INSERT cuối trong session (kể cả trigger)
SELECT IDENT_CURRENT('Products');  -- Identity hiện tại của table

-- INSERT với IDENTITY_INSERT ON (khi cần insert giá trị cụ thể)
SET IDENTITY_INSERT Products ON;
INSERT INTO Products (ProductId, ProductName) VALUES (100, 'Special Item');
SET IDENTITY_INSERT Products OFF;

-- Reset IDENTITY
DBCC CHECKIDENT ('Products', RESEED, 0);  -- Reset về 0, next insert = 1

-- Xem thông tin IDENTITY
SELECT 
    name AS column_name,
    seed_value,
    increment_value,
    last_value
FROM sys.identity_columns
WHERE object_id = OBJECT_ID('Products');

NEWID() và NEWSEQUENTIALID()

-- NEWID(): Random GUID - BAD cho clustered PK vì gây fragmentation
CREATE TABLE Sessions_Bad (
    SessionId UNIQUEIDENTIFIER PRIMARY KEY DEFAULT NEWID(),  -- Random, gây page splits
    UserId    INT
);

-- NEWSEQUENTIALID(): Sequential GUID - tốt hơn cho clustered PK
CREATE TABLE Sessions_Good (
    SessionId UNIQUEIDENTIFIER PRIMARY KEY DEFAULT NEWSEQUENTIALID(),  -- Sequential
    UserId    INT
);
-- Lưu ý: NEWSEQUENTIALID() chỉ dùng được trong DEFAULT constraint
-- Không gọi trực tiếp trong query được

-- Tại sao NEWID() gây vấn đề?
-- Mỗi INSERT có thể xen vào giữa các pages hiện có
-- -> Page splits -> Fragmentation -> Hiệu năng giảm

CREATE SEQUENCE

-- SEQUENCE là đối tượng độc lập, linh hoạt hơn IDENTITY
CREATE SEQUENCE dbo.OrderIdSeq
    START WITH 1000
    INCREMENT BY 1
    MINVALUE 1000
    MAXVALUE 9999999
    NO CYCLE                    -- Không quay lại từ đầu khi đến max
    CACHE 50;                   -- Cache 50 giá trị để tăng hiệu năng

-- Sử dụng SEQUENCE
INSERT INTO Orders (OrderId, CustomerId)
VALUES (NEXT VALUE FOR dbo.OrderIdSeq, 42);

-- Dùng trong DEFAULT
CREATE TABLE Orders (
    OrderId    INT DEFAULT (NEXT VALUE FOR dbo.OrderIdSeq),
    CustomerId INT,
    OrderDate  DATE DEFAULT GETDATE()
);

-- Xem giá trị hiện tại
SELECT current_value FROM sys.sequences WHERE name = 'OrderIdSeq';

-- Đặt lại SEQUENCE
ALTER SEQUENCE dbo.OrderIdSeq RESTART WITH 1000;

-- Ưu điểm SEQUENCE vs IDENTITY:
-- - Có thể dùng cho nhiều tables
-- - Có thể lấy giá trị trước khi INSERT (cho audit, logging)
-- - Hỗ trợ cycle
-- - Linh hoạt về min/max/increment

DECLARE @nextId INT = NEXT VALUE FOR dbo.OrderIdSeq;
-- Bây giờ có thể dùng @nextId trước khi INSERT

6. Computed Columns

-- Non-persisted computed column (tính lại mỗi khi query)
CREATE TABLE Rectangles (
    RectId  INT PRIMARY KEY,
    Width   DECIMAL(10,2) NOT NULL,
    Height  DECIMAL(10,2) NOT NULL,
    
    -- Tính toán mỗi lần query
    Area    AS (Width * Height),
    
    -- Persisted: lưu kết quả vào disk, tính lại khi INSERT/UPDATE
    Perimeter AS (2 * (Width + Height)) PERSISTED
);

-- Ví dụ thực tế
CREATE TABLE OrderDetails (
    OrderDetailId INT PRIMARY KEY,
    Quantity      INT            NOT NULL,
    UnitPrice     DECIMAL(10,2)  NOT NULL,
    Discount      DECIMAL(5,4)   NOT NULL DEFAULT 0,
    
    -- Non-persisted
    SubTotal AS (Quantity * UnitPrice),
    
    -- Persisted - có thể tạo index trên persisted computed column
    NetAmount AS (Quantity * UnitPrice * (1 - Discount)) PERSISTED
);

-- Index trên persisted computed column
CREATE INDEX IX_OrderDetails_NetAmount ON OrderDetails (NetAmount);

-- Xem computed columns
SELECT 
    name,
    definition,
    is_persisted
FROM sys.computed_columns
WHERE object_id = OBJECT_ID('OrderDetails');

7. Temporal Tables (System-Versioned)

Temporal tables tự động lưu lịch sử thay đổi dữ liệu:

-- Tạo temporal table
CREATE TABLE Employees (
    EmployeeId    INT             NOT NULL CONSTRAINT PK_Employees PRIMARY KEY,
    FullName      NVARCHAR(200)   NOT NULL,
    Salary        DECIMAL(15,2)   NOT NULL,
    DepartmentId  INT             NULL,
    
    -- Bắt buộc: 2 datetime2 columns cho period
    ValidFrom     DATETIME2(7)    GENERATED ALWAYS AS ROW START NOT NULL,
    ValidTo       DATETIME2(7)    GENERATED ALWAYS AS ROW END   NOT NULL,
    
    PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH (SYSTEM_VERSIONING = ON (  
    HISTORY_TABLE = dbo.EmployeesHistory  -- SQL Server tự tạo history table
));

-- INSERT/UPDATE/DELETE hoạt động bình thường
UPDATE Employees SET Salary = 75000 WHERE EmployeeId = 1;
-- Row cũ tự động chuyển vào EmployeesHistory

-- Query dữ liệu lịch sử
-- Lấy dữ liệu tại một thời điểm cụ thể
SELECT * FROM Employees
FOR SYSTEM_TIME AS OF '2025-01-01 00:00:00';

-- Lấy tất cả versions trong khoảng thời gian
SELECT * FROM Employees
FOR SYSTEM_TIME BETWEEN '2025-01-01' AND '2026-01-01';

-- Lấy tất cả versions từng tồn tại trong khoảng
SELECT * FROM Employees
FOR SYSTEM_TIME FROM '2025-01-01' TO '2026-01-01';

-- Tất cả versions kể cả đã bị xóa
SELECT * FROM Employees
FOR SYSTEM_TIME ALL;

-- Xem history table
SELECT * FROM dbo.EmployeesHistory WHERE EmployeeId = 1 ORDER BY ValidFrom;

-- Tắt system versioning (để có thể DROP table)
ALTER TABLE Employees SET (SYSTEM_VERSIONING = OFF);
DROP TABLE dbo.EmployeesHistory;
DROP TABLE dbo.Employees;

8. Table Constraints vs Column Constraints

-- Column-level constraint (đặt ngay sau column definition)
CREATE TABLE Example (
    Col1 INT NOT NULL PRIMARY KEY,           -- Column constraint
    Col2 INT REFERENCES OtherTable(Id),      -- Inline FK
    Col3 INT CHECK (Col3 > 0),              -- Inline CHECK
    Col4 INT DEFAULT 42                      -- Inline DEFAULT
);

-- Table-level constraint (đặt sau tất cả columns)
CREATE TABLE Example (
    Col1 INT NOT NULL,
    Col2 INT,
    Col3 INT,
    Col4 INT,
    
    CONSTRAINT PK_Example PRIMARY KEY (Col1),             -- Named PK
    CONSTRAINT FK_Example_OtherTable FOREIGN KEY (Col2)   -- Named FK
        REFERENCES OtherTable(Id),
    CONSTRAINT CHK_Example_Col3 CHECK (Col3 > 0),         -- Named CHECK
    CONSTRAINT UQ_Example_Col3_Col4 UNIQUE (Col3, Col4)   -- Composite UNIQUE
);

-- PHẢI dùng table-level constraint khi:
-- 1. Composite PRIMARY KEY
-- 2. Composite UNIQUE
-- 3. Composite FOREIGN KEY (hiếm)
-- 4. Muốn đặt tên cho constraint (khuyến nghị)

-- Xem tất cả constraints của table
SELECT 
    cc.name AS constraint_name,
    cc.type_desc,
    cc.definition
FROM sys.check_constraints cc
WHERE OBJECT_NAME(cc.parent_object_id) = 'Example'

UNION ALL

SELECT 
    dc.name,
    'DEFAULT_CONSTRAINT',
    dc.definition
FROM sys.default_constraints dc
WHERE OBJECT_NAME(dc.parent_object_id) = 'Example';

9. Cascading Actions

-- ON DELETE / ON UPDATE options:
-- NO ACTION  - Mặc định. Báo lỗi nếu có FK references
-- CASCADE    - Tự xóa/cập nhật rows con
-- SET NULL   - Đặt FK = NULL khi parent bị xóa/cập nhật
-- SET DEFAULT - Đặt FK = DEFAULT value khi parent bị xóa/cập nhật
-- RESTRICT   - Tương tự NO ACTION (ANSI standard, không dùng trong SQL Server)

CREATE TABLE Departments (
    DepartmentId INT PRIMARY KEY,
    Name         NVARCHAR(100) NOT NULL
);

CREATE TABLE Employees (
    EmployeeId    INT PRIMARY KEY,
    DepartmentId  INT NOT NULL,
    ManagerId     INT NULL,
    
    -- CASCADE: xóa Dept -> xóa tất cả employees của dept đó
    CONSTRAINT FK_Employees_Departments FOREIGN KEY (DepartmentId)
        REFERENCES Departments(DepartmentId)
        ON DELETE CASCADE
        ON UPDATE CASCADE,
    
    -- SET NULL: xóa Manager -> ManagerId = NULL
    CONSTRAINT FK_Employees_Manager FOREIGN KEY (ManagerId)
        REFERENCES Employees(EmployeeId)
        ON DELETE SET NULL
        ON UPDATE NO ACTION
);

-- Lưu ý: SQL Server KHÔNG cho phép circular cascade
-- Và không cho phép multiple cascade paths đến cùng 1 table
-- Ví dụ: Orders -> Customers (ON DELETE CASCADE) 
--        Orders -> Employees (ON DELETE CASCADE)
--        Nếu thêm Customers -> Employees (ON DELETE CASCADE) -> ERROR: multiple cascade paths

-- Ví dụ ON DELETE SET DEFAULT
CREATE TABLE Tickets (
    TicketId    INT PRIMARY KEY,
    AssignedTo  INT NOT NULL DEFAULT 0,  -- 0 = Unassigned
    
    CONSTRAINT FK_Tickets_Users FOREIGN KEY (AssignedTo)
        REFERENCES Users(UserId)
        ON DELETE SET DEFAULT  -- Khi User bị xóa, ticket về trạng thái unassigned
        ON UPDATE CASCADE
);

10. Indexes trong DDL

-- CLUSTERED INDEX: Sắp xếp vật lý dữ liệu (mỗi table chỉ có 1)
-- PRIMARY KEY mặc định là clustered
CREATE TABLE Orders (
    OrderId INT NOT NULL,
    OrderDate DATE NOT NULL,
    CustomerId INT,
    
    CONSTRAINT PK_Orders PRIMARY KEY CLUSTERED (OrderId)
);

-- Nếu muốn PK non-clustered và tạo clustered index trên column khác
CREATE TABLE Orders (
    OrderId INT NOT NULL,
    OrderDate DATE NOT NULL,
    CustomerId INT,
    
    CONSTRAINT PK_Orders PRIMARY KEY NONCLUSTERED (OrderId)
);

CREATE CLUSTERED INDEX CIX_Orders_OrderDate ON Orders (OrderDate);
-- Clustered trên OrderDate -> data pages sắp xếp theo OrderDate

-- NONCLUSTERED INDEX (mặc định khi tạo CREATE INDEX)
CREATE NONCLUSTERED INDEX IX_Orders_CustomerId 
ON Orders (CustomerId)
INCLUDE (OrderDate, TotalAmount);  -- INCLUDE: đưa thêm columns vào leaf node

-- UNIQUE INDEX
CREATE UNIQUE INDEX UX_Employees_Email ON Employees (Email);
-- Khác với UNIQUE CONSTRAINT: index có thể hỗ trợ INCLUDE columns

-- FILTERED INDEX - index chỉ trên subset rows
CREATE NONCLUSTERED INDEX IX_Employees_ActiveSalary
ON Employees (Salary)
WHERE IsActive = 1;  -- Chỉ index active employees

-- COMPOSITE INDEX
CREATE INDEX IX_Orders_CustomerDate 
ON Orders (CustomerId, OrderDate DESC)
INCLUDE (TotalAmount, Status);

-- Xem indexes của table
SELECT 
    i.name AS index_name,
    i.type_desc,
    i.is_unique,
    STRING_AGG(c.name, ', ') WITHIN GROUP (ORDER BY ic.key_ordinal) AS key_columns
FROM sys.indexes i
JOIN sys.index_columns ic ON i.object_id = ic.object_id AND i.index_id = ic.index_id
JOIN sys.columns c ON ic.object_id = c.object_id AND ic.column_id = c.column_id
WHERE i.object_id = OBJECT_ID('Orders')
    AND ic.is_included_column = 0
GROUP BY i.name, i.type_desc, i.is_unique;

-- DROP INDEX
DROP INDEX IX_Orders_CustomerId ON Orders;

DML - Data Manipulation Language

DML (Data Manipulation Language) là tập hợp các câu lệnh SQL dùng để thêm, cập nhật, xóa, và đọc dữ liệu trong các tables. Các câu lệnh DML chính: INSERT, UPDATE, DELETE, MERGE, SELECT.

1. INSERT

INSERT cơ bản

-- Chỉ định tên columns (khuyến nghị - luôn làm vậy)
INSERT INTO Employees (FirstName, LastName, Email, DepartmentId, Salary, HireDate)
VALUES ('Nguyen', 'Van An', 'nvan.an@company.com', 3, 50000, '2026-01-15');

-- Không chỉ định columns (nguy hiểm - phụ thuộc vào column order)
INSERT INTO Employees
VALUES (NULL, 'Nguyen', 'Van An', 'nvan.an@company.com', NULL, 50000, '2026-01-15', 1);

-- INSERT và lấy lại ID vừa tạo
DECLARE @newId INT;
INSERT INTO Employees (FirstName, LastName, Email, DepartmentId, Salary)
VALUES ('Tran', 'Thi B', 'tthi.b@company.com', 2, 45000);
SET @newId = SCOPE_IDENTITY();
SELECT @newId;  -- Lấy IDENTITY value vừa insert

Multi-row INSERT

-- INSERT nhiều rows cùng lúc (SQL Server 2008+) - hiệu quả hơn nhiều lần INSERT
INSERT INTO Products (ProductName, Price, CategoryId, Stock)
VALUES 
    ('Widget A',  19.99, 1, 100),
    ('Widget B',  29.99, 1, 200),
    ('Gadget X',  49.99, 2, 50),
    ('Gadget Y',  79.99, 2, 75),
    ('Service Z', 99.99, 3, NULL);

-- Tối đa một VALUES clause có thể có 1000 rows

INSERT INTO…SELECT

-- Sao chép dữ liệu từ table khác
INSERT INTO EmployeesArchive (EmployeeId, FullName, Salary, ArchivedAt)
SELECT EmployeeId, FirstName + ' ' + LastName, Salary, SYSDATETIME()
FROM Employees
WHERE IsActive = 0 AND HireDate < '2020-01-01';

-- INSERT từ nhiều tables với JOIN
INSERT INTO OrderSummary (OrderId, CustomerName, TotalAmount, OrderDate)
SELECT 
    o.OrderId,
    c.FirstName + ' ' + c.LastName,
    SUM(od.Quantity * od.UnitPrice),
    o.OrderDate
FROM Orders o
JOIN Customers c ON o.CustomerId = c.CustomerId
JOIN OrderDetails od ON o.OrderId = od.OrderId
WHERE o.OrderDate >= '2026-01-01'
GROUP BY o.OrderId, c.FirstName, c.LastName, o.OrderDate;

-- INSERT với CTE
WITH NewHires AS (
    SELECT EmployeeId, FirstName, LastName, DepartmentId
    FROM Employees
    WHERE HireDate >= DATEADD(MONTH, -3, GETDATE())
)
INSERT INTO NewHireReport (EmployeeId, FullName, DeptName)
SELECT 
    nh.EmployeeId,
    nh.FirstName + ' ' + nh.LastName,
    d.DepartmentName
FROM NewHires nh
JOIN Departments d ON nh.DepartmentId = d.DepartmentId;

OUTPUT clause với INSERT

-- OUTPUT: capture rows bị ảnh hưởng
-- INSERTED table: rows được INSERT
-- DELETED table: rows bị DELETE

-- Lấy lại tất cả rows vừa INSERT
INSERT INTO Employees (FirstName, LastName, Email, Salary)
OUTPUT 
    INSERTED.EmployeeId,
    INSERTED.FirstName,
    INSERTED.LastName,
    INSERTED.CreatedAt
VALUES 
    ('Alice', 'Smith', 'alice@co.com', 60000),
    ('Bob',   'Jones', 'bob@co.com',   55000);

-- Lưu OUTPUT vào table khác
DECLARE @InsertedRows TABLE (
    EmployeeId INT,
    FullName   NVARCHAR(200),
    InsertedAt DATETIME2
);

INSERT INTO Employees (FirstName, LastName, Email, Salary)
OUTPUT 
    INSERTED.EmployeeId,
    INSERTED.FirstName + ' ' + INSERTED.LastName,
    INSERTED.CreatedAt
INTO @InsertedRows (EmployeeId, FullName, InsertedAt)
VALUES ('Charlie', 'Brown', 'charlie@co.com', 52000);

SELECT * FROM @InsertedRows;

2. UPDATE

UPDATE cơ bản

-- UPDATE với WHERE (LUÔN kiểm tra WHERE trước khi chạy!)
UPDATE Employees
SET Salary = Salary * 1.10,          -- Tăng 10%
    UpdatedAt = SYSDATETIME()
WHERE DepartmentId = 3
  AND IsActive = 1;

-- Update nhiều columns
UPDATE Products
SET 
    Price       = Price * 0.9,        -- Giảm 10%
    IsOnSale    = 1,
    SaleEndDate = DATEADD(DAY, 30, GETDATE()),
    UpdatedAt   = SYSDATETIME()
WHERE CategoryId = 5;

-- Update dùng subquery
UPDATE Orders
SET TotalAmount = (
    SELECT SUM(od.Quantity * od.UnitPrice)
    FROM OrderDetails od
    WHERE od.OrderId = Orders.OrderId
)
WHERE Status = 'Pending';

UPDATE với JOIN

-- UPDATE với JOIN (SQL Server specific syntax)
UPDATE e
SET 
    e.DepartmentName = d.DepartmentName,  -- Bất thường, nhưng ví dụ về UPDATE với JOIN
    e.ManagerId = d.ManagerId
FROM Employees e
INNER JOIN Departments d ON e.DepartmentId = d.DepartmentId
WHERE d.IsActive = 1;

-- UPDATE nhiều tables liên quan
UPDATE od
SET od.UnitPrice = p.CurrentPrice
FROM OrderDetails od
JOIN Products p ON od.ProductId = p.ProductId
JOIN Orders o ON od.OrderId = o.OrderId
WHERE o.Status = 'Draft'    -- Chỉ update orders chưa confirm
  AND od.UnitPrice <> p.CurrentPrice;

-- Ví dụ thực tế: tăng lương theo department target
UPDATE e
SET e.Salary = e.Salary * (1 + d.SalaryIncreaseRate)
FROM Employees e
JOIN Departments d ON e.DepartmentId = d.DepartmentId
WHERE e.IsActive = 1
  AND e.LastReviewDate < DATEADD(YEAR, -1, GETDATE())
  AND d.SalaryIncreaseRate > 0;

UPDATE với CTE

-- UPDATE qua CTE
WITH EmployeesToUpdate AS (
    SELECT 
        e.EmployeeId,
        e.Salary,
        e.Salary * 1.05 AS NewSalary,
        ROW_NUMBER() OVER (PARTITION BY e.DepartmentId ORDER BY e.Salary DESC) AS rn
    FROM Employees e
    WHERE e.IsActive = 1
)
UPDATE EmployeesToUpdate
SET Salary = NewSalary
WHERE rn <= 3;  -- Chỉ tăng lương top 3 người trong mỗi department

-- UPDATE với ranking
WITH RankedEmployees AS (
    SELECT 
        EmployeeId,
        Salary,
        RANK() OVER (ORDER BY PerformanceScore DESC) AS perf_rank
    FROM Employees
    WHERE ReviewYear = 2025
)
UPDATE Employees
SET Salary = Salary * CASE 
    WHEN re.perf_rank <= 10 THEN 1.15  -- Top 10: +15%
    WHEN re.perf_rank <= 30 THEN 1.10  -- Rank 11-30: +10%
    ELSE 1.05                          -- Others: +5%
END
FROM Employees e
JOIN RankedEmployees re ON e.EmployeeId = re.EmployeeId;

OUTPUT clause với UPDATE

-- Capture giá trị trước và sau khi UPDATE
DECLARE @SalaryChanges TABLE (
    EmployeeId  INT,
    OldSalary   DECIMAL(15,2),
    NewSalary   DECIMAL(15,2),
    ChangedAt   DATETIME2
);

UPDATE Employees
SET Salary = Salary * 1.10
OUTPUT 
    INSERTED.EmployeeId,
    DELETED.Salary,       -- Giá trị CŨ (trước khi update)
    INSERTED.Salary,      -- Giá trị MỚI (sau khi update)
    INSERTED.UpdatedAt
INTO @SalaryChanges (EmployeeId, OldSalary, NewSalary, ChangedAt)
WHERE DepartmentId = 3 AND IsActive = 1;

-- Xem kết quả thay đổi
SELECT 
    EmployeeId,
    OldSalary,
    NewSalary,
    NewSalary - OldSalary AS increase_amount,
    ChangedAt
FROM @SalaryChanges;

3. DELETE

DELETE cơ bản

-- DELETE với điều kiện (LUÔN có WHERE!)
DELETE FROM Employees WHERE EmployeeId = 42;

-- DELETE nhiều rows
DELETE FROM AuditLog
WHERE CreatedAt < DATEADD(YEAR, -2, GETDATE())
  AND IsProcessed = 1;

-- DELETE với subquery
DELETE FROM Orders
WHERE OrderId IN (
    SELECT o.OrderId
    FROM Orders o
    LEFT JOIN OrderDetails od ON o.OrderId = od.OrderId
    WHERE od.OrderId IS NULL  -- Orders không có items
      AND o.CreatedAt < DATEADD(DAY, -7, GETDATE())
);

DELETE với JOIN

-- DELETE với FROM...JOIN (SQL Server syntax)
DELETE od
FROM OrderDetails od
JOIN Orders o ON od.OrderId = o.OrderId
WHERE o.Status = 'Cancelled'
  AND o.CancelledAt < DATEADD(MONTH, -6, GETDATE());

-- Soft delete thường được ưa chuộng hơn hard delete
UPDATE Employees
SET 
    IsDeleted  = 1,
    DeletedAt  = SYSDATETIME(),
    DeletedBy  = SUSER_SNAME()
WHERE EmployeeId = 42;

OUTPUT clause với DELETE

-- Capture rows bị xóa trước khi xóa
DECLARE @DeletedOrders TABLE (
    OrderId     INT,
    CustomerId  INT,
    TotalAmount DECIMAL(10,2),
    DeletedAt   DATETIME2 DEFAULT SYSDATETIME()
);

DELETE FROM Orders
OUTPUT 
    DELETED.OrderId,
    DELETED.CustomerId,
    DELETED.TotalAmount,
    SYSDATETIME()
INTO @DeletedOrders (OrderId, CustomerId, TotalAmount, DeletedAt)
WHERE Status = 'Cancelled'
  AND OrderDate < DATEADD(YEAR, -3, GETDATE());

-- Lưu audit trail
INSERT INTO OrdersDeleteAudit
SELECT * FROM @DeletedOrders;

TRUNCATE TABLE vs DELETE

-- DELETE - chậm, log từng row, có thể ROLLBACK trong transaction
BEGIN TRANSACTION;
DELETE FROM TempData WHERE BatchId = 42;
ROLLBACK;  -- Khôi phục được

-- TRUNCATE - nhanh hơn, không kích hoạt triggers
TRUNCATE TABLE TempData;  -- Xóa tất cả, reset IDENTITY

-- TRUNCATE với Foreign Key: phải disable FK trước
ALTER TABLE ChildTable NOCHECK CONSTRAINT FK_Child_Parent;
TRUNCATE TABLE ParentTable;  -- Error nếu FK vẫn active

-- Delete theo batch để tránh lock cả table
DECLARE @batch_size INT = 10000;
DECLARE @deleted_count INT;

REPEAT_DELETE:
    DELETE TOP (@batch_size)
    FROM LargeAuditTable
    WHERE CreatedAt < DATEADD(YEAR, -5, GETDATE());
    
    SET @deleted_count = @@ROWCOUNT;
    
    WAITFOR DELAY '00:00:01';  -- Cho phép các transaction khác tiếp tục
    
IF @deleted_count = @batch_size GOTO REPEAT_DELETE;
-- Lặp đến khi không còn gì để xóa

4. MERGE Statement (Upsert)

MERGE kết hợp INSERT, UPDATE, DELETE trong một statement:

-- Cú pháp MERGE cơ bản
MERGE INTO TargetTable AS target
USING SourceTable AS source
ON target.Id = source.Id

WHEN MATCHED AND target.SomeColumn <> source.SomeColumn THEN
    UPDATE SET 
        target.SomeColumn = source.SomeColumn,
        target.UpdatedAt = SYSDATETIME()

WHEN NOT MATCHED BY TARGET THEN
    INSERT (Id, SomeColumn, CreatedAt)
    VALUES (source.Id, source.SomeColumn, SYSDATETIME())

WHEN NOT MATCHED BY SOURCE THEN
    DELETE;  -- Xóa rows trong target không có trong source

Ví dụ thực tế - Product sync

-- Đồng bộ sản phẩm từ staging table vào production
MERGE INTO Products AS target
USING StagingProducts AS source
ON target.ProductSku = source.ProductSku

WHEN MATCHED AND (
    target.ProductName <> source.ProductName OR
    target.Price <> source.Price OR
    target.Stock <> source.Stock
) THEN
    UPDATE SET
        target.ProductName = source.ProductName,
        target.Price       = source.Price,
        target.Stock       = source.Stock,
        target.UpdatedAt   = SYSDATETIME()

WHEN NOT MATCHED BY TARGET THEN
    INSERT (ProductSku, ProductName, Price, Stock, CreatedAt)
    VALUES (source.ProductSku, source.ProductName, source.Price, source.Stock, SYSDATETIME())

WHEN NOT MATCHED BY SOURCE AND target.IsActive = 1 THEN
    UPDATE SET target.IsActive = 0, target.UpdatedAt = SYSDATETIME()

OUTPUT
    $action AS merge_action,          -- 'INSERT', 'UPDATE', 'DELETE'
    INSERTED.ProductSku,
    DELETED.Price AS old_price,
    INSERTED.Price AS new_price;

Upsert Pattern (Simple)

-- Đơn giản hơn MERGE khi chỉ cần INSERT hoặc UPDATE

-- Option 1: MERGE (an toàn nhất)
MERGE INTO UserPreferences AS target
USING (VALUES (@userId, @key, @value)) AS source(UserId, PrefKey, PrefValue)
ON target.UserId = source.UserId AND target.PrefKey = source.PrefKey
WHEN MATCHED THEN
    UPDATE SET target.PrefValue = source.PrefValue, target.UpdatedAt = SYSDATETIME()
WHEN NOT MATCHED THEN
    INSERT (UserId, PrefKey, PrefValue, CreatedAt)
    VALUES (source.UserId, source.PrefKey, source.PrefValue, SYSDATETIME());

-- Option 2: IF EXISTS (đơn giản nhưng có race condition)
IF EXISTS (SELECT 1 FROM UserPreferences WHERE UserId = @userId AND PrefKey = @key)
    UPDATE UserPreferences 
    SET PrefValue = @value, UpdatedAt = SYSDATETIME()
    WHERE UserId = @userId AND PrefKey = @key;
ELSE
    INSERT INTO UserPreferences (UserId, PrefKey, PrefValue)
    VALUES (@userId, @key, @value);

5. SELECT INTO

-- Tạo table mới từ kết quả query (không cần CREATE TABLE trước)
SELECT EmployeeId, FirstName + ' ' + LastName AS FullName, Salary, DepartmentId
INTO EmployeesBackup              -- Tạo table mới
FROM Employees
WHERE IsActive = 1;

-- SELECT INTO tạo table với cùng cấu trúc nhưng KHÔNG copy:
-- - Constraints (PK, FK, UNIQUE, CHECK)
-- - Indexes
-- - Triggers

-- Tạo empty table với cùng cấu trúc
SELECT * INTO EmptyEmployees
FROM Employees
WHERE 1 = 0;  -- Không có rows nào thỏa

-- Tạo table trong database khác
SELECT * INTO OtherDB.dbo.EmployeesBackup
FROM Employees;

-- SELECT INTO với tempdb (temporary table)
SELECT EmployeeId, Salary
INTO #TempSalaries  -- Temp table (# prefix)
FROM Employees;

SELECT EmployeeId, AVG(Salary) OVER (PARTITION BY DepartmentId) AS dept_avg
INTO ##GlobalTemp    -- Global temp table (## prefix)
FROM Employees;

6. Bulk Operations

BULK INSERT

-- Import dữ liệu từ file CSV
BULK INSERT Products
FROM 'D:\Data\products.csv'
WITH (
    FORMAT = 'CSV',              -- SQL Server 2017+
    FIELDTERMINATOR = ',',       -- Phân cách cột
    ROWTERMINATOR = '\n',        -- Phân cách dòng
    FIRSTROW = 2,                -- Bỏ qua header row
    MAXERRORS = 10,              -- Cho phép tối đa 10 lỗi
    ERRORFILE = 'D:\Errors\products_errors.txt',
    TABLOCK                      -- Table-level lock, nhanh hơn
);

-- Import với format file
BULK INSERT Products
FROM 'D:\Data\products.dat'
WITH (
    FORMATFILE = 'D:\Data\products.fmt',  -- File mô tả format
    BATCHSIZE = 5000,            -- Commit mỗi 5000 rows
    TABLOCK
);

OPENROWSET

-- Import từ file ad-hoc
INSERT INTO Products (ProductName, Price, CategoryId)
SELECT ProductName, Price, CategoryId
FROM OPENROWSET(
    BULK 'D:\Data\products.csv',
    FORMATFILE = 'D:\Data\products.fmt'
) AS bulk_data;

-- Import từ Excel (cần OLEDB provider)
SELECT * 
FROM OPENROWSET(
    'Microsoft.ACE.OLEDB.12.0',
    'Excel 12.0;Database=D:\Data\products.xlsx;HDR=YES',
    'SELECT * FROM [Sheet1$]'
);

Table-Valued Parameters (TVP)

-- Tạo user-defined table type
CREATE TYPE dbo.ProductList AS TABLE (
    ProductId   INT NOT NULL,
    ProductName NVARCHAR(200) NOT NULL,
    Price       DECIMAL(10,2) NOT NULL,
    
    PRIMARY KEY (ProductId)
);

-- Stored procedure nhận TVP
CREATE PROCEDURE dbo.BulkInsertProducts
    @Products dbo.ProductList READONLY  -- READONLY là bắt buộc cho TVP parameters
AS
BEGIN
    INSERT INTO Products (ProductId, ProductName, Price)
    SELECT ProductId, ProductName, Price
    FROM @Products;
END;

-- Sử dụng từ T-SQL
DECLARE @myProducts dbo.ProductList;
INSERT INTO @myProducts (ProductId, ProductName, Price)
VALUES (1, 'Widget A', 19.99), (2, 'Widget B', 29.99);

EXEC dbo.BulkInsertProducts @Products = @myProducts;

7. Transactions với DML

-- Transaction đảm bảo ACID properties
BEGIN TRANSACTION;

    -- Tất cả hoặc không có gì
    INSERT INTO Orders (CustomerId, OrderDate, TotalAmount)
    VALUES (42, GETDATE(), 299.99);

    DECLARE @orderId INT = SCOPE_IDENTITY();

    INSERT INTO OrderDetails (OrderId, ProductId, Quantity, UnitPrice)
    VALUES (@orderId, 101, 2, 99.99),
           (@orderId, 202, 1, 100.01);

    -- Cập nhật stock
    UPDATE Products
    SET Stock = Stock - 2
    WHERE ProductId = 101;
    
    UPDATE Products
    SET Stock = Stock - 1
    WHERE ProductId = 202;

    -- Kiểm tra stock không âm
    IF EXISTS (SELECT 1 FROM Products WHERE ProductId IN (101, 202) AND Stock < 0)
    BEGIN
        ROLLBACK TRANSACTION;
        RAISERROR('Insufficient stock', 16, 1);
        RETURN;
    END

COMMIT TRANSACTION;

-- Transaction với error handling
BEGIN TRY
    BEGIN TRANSACTION;

        UPDATE Accounts SET Balance = Balance - 500 WHERE AccountId = 1;
        UPDATE Accounts SET Balance = Balance + 500 WHERE AccountId = 2;
        
        -- Kiểm tra balance
        IF EXISTS (SELECT 1 FROM Accounts WHERE AccountId = 1 AND Balance < 0)
            THROW 50001, 'Insufficient funds.', 1;

    COMMIT TRANSACTION;
    PRINT 'Transfer successful';
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;
    
    DECLARE @ErrorMessage NVARCHAR(4000) = ERROR_MESSAGE();
    DECLARE @ErrorSeverity INT = ERROR_SEVERITY();
    DECLARE @ErrorState INT = ERROR_STATE();
    
    RAISERROR (@ErrorMessage, @ErrorSeverity, @ErrorState);
END CATCH;

8. Performance Considerations

Set-based vs Row-by-row Operations

-- BAD: Cursor (row-by-row) - rất chậm cho large datasets
DECLARE @EmployeeId INT, @Salary DECIMAL(15,2);

DECLARE emp_cursor CURSOR FOR
    SELECT EmployeeId, Salary FROM Employees WHERE IsActive = 1;

OPEN emp_cursor;
FETCH NEXT FROM emp_cursor INTO @EmployeeId, @Salary;

WHILE @@FETCH_STATUS = 0
BEGIN
    UPDATE Employees
    SET Salary = @Salary * 1.05
    WHERE EmployeeId = @EmployeeId;
    
    FETCH NEXT FROM emp_cursor INTO @EmployeeId, @Salary;
END;

CLOSE emp_cursor;
DEALLOCATE emp_cursor;

-- GOOD: Set-based (một lần cho tất cả)
UPDATE Employees
SET Salary = Salary * 1.05
WHERE IsActive = 1;

-- Set-based thường nhanh hơn cursor 10-100x cho large datasets!

Batch Updates cho Large Tables

-- Chia UPDATE/DELETE thành batches để giảm lock pressure
DECLARE @batch_size INT = 5000;
DECLARE @rows_affected INT = 1;

WHILE @rows_affected > 0
BEGIN
    UPDATE TOP (@batch_size) e
    SET e.IsArchived = 1, e.ArchivedAt = SYSDATETIME()
    FROM Employees e
    WHERE e.IsActive = 0 
      AND e.TerminationDate < DATEADD(YEAR, -3, GETDATE())
      AND e.IsArchived = 0;
    
    SET @rows_affected = @@ROWCOUNT;
    
    -- Nhường CPU và lock cho các processes khác
    WAITFOR DELAY '00:00:00.500';  -- 500ms pause
END;

Avoiding Common DML Pitfalls

-- 1. Luôn có WHERE trong UPDATE/DELETE (kiểm tra kỹ!)
-- Test với SELECT trước
SELECT * FROM Employees WHERE DepartmentId = 99;  -- Xem có đúng không
UPDATE Employees SET Salary = 0 WHERE DepartmentId = 99;  -- Sau đó UPDATE

-- 2. Dùng OUTPUT để audit changes quan trọng
-- 3. Test trong transaction, rollback nếu số rows không đúng
BEGIN TRANSACTION;
UPDATE Products SET Price = Price * 0.9 WHERE CategoryId = 5;
SELECT @@ROWCOUNT AS rows_updated;  -- Kiểm tra số rows
-- Nếu đúng thì: COMMIT TRANSACTION;
-- Nếu sai thì: ROLLBACK TRANSACTION;
ROLLBACK TRANSACTION;  -- Nhớ commit hoặc rollback!

-- 4. MERGE có thể có edge cases - test kỹ
-- 5. Avoid implicit conversion trong WHERE clause của DML
-- BAD:
DELETE FROM Orders WHERE OrderId = '1000';  -- Convert string sang int mỗi row
-- GOOD:
DELETE FROM Orders WHERE OrderId = 1000;    -- Type match, dùng index

-- 6. Với INSERT nhiều rows, dùng multi-row VALUES thay vì nhiều INSERT
-- BAD:
INSERT INTO Tags (Name) VALUES ('SQL');
INSERT INTO Tags (Name) VALUES ('Database');
INSERT INTO Tags (Name) VALUES ('Performance');

-- GOOD:
INSERT INTO Tags (Name) VALUES ('SQL'), ('Database'), ('Performance');

INSERT Performance

-- Tắt indexes trước khi BULK INSERT, bật lại sau
ALTER INDEX ALL ON Products DISABLE;

BULK INSERT Products
FROM 'D:\data\products.csv'
WITH (TABLOCK, BATCHSIZE = 10000);

ALTER INDEX ALL ON Products REBUILD;

-- Tắt CHECK và FK constraints để tăng tốc BULK INSERT
ALTER TABLE Products NOCHECK CONSTRAINT ALL;
-- ... BULK INSERT ...
ALTER TABLE Products WITH CHECK CHECK CONSTRAINT ALL;  -- Re-validate sau

-- Sử dụng minimal logging với SIMPLE recovery model
ALTER DATABASE MyDB SET RECOVERY SIMPLE;
-- ... BULK INSERT với TABLOCK ...
ALTER DATABASE MyDB SET RECOVERY FULL;

Truy vấn & Joins

Hiểu sâu về cách SQL Server xử lý JOIN và các loại truy vấn phức tạp là nền tảng để viết T-SQL hiệu quả và tối ưu hiệu suất.

1. INNER JOIN

INNER JOIN trả về các hàng có kết quả khớp ở cả hai bảng theo điều kiện join.

-- Cú pháp cơ bản
SELECT o.OrderId, o.OrderDate, c.CustomerName
FROM Orders o
INNER JOIN Customers c ON o.CustomerId = c.CustomerId;

-- Tương đương với (cú pháp cũ, không khuyến nghị)
SELECT o.OrderId, o.OrderDate, c.CustomerName
FROM Orders o, Customers c
WHERE o.CustomerId = c.CustomerId;

Lưu ý quan trọng

• Hàng nào không có match ở bảng kia sẽ bị loại bỏ
• Có thể join trên nhiều cột (composite key)

-- Join trên nhiều cột
SELECT *
FROM OrderDetails od
INNER JOIN Products p 
    ON od.ProductId = p.ProductId 
    AND od.WarehouseId = p.WarehouseId;

2. LEFT / RIGHT OUTER JOIN

LEFT JOIN (LEFT OUTER JOIN)

Trả về tất cả hàng từ bảng trái + hàng khớp từ bảng phải. Nếu không có match, cột bảng phải trả về NULL.

-- Lấy tất cả khách hàng, kể cả chưa có đơn hàng nào
SELECT c.CustomerId, c.CustomerName, o.OrderId, o.OrderDate
FROM Customers c
LEFT JOIN Orders o ON c.CustomerId = o.CustomerId;

-- Tìm khách hàng CHƯA có đơn hàng
SELECT c.CustomerId, c.CustomerName
FROM Customers c
LEFT JOIN Orders o ON c.CustomerId = o.CustomerId
WHERE o.OrderId IS NULL;   -- Anti-join pattern

RIGHT JOIN (RIGHT OUTER JOIN)

Trả về tất cả hàng từ bảng phải + hàng khớp từ bảng trái.

-- Tương đương với LEFT JOIN nhưng đổi thứ tự bảng
SELECT c.CustomerId, c.CustomerName, o.OrderId
FROM Orders o
RIGHT JOIN Customers c ON o.CustomerId = c.CustomerId;

Tip: Trong thực tế, hầu hết lập trình viên dùng LEFT JOIN hết, ít dùng RIGHT JOIN để code dễ đọc hơn.

3. FULL OUTER JOIN

Trả về tất cả hàng từ cả hai bảng. Nếu không có match, side không có sẽ là NULL.

-- Lấy tất cả employees và departments, kể cả không match
SELECT e.EmployeeId, e.Name, d.DepartmentName
FROM Employees e
FULL OUTER JOIN Departments d ON e.DepartmentId = d.DepartmentId;

-- Tìm các hàng chỉ tồn tại ở một trong hai bảng (symmetric difference)
SELECT e.EmployeeId, e.Name, d.DepartmentName
FROM Employees e
FULL OUTER JOIN Departments d ON e.DepartmentId = d.DepartmentId
WHERE e.EmployeeId IS NULL OR d.DepartmentId IS NULL;

4. CROSS JOIN

CROSS JOIN tạo ra tích Descartes (Cartesian product): mỗi hàng bảng A kết hợp với mọi hàng bảng B.

-- Tạo tất cả tổ hợp màu sắc và kích thước
SELECT c.ColorName, s.SizeName
FROM Colors c
CROSS JOIN Sizes s;
-- Nếu Colors có 5 hàng, Sizes có 3 hàng → 15 hàng kết quả

-- Ứng dụng thực tế: Tạo calendar/date dimension
SELECT d.DateValue, h.HourValue
FROM (VALUES ('2024-01-01'), ('2024-01-02'), ('2024-01-03')) AS d(DateValue)
CROSS JOIN (VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9),(10),(11)) AS h(HourValue);

Cảnh báo

CROSS JOIN với bảng lớn có thể tạo ra hàng triệu hàng, gây OutOfMemory hoặc timeout.

5. SELF JOIN

SELF JOIN là join bảng với chính nó, thường dùng cho dữ liệu phân cấp (hierarchical data).

-- Lấy employee và tên manager của họ
SELECT 
    e.EmployeeId,
    e.Name AS EmployeeName,
    m.Name AS ManagerName
FROM Employees e
LEFT JOIN Employees m ON e.ManagerId = m.EmployeeId;

-- Tìm các cặp nhân viên cùng phòng ban
SELECT 
    e1.Name AS Employee1,
    e2.Name AS Employee2,
    e1.DepartmentId
FROM Employees e1
INNER JOIN Employees e2 
    ON e1.DepartmentId = e2.DepartmentId
    AND e1.EmployeeId < e2.EmployeeId  -- Tránh duplicate pairs
ORDER BY e1.DepartmentId;

6. Multiple Table Joins (Kết hợp nhiều bảng)

-- JOIN 4 bảng
SELECT 
    o.OrderId,
    o.OrderDate,
    c.CustomerName,
    p.ProductName,
    od.Quantity,
    od.UnitPrice,
    cat.CategoryName
FROM Orders o
INNER JOIN Customers c    ON o.CustomerId = c.CustomerId
INNER JOIN OrderDetails od ON o.OrderId = od.OrderId
INNER JOIN Products p     ON od.ProductId = p.ProductId
INNER JOIN Categories cat ON p.CategoryId = cat.CategoryId
WHERE o.OrderDate >= '2024-01-01'
ORDER BY o.OrderDate DESC;

Thứ tự JOIN ảnh hưởng đến hiệu suất

SQL Server Optimizer thường chọn thứ tự tối ưu, nhưng có thể gợi ý thứ tự bằng OPTION (FORCE ORDER):

-- Ép optimizer join theo thứ tự viết
SELECT ...
FROM SmallTable s
INNER JOIN LargeTable l ON s.Id = l.SmallId
OPTION (FORCE ORDER);

7. Subqueries (Truy vấn con)

Non-Correlated Subquery

Subquery chạy một lần độc lập, không phụ thuộc outer query.

-- Lấy sản phẩm có giá cao hơn giá trung bình
SELECT ProductId, ProductName, Price
FROM Products
WHERE Price > (SELECT AVG(Price) FROM Products);

-- IN với subquery
SELECT * FROM Orders
WHERE CustomerId IN (
    SELECT CustomerId FROM Customers WHERE Country = 'Vietnam'
);

Correlated Subquery

Subquery tham chiếu đến outer query, chạy lại cho mỗi hàng.

-- Lấy đơn hàng gần nhất của mỗi khách hàng
SELECT o1.OrderId, o1.CustomerId, o1.OrderDate
FROM Orders o1
WHERE o1.OrderDate = (
    SELECT MAX(o2.OrderDate)
    FROM Orders o2
    WHERE o2.CustomerId = o1.CustomerId  -- Tham chiếu outer query
);

Performance Warning: Correlated subquery chạy N lần (N = số hàng outer query). Với bảng lớn, nên viết lại thành JOIN hoặc dùng window function.

-- ✅ Viết lại với ROW_NUMBER() - hiệu quả hơn
WITH LatestOrders AS (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY CustomerId ORDER BY OrderDate DESC) AS rn
    FROM Orders
)
SELECT OrderId, CustomerId, OrderDate
FROM LatestOrders
WHERE rn = 1;

Scalar Subquery

Subquery trả về đúng một giá trị (một hàng, một cột).

SELECT 
    ProductId,
    ProductName,
    Price,
    (SELECT AVG(Price) FROM Products) AS AvgPrice,
    Price - (SELECT AVG(Price) FROM Products) AS DiffFromAvg
FROM Products;

8. EXISTS vs IN vs JOIN

EXISTS

Kiểm tra sự tồn tại - dừng ngay khi tìm thấy hàng đầu tiên.

-- Khách hàng có ít nhất 1 đơn hàng
SELECT c.CustomerId, c.CustomerName
FROM Customers c
WHERE EXISTS (
    SELECT 1
    FROM Orders o
    WHERE o.CustomerId = c.CustomerId
);

IN

So sánh giá trị với một tập hợp kết quả.

SELECT ProductId, ProductName
FROM Products
WHERE CategoryId IN (1, 3, 5);

SELECT ProductId, ProductName
FROM Products
WHERE CategoryId IN (SELECT CategoryId FROM Categories WHERE IsActive = 1);

So sánh hiệu suất

-- ❌ NOT IN nguy hiểm với NULL
SELECT * FROM Orders
WHERE CustomerId NOT IN (SELECT CustomerId FROM BlacklistCustomers);
-- Nếu BlacklistCustomers có 1 hàng CustomerId = NULL → không hàng nào được trả về!

-- ✅ NOT EXISTS an toàn hơn
SELECT * FROM Orders o
WHERE NOT EXISTS (
    SELECT 1 FROM BlacklistCustomers bc WHERE bc.CustomerId = o.CustomerId
);

9. APPLY Operator

APPLY gọi một table-valued function hoặc subquery cho mỗi hàng của outer table.

CROSS APPLY

Giống INNER JOIN: chỉ trả về hàng outer khi subquery có kết quả.

-- Top 3 orders gần nhất cho mỗi khách hàng
SELECT c.CustomerId, c.CustomerName, o.OrderId, o.OrderDate
FROM Customers c
CROSS APPLY (
    SELECT TOP 3 OrderId, OrderDate
    FROM Orders
    WHERE CustomerId = c.CustomerId
    ORDER BY OrderDate DESC
) o;

-- Sử dụng với Table-Valued Function
SELECT e.EmployeeId, t.SaleAmount
FROM Employees e
CROSS APPLY dbo.GetTopSalesForEmployee(e.EmployeeId, 5) t;

OUTER APPLY

Giống LEFT JOIN: trả về tất cả hàng outer, dù subquery không có kết quả (NULL).

-- Tất cả khách hàng, kể cả chưa có đơn hàng
SELECT c.CustomerId, c.CustomerName, o.OrderId, o.OrderDate
FROM Customers c
OUTER APPLY (
    SELECT TOP 1 OrderId, OrderDate
    FROM Orders
    WHERE CustomerId = c.CustomerId
    ORDER BY OrderDate DESC
) o;

APPLY vs JOIN

-- CROSS APPLY có thể làm những việc mà JOIN không làm được:
-- Gọi TVF với tham số từ outer table
SELECT p.ProductId, p.ProductName, r.RelatedProductId
FROM Products p
CROSS APPLY dbo.GetRelatedProducts(p.ProductId, p.CategoryId) r;

10. Set Operations: UNION / UNION ALL / INTERSECT / EXCEPT

UNION vs UNION ALL

-- UNION: loại bỏ duplicate (tốn thêm chi phí DISTINCT)
SELECT ProductId, ProductName FROM ActiveProducts
UNION
SELECT ProductId, ProductName FROM ArchivedProducts;

-- UNION ALL: giữ tất cả hàng, nhanh hơn
SELECT ProductId, ProductName FROM ActiveProducts
UNION ALL
SELECT ProductId, ProductName FROM ArchivedProducts;

INTERSECT

Trả về hàng có trong cả hai tập hợp.

-- Sản phẩm vừa có trong ActiveProducts vừa có trong FeaturedProducts
SELECT ProductId, ProductName FROM ActiveProducts
INTERSECT
SELECT ProductId, ProductName FROM FeaturedProducts;

EXCEPT

Trả về hàng có trong tập đầu nhưng không có ở tập sau.

-- Sản phẩm active nhưng chưa được featured
SELECT ProductId, ProductName FROM ActiveProducts
EXCEPT
SELECT ProductId, ProductName FROM FeaturedProducts;

Lưu ý

• Số cột và kiểu dữ liệu phải tương thích
• UNION / INTERSECT / EXCEPT đều loại bỏ duplicate
• UNION ALL là ngoại lệ duy nhất không loại duplicate
• ORDER BY chỉ được phép ở cuối cùng

SELECT ProductId, ProductName, 'Active' AS Source FROM ActiveProducts
UNION ALL
SELECT ProductId, ProductName, 'Archived' AS Source FROM ArchivedProducts
ORDER BY ProductName;  -- ORDER BY chỉ ở cuối cùng

11. Derived Tables (Inline Views)

Derived table là subquery trong mệnh đề FROM, hoạt động như một bảng tạm thời.

-- Derived table: lấy top customers theo doanh thu
SELECT dt.CustomerId, dt.CustomerName, dt.TotalRevenue
FROM (
    SELECT 
        c.CustomerId,
        c.CustomerName,
        SUM(o.TotalAmount) AS TotalRevenue
    FROM Customers c
    INNER JOIN Orders o ON c.CustomerId = o.CustomerId
    GROUP BY c.CustomerId, c.CustomerName
) AS dt   -- Bắt buộc phải đặt alias
WHERE dt.TotalRevenue > 10000
ORDER BY dt.TotalRevenue DESC;

CTE vs Derived Table

-- CTE (Common Table Expression) - thường dễ đọc hơn
WITH CustomerRevenue AS (
    SELECT 
        c.CustomerId,
        c.CustomerName,
        SUM(o.TotalAmount) AS TotalRevenue
    FROM Customers c
    INNER JOIN Orders o ON c.CustomerId = o.CustomerId
    GROUP BY c.CustomerId, c.CustomerName
)
SELECT * FROM CustomerRevenue WHERE TotalRevenue > 10000;

Note: CTE và Derived table về mặt hiệu suất thường tương đương - optimizer xử lý chúng giống nhau. CTE có thể tái sử dụng trong cùng query.

12. Query Hints (Gợi ý truy vấn)

NOLOCK (READ UNCOMMITTED)

-- Đọc dữ liệu chưa được commit (dirty read), tránh blocking
SELECT * FROM Orders WITH (NOLOCK)
WHERE OrderDate >= '2024-01-01';

-- Cảnh báo: có thể đọc dữ liệu "phantom" hoặc dữ liệu bị rollback!

FORCESEEK

-- Ép optimizer dùng Index Seek thay vì Scan
SELECT * FROM Orders WITH (FORCESEEK)
WHERE CustomerId = 12345;

-- Ép seek trên index cụ thể
SELECT * FROM Orders WITH (FORCESEEK (IX_Orders_CustomerId (CustomerId)))
WHERE CustomerId = 12345;

INDEX hint

-- Ép dùng index cụ thể
SELECT * FROM Orders WITH (INDEX = IX_Orders_OrderDate)
WHERE OrderDate BETWEEN '2024-01-01' AND '2024-12-31';

-- Ép Table Scan (bỏ qua tất cả indexes)
SELECT * FROM SmallTable WITH (INDEX = 0);

OPTION hints

-- Force recompile plan cho query này
SELECT * FROM Orders WHERE CustomerId = @Id 
OPTION (RECOMPILE);

-- Giới hạn parallelism
SELECT * FROM BigTable 
OPTION (MAXDOP 4);

-- Optimize for specific parameter value
SELECT * FROM Orders WHERE CustomerId = @Id
OPTION (OPTIMIZE FOR (@Id = 1000));

-- Optimize for unknown (avoid parameter sniffing)
SELECT * FROM Orders WHERE CustomerId = @Id
OPTION (OPTIMIZE FOR UNKNOWN);

Best practice: Chỉ dùng hints khi bạn biết rõ lý do - hints có thể trở nên không còn tối ưu khi data distribution thay đổi.

Q&A - Phỏng vấn

Junior Level

Q: Sự khác biệt giữa INNER JOIN và LEFT JOIN là gì?

A: INNER JOIN chỉ trả về hàng có match ở cả hai bảng. LEFT JOIN trả về tất cả hàng bảng trái, nếu không có match bảng phải thì các cột đó là NULL. Dùng LEFT JOIN khi cần giữ lại tất cả records của bảng chính dù không có dữ liệu liên quan.

Q: UNION khác UNION ALL như thế nào?

A: UNION loại bỏ các hàng trùng lặp (thực hiện DISTINCT ngầm), UNION ALL giữ tất cả hàng kể cả duplicate. UNION chậm hơn vì phải so sánh để loại duplicate. Dùng UNION ALL khi biết chắc không có duplicate hoặc không quan tâm đến duplicate để tăng hiệu suất.

Q: Subquery là gì? Cho ví dụ?

A: Subquery là truy vấn SQL nằm bên trong một truy vấn khác (trong WHERE, FROM, SELECT, HAVING). Ví dụ: SELECT * FROM Products WHERE Price > (SELECT AVG(Price) FROM Products) - subquery tính giá trung bình, outer query lọc sản phẩm đắt hơn trung bình.

Mid Level

Q: Khi nào nên dùng EXISTS thay vì IN?

A: Dùng EXISTS khi subquery trả về nhiều hàng (bảng lớn) vì EXISTS dừng ngay khi tìm thấy một hàng match (short-circuit). NOT IN phải tránh nếu tập có thể chứa NULL vì kết quả sẽ luôn rỗng. NOT EXISTS là lựa chọn an toàn hơn. Với tập giá trị nhỏ và tĩnh thì IN vẫn dùng được.

Q: Correlated subquery là gì? Tại sao có thể gây vấn đề hiệu suất?

A: Correlated subquery tham chiếu đến cột của outer query, nghĩa là nó được thực thi lại cho mỗi hàng của outer query. Nếu outer query trả về N hàng thì subquery chạy N lần. Với bảng lớn điều này rất tốn kém. Giải pháp: viết lại bằng JOIN hoặc window functions (ROW_NUMBER, RANK…).

Q: CROSS APPLY và OUTER APPLY khác nhau thế nào?

A: CROSS APPLY tương tự INNER JOIN - chỉ trả về outer rows khi subquery/TVF có kết quả. OUTER APPLY tương tự LEFT JOIN - trả về tất cả outer rows, nếu không có match thì cột bên trong là NULL. APPLY thường dùng để gọi table-valued function với tham số từ outer table, hoặc để lấy top-N rows per group.

Q: Tại sao NOT IN nguy hiểm khi có NULL trong tập hợp?

A: Vì SQL dùng logic ba giá trị (TRUE/FALSE/UNKNOWN). Khi so sánh bất kỳ giá trị nào với NULL, kết quả là UNKNOWN. Trong NOT IN, nếu tập chứa NULL thì điều kiện x NOT IN (..., NULL, ...) tương đương x != NULL là UNKNOWN, khiến không hàng nào được trả về. Luôn dùng NOT EXISTS thay thế.

Senior Level

Q: Giải thích cơ chế Join Algorithms của SQL Server (Nested Loops, Hash Join, Merge Join)?

A:

• Nested Loops: Với mỗi hàng outer table, duyệt qua inner table để tìm match. Hiệu quả khi outer table nhỏ và inner table có index trên join key. O(N×M) worst case.
• Hash Join: Build hash table từ bảng nhỏ hơn (build input), sau đó probe với bảng lớn hơn. Hiệu quả cho large, unsorted, unindexed inputs. Tốn bộ nhớ - có thể spill ra TempDB.
• Merge Join: Cả hai inputs phải được sắp xếp theo join key. Rất hiệu quả khi inputs đã có order (từ index). O(N+M). Optimizer chọn dựa trên ước tính cardinality và có index hay không.

Q: Làm thế nào để viết lại correlated subquery lấy top-N per group hiệu quả hơn trong SQL Server?

A: Dùng window functions thay vì correlated subquery:

-- ❌ Correlated subquery - chạy N lần
SELECT * FROM Orders o1
WHERE OrderDate IN (
    SELECT TOP 3 OrderDate FROM Orders o2
    WHERE o2.CustomerId = o1.CustomerId
    ORDER BY OrderDate DESC
);

-- ✅ ROW_NUMBER() - hiệu quả hơn nhiều
WITH RankedOrders AS (
    SELECT *, ROW_NUMBER() OVER (
        PARTITION BY CustomerId 
        ORDER BY OrderDate DESC
    ) AS rn
    FROM Orders
)
SELECT * FROM RankedOrders WHERE rn <= 3;

Window function tiếp cận theo set-based, SQL Server có thể tối ưu tốt hơn nhiều so với row-by-row correlated subquery.

Q: Khi nào APPLY operator tốt hơn JOIN?

A: APPLY tốt hơn JOIN trong các trường hợp:

1. TVF với tham số từ outer row: CROSS APPLY dbo.fn(e.EmployeeId) - JOIN không thể làm điều này.
2. Top-N per group: CROSS APPLY (SELECT TOP 3 ... WHERE CustomerId = c.CustomerId ORDER BY ...) - thường hiệu quả hơn ROW_NUMBER() cho cardinality thấp.
3. Tránh outer reference trong subquery phức tạp: APPLY cho phép tái sử dụng alias trong cùng mệnh đề APPLY.

JOIN thường được optimizer tối ưu tốt hơn khi chỉ cần equi-join đơn giản.

Indexes & Performance

Phần này bao gồm tất cả kiến thức về Index và tối ưu hiệu suất trong SQL Server - từ cơ bản đến nâng cao.

Các chủ đề

• Index Cơ Bản: Clustered/Non-Clustered Index, B-tree, SARGable predicates, chọn clustered key, covering index, fragmentation, index maintenance
• Index Nâng Cao: Filtered Index, Columnstore Index, Full-Text, XML, Spatial, Unique, Composite, In-Memory OLTP Indexes
• Query Optimization: Query Pipeline, Cost-Based Optimizer, Anti-Patterns, JOIN Algorithms, Parameter Sniffing, TempDB, Parallelism, DMVs, Extended Events
• Execution Plans: Đọc và phân tích execution plans, các operators phổ biến

Q&A - Phỏng vấn

Junior Level

Q1: Index là gì và tại sao cần dùng index?

A: Index là cấu trúc dữ liệu bổ sung (B-tree) giúp SQL Server tìm kiếm dữ liệu nhanh hơn mà không cần đọc toàn bộ bảng (Table Scan). Không có index, SQL Server phải đọc tất cả các trang dữ liệu. Với index, SQL Server đi theo B-tree từ root đến leaf để tìm đúng records - tương tự mục lục của cuốn sách.

Q2: Clustered Index và Non-Clustered Index khác nhau thế nào?

A:

• Clustered Index: quyết định thứ tự vật lý lưu trữ dữ liệu trong bảng. Leaf pages chứa chính data rows. Mỗi bảng chỉ có 1 clustered index.
• Non-Clustered Index: cấu trúc B-tree riêng biệt với bảng. Leaf pages chứa key columns + row locator (clustered key hoặc RID nếu bảng là heap). Mỗi bảng có thể có đến 999 non-clustered indexes.

Q3: Khi nào xảy ra Table Scan và khi nào Index Seek?

A: Table Scan xảy ra khi không có index phù hợp, predicate không SARGable, hoặc optimizer ước tính phần lớn bảng sẽ được đọc (thường > 5-30%). Index Seek xảy ra khi có SARGable predicate matching leading key column của index. SARGable có nghĩa là cột không bị bao bọc trong function hay biểu thức.

Q4: Covering Index là gì?

A: Covering Index là index chứa tất cả các cột mà một query cần - cả cột dùng để filter (WHERE) và cột cần lấy (SELECT). Khi query được “covered” bởi index, SQL Server không cần quay lại bảng gốc để lấy thêm dữ liệu (tránh Key Lookup), giúp giảm I/O đáng kể.

Q5: UNION và UNION ALL khác nhau thế nào?

A: UNION loại bỏ duplicate rows (thực hiện DISTINCT ngầm, tốn thêm sort/hash). UNION ALL giữ tất cả rows kể cả duplicate và nhanh hơn. Dùng UNION ALL khi biết chắc không có duplicate hoặc không cần loại bỏ chúng để tối ưu hiệu suất.

Q6: Fill Factor là gì? Giá trị nên chọn là bao nhiêu?

A: Fill Factor là % không gian lấp đầy trên mỗi leaf page khi tạo/rebuild index. Để lại không gian trống giúp giảm page split khi INSERT. Giá trị phổ biến:

• 100 (0): read-only tables
• 80-90: mixed workload bình thường
• 60-70: heavy insert/update vào giữa index

Q7: Heap là gì trong SQL Server?

A: Heap là bảng không có clustered index - data pages không được tổ chức theo thứ tự. SQL Server dùng IAM (Index Allocation Map) pages để tìm data pages. Heap tốt khi insert nhiều và không cần range scan. Non-clustered index trên Heap dùng RID (Row ID = file + page + slot) làm row locator thay vì clustered key.

Q8: Fragmentation là gì? Khi nào REBUILD vs REORGANIZE?

A: Fragmentation xảy ra khi pages không còn liên tục về mặt vật lý sau nhiều INSERT/UPDATE/DELETE. Ảnh hưởng: sequential I/O trở thành random I/O, chậm hơn.

• REORGANIZE: fragmentation 10-30%, online (không block reads/writes), ít log hơn
• REBUILD: fragmentation > 30%, có thể offline hoặc ONLINE (Enterprise), reset fill factor, update statistics đầy đủ

Mid Level

Q9: Tại sao không nên tạo quá nhiều indexes trên một bảng?

A: Mỗi index tốn thêm write overhead: khi INSERT/UPDATE/DELETE một hàng, SQL Server phải cập nhật tất cả indexes liên quan. Ngoài ra, nhiều indexes tốn storage và RAM (buffer pool). Index cũng cần maintenance (REBUILD/REORGANIZE). Rule of thumb: OLTP tables thường không nên quá 5-7 indexes, DWH/fact tables có thể nhiều hơn.

Q10: SARGable predicate là gì? Cho ví dụ non-SARGable và cách sửa?

A: SARGable (Search ARGument ABLE) là predicate mà SQL Server có thể dùng để Index Seek. Predicate trở thành non-SARGable khi cột nằm bên trong function hoặc biểu thức.

-- ❌ Non-SARGable
WHERE YEAR(OrderDate) = 2024
WHERE UPPER(LastName) = 'NGUYEN'

-- ✅ SARGable alternatives
WHERE OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01'
WHERE LastName = 'Nguyen'   -- CI collation tự xử lý case-insensitive

Q11: Parameter Sniffing là gì? Khi nào nó gây vấn đề và cách giải quyết?

A: Parameter Sniffing xảy ra khi SQL Server compile stored procedure lần đầu với một parameter value cụ thể và cache plan đó. Nếu distribution data không đồng đều, plan tốt cho một giá trị có thể rất tệ cho giá trị khác.

Giải pháp:

1. OPTION (RECOMPILE) - compile lại mỗi lần (mất cache benefit)
2. OPTION (OPTIMIZE FOR UNKNOWN) - dùng average statistics
3. Local variable trick - DECLARE @Local = @Param
4. Query Store - detect regression và force good plan

Q12: Composite Index: thứ tự cột ảnh hưởng thế nào?

A: SQL Server chỉ có thể seek trên composite index nếu bắt đầu từ leading column. Index (A, B, C) hỗ trợ seek trên A, A+B, A+B+C nhưng không seek được trên chỉ B hay C. Nguyên tắc: equality columns trước, range column sau cùng, selectivity cao ưu tiên trước.

Q13: Khi nào dùng Filtered Index?

A: Filtered Index hữu ích khi:

1. Sparse data: cột có nhiều NULL (chỉ index hàng không NULL)
2. Soft deletes: WHERE IsDeleted = 0 - chỉ index active records
3. Status filtering: chỉ query một trạng thái cụ thể thường xuyên
4. Partial uniqueness: unique email chỉ trong active users

Filtered Index nhỏ hơn full index → ít RAM, ít I/O, ít maintenance. Nhưng chỉ được dùng khi query predicate tương thích với filter predicate của index.

Q14: Hash Join vs Nested Loops vs Merge Join - khi nào optimizer chọn cái nào?

A:

• Nested Loops: outer table nhỏ, inner table có index trên join key. Tốt cho OLTP lookups.
• Hash Join: cả hai inputs lớn, không có index phù hợp. Tốn memory (có thể spill TempDB).
• Merge Join: cả hai inputs đã sorted theo join key (từ index). Rất hiệu quả nhưng cần sorted input.

Optimizer chọn dựa trên estimated row counts và available indexes. Nếu estimates sai (statistics lỗi thời), wrong algorithm có thể được chọn.

Q15: Implicit conversion là gì và tại sao gây vấn đề hiệu suất?

A: Implicit conversion xảy ra khi SQL Server tự động convert kiểu dữ liệu để so sánh. Ví dụ: cột NVARCHAR so sánh với VARCHAR parameter → SQL Server phải convert toàn bộ cột sang VARCHAR, làm mất khả năng dùng index. Giải pháp: đảm bảo parameter và column có cùng kiểu dữ liệu, dùng N'' prefix cho Unicode strings.

Q16: Covering Index và Key Lookup liên quan thế nào?

A: Key Lookup xảy ra khi SQL Server tìm rows qua Non-Clustered Index nhưng cần thêm cột không có trong index → phải quay về Clustered Index/Heap để lấy. Đây là Bookmark Lookup. Mỗi Key Lookup là một round-trip tốn kém. Covering Index loại bỏ Key Lookup bằng cách thêm các cột cần thiết vào INCLUDE.

Q17: Columnstore Index phù hợp cho workload nào?

A: Columnstore Index tối ưu cho OLAP/analytical workloads: aggregations (SUM, AVG, COUNT), GROUP BY, wide table scans. Lý do: compression tốt hơn (5-10x), batch mode execution, column pruning (chỉ đọc cột cần). Không phù hợp cho OLTP với nhiều point lookups và single-row updates/inserts (delta store overhead).

Senior Level

Q18: Giải thích cơ chế Plan Cache và khi nào plan bị evict hoặc recompile?

A: SQL Server lưu execution plans trong Plan Cache (một phần của buffer pool). Plan được identify bằng hash của query text. Khi query mới match hash, dùng lại plan (avoid expensive compilation).

Plan bị evict khi:

• Memory pressure (cần RAM cho dữ liệu)
• DBCC FREEPROCCACHE
• Đủ điều kiện memory pressure eviction (least recently used)

Plan bị recompile khi:

• Schema change (ALTER TABLE, CREATE INDEX)
• Statistics change (threshold: 20% rows + 500 modified)
• SET options thay đổi
• sp_recompile hoặc OPTION (RECOMPILE) hint

Q19: Giải thích Columnstore Delta Store và Tuple Mover hoạt động thế nào?

A: Khi INSERT vào Columnstore table:

1. Rows mới đi vào Delta Store (row-store B-tree nhỏ trong TempDB/data file)
2. Delta Store tích lũy đến ~1 triệu rows
3. Tuple Mover (background process) compress và chuyển Delta Store → Column Segments (read-only, highly compressed)
4. Deleted rows được đánh dấu trong Delete Bitmap (không xóa ngay khỏi segments)

Khi REBUILD Columnstore Index → Delta Stores và Delete Bitmaps được flush, tất cả merge thành segments mới, reclaim không gian.

Q20: Wait statistics là gì? Cách dùng để diagnose performance vấn đề?

A: SQL Server track thời gian mỗi task phải chờ resource (sys.dm_os_wait_stats). Phân tích top waits giúp xác định bottleneck:

• PAGEIOLATCH: I/O bottleneck → thêm RAM, optimize queries, faster disk
• LCK_M_X: lock contention → shorten transactions, optimize isolation level
• CXPACKET: parallelism overhead → tăng cost threshold, giảm MAXDOP
• ASYNCH_NETWORK_IO: client chậm đọc → reduce result set, pagination
• SOS_SCHEDULER_YIELD: CPU pressure → optimize CPU-heavy queries, thêm CPU

Approach: reset waits (DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR)), run workload 30 phút, check top waits lại → targeted investigation.

Q21: Hash Join Spill là gì và làm thế nào để tránh?

A: Hash Join Spill xảy ra khi SQL Server không có đủ memory để giữ hash table trong RAM → phải spill sang TempDB (disk). Điều này tăng I/O dramatically và làm query chậm.

Nguyên nhân:

1. Cardinality estimate quá thấp (statistics lỗi thời) → cấp ít memory grant
2. Query thực sự xử lý dữ liệu rất lớn

Giải pháp:

1. Update statistics
2. Thêm/sửa indexes để reduce rows trước khi join
3. Tăng memory grant hint: OPTION (MIN_GRANT_PERCENT = 50)
4. Tăng server memory
5. Dùng Query Store để detect và force better plan

Q22: Query Store có gì tốt hơn Extended Events để track performance?

A: Query Store (SQL 2016+) tự động persist query text, plans và runtime stats vào database catalog - không cần setup trace session. Cho phép:

• So sánh plan thay đổi theo thời gian (plan regression detection)
• Force plan cụ thể khi có regression
• Identify “regressed queries” tự động (SQL 2022 Intelligent Query Processing)
• View qua SSMS GUI hoặc sys.query_store_* views

Extended Events tốt hơn khi cần real-time capture, filter chi tiết (theo database, user, host), capture events không có trong Query Store (locking, deadlock, etc.).

Q23: In-Memory OLTP indexes khác traditional indexes thế nào?

A:

• Hash Index: dùng cho equality lookups, O(1), không sort. PHẢI ước tính BUCKET_COUNT chính xác (too low → collision, too high → wasted memory). Không hỗ trợ range, ORDER BY.
• Nonclustered Range Index: Bw-tree (lock-free B-tree variant). Hỗ trợ range và ORDER BY. O(log N).
• Không có clustered index: Memory-optimized tables không có clustered index concept. Data là heap trong memory, access qua indexes.
• Lock-free: All indexes dùng optimistic concurrency, MVCC - không có page latches hay traditional locks.

Q24: Giải thích MAXDOP và Cost Threshold for Parallelism, nên set về giá trị bao nhiêu?

A:

• MAXDOP (Max Degree of Parallelism): số CPU threads tối đa cho một query. Default 0 = tất cả CPUs.
• Cost Threshold for Parallelism: estimated cost threshold để SQL Server mới xem xét parallel plan. Default 5 (rất thấp, gây nhiều small queries đi parallel không cần thiết).

Recommendations:

• Cost Threshold: tăng lên 25-50 cho OLTP workloads (giảm unnecessary parallelism overhead)
• MAXDOP OLTP: = số cores per NUMA node hoặc 8 (lấy số nhỏ hơn)
• MAXDOP DWH: 0 hoặc số cores per socket

Từ SQL Server 2022: ALTER DATABASE SCOPED CONFIGURATION cho phép set per-database.

Q25: Tại sao NOT IN nguy hiểm khi có NULL? Giải thích bằng SQL logic ba giá trị?

A: SQL dùng three-valued logic: TRUE, FALSE, và UNKNOWN. Khi so sánh với NULL, kết quả là UNKNOWN (không phải FALSE).

x NOT IN (1, 2, NULL) được evaluate như: NOT (x = 1 OR x = 2 OR x = NULL) = NOT (x = 1 OR x = 2 OR UNKNOWN) = NOT (UNKNOWN) (khi x ≠ 1 và x ≠ 2) = UNKNOWN

WHERE chỉ cho qua rows với UNKNOWN = TRUE. UNKNOWN rows bị loại. Kết quả: không hàng nào được trả về dù logic bạn muốn là “x không có trong danh sách”. Luôn dùng NOT EXISTS thay thế.

Q26: Giải thích cơ chế Statistics trong SQL Server và khi nào bị outdated?

A: Statistics là histogram mô tả phân phối dữ liệu của một column. SQL Server dùng statistics để ước tính cardinality (số rows mỗi operator trả về), từ đó chọn join algorithm, index, và memory grant.

Statistics tự động update khi:

• 20% của rows trong bảng bị modify (+ 500 rows cho bảng nhỏ)
• Với trace flag 2371 hoặc SQL 2016+: dynamic threshold cho bảng lớn

Statistics có thể không đủ chính xác khi:

1. Data distribution lệch (skewed) - histogram chỉ có 200 steps
2. Nhiều NULL values
3. Correlated columns (stats độc lập nhau, không track correlation)
4. Ascending key problem (new values ngoài histogram range)

Giải pháp: UPDATE STATISTICS ... WITH FULLSCAN, enable Auto Update Statistics Async.

Q27: Concurrent index rebuild có thể làm gì? Hạn chế là gì?

A: ALTER INDEX ... REBUILD WITH (ONLINE = ON) (Enterprise Edition) cho phép rebuild không block reads/writes:

• Dùng row versioning để maintain cả hai copies trong quá trình rebuild
• Schema Modification Lock (SCH-M) chỉ lấy ở đầu và cuối (rất ngắn)
• Tốn thêm disk space (phải giữ cả old và new index cùng lúc)
• Chậm hơn offline rebuild
• Không available trên Standard Edition
• Không available cho Columnstore indexes (dùng REORGANIZE hoặc offline)

Q28: Giải thích sự khác biệt giữa Seek Predicate và Predicate trong execution plan?

A:

• Seek Predicate: phần predicate SQL Server dùng để navigate B-tree (true seek). Rất hiệu quả - chỉ đọc relevant leaf pages.
• Predicate (Residual predicate): phần predicate được apply sau khi đã seek đến leaf pages, để filter thêm các rows đọc được. Kém hiệu quả hơn vì phải đọc rồi mới filter.

Ví dụ với Index (CustomerId, Status):

WHERE CustomerId = 100 AND Status = 'Active' AND TotalAmount > 500
-- Seek Predicate: CustomerId = 100 AND Status = 'Active' (cả hai key columns)
-- Residual Predicate: TotalAmount > 500 (không phải key column)

Mục tiêu tối ưu: đưa càng nhiều predicate vào Seek Predicate càng tốt (thêm cột vào index key hoặc adjust index).

Q29: Khi nào nên dùng Table Variable thay Temp Table và ngược lại?

A: Table Variable tốt hơn khi:

• < 100 rows (thường)
• Trong function (bắt buộc dùng table variable)
• Cần transactions riêng (không bị rollback khi outer TX rollback)
• Đơn giản, không cần indexes phức tạp

Temp Table tốt hơn khi:

• 1000 rows (statistics giúp optimizer)

• Cần explicit indexes
• JOIN phức tạp với temp data (optimizer có statistics ước tính đúng hơn)
• Cần dùng trong nhiều batches/procedures

Vấn đề chính của Table Variable: optimizer luôn ước tính 1 row (SQL 2017 trở lên có Deferred Compilation cải thiện phần nào). Điều này gây wrong join algorithm nếu thực tế có nhiều rows.

Q30: Làm thế nào phân tích và fix một query đột ngột chạy chậm trên production?

A: Quy trình điều tra:

1. Query Store (SQL 2016+): kiểm tra “Regressed Queries” trong SSMS hoặc:

SELECT q.query_id, qt.query_sql_text, rs.avg_duration, p.plan_id
FROM sys.query_store_query q
INNER JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id
INNER JOIN sys.query_store_plan p ON q.query_id = p.query_id
INNER JOIN sys.query_store_runtime_stats rs ON p.plan_id = rs.plan_id
WHERE rs.last_execution_time > DATEADD(HOUR, -2, GETUTCDATE())
ORDER BY rs.avg_duration DESC;

2. So sánh plans: xem plan mới vs plan cũ có gì khác (join algorithm thay đổi, index mới/bị xóa)

3. Check statistics: sys.dm_db_stats_properties - xem modification_counter cao → update statistics

4. Check blocking/locks: sys.dm_exec_requests với blocking_session_id

5. Check execution plan hiện tại: sys.dm_exec_query_plan - có key lookup không cần thiết, bad join không?

6. Quick fix: EXEC sp_recompile 'ProcName' hoặc force plan qua Query Store

7. Root cause: update statistics, thêm/sửa index, fix parameter sniffing, hoặc code fix

Index Cơ Bản

Index là cấu trúc dữ liệu đặc biệt giúp SQL Server tìm kiếm và truy cập dữ liệu nhanh hơn nhiều so với quét toàn bộ bảng. Hiểu index đúng là yếu tố quyết định hiệu suất của ứng dụng database.

1. Tại sao cần Index?

Không có index, SQL Server phải thực hiện Table Scan - đọc toàn bộ mọi trang dữ liệu của bảng từ đầu đến cuối. Với bảng hàng triệu hàng, điều này cực kỳ tốn kém.

B-tree Structure

SQL Server dùng cấu trúc B-tree (Balanced Tree) cho hầu hết loại index:

                    [Root Page]
                   /     |      \
          [Branch]   [Branch]   [Branch]
          /    \     /    \     /    \
       [Leaf] [Leaf] [Leaf] [Leaf] [Leaf] [Leaf]
         ↓      ↓      ↓      ↓      ↓      ↓
       Data   Data   Data   Data   Data   Data

• Root page: điểm xuất phát tìm kiếm
• Branch pages: định hướng tìm kiếm
• Leaf pages: chứa dữ liệu thực (clustered) hoặc row pointer (non-clustered)

Seek vs Scan

2. Clustered Index

Khái niệm

Clustered Index quyết định thứ tự vật lý lưu trữ dữ liệu trong bảng. Leaf pages của clustered index chứa chính data rows.

• Mỗi bảng chỉ có tối đa 1 clustered index
• Khi tạo PRIMARY KEY, SQL Server mặc định tạo clustered index trên đó

-- Tạo clustered index tường minh
CREATE CLUSTERED INDEX CIX_Orders_OrderId ON Orders (OrderId);

-- PRIMARY KEY tự động tạo clustered index
CREATE TABLE Orders (
    OrderId INT PRIMARY KEY,  -- → Clustered index tự động
    OrderDate DATETIME,
    CustomerId INT
);

-- Tạo PRIMARY KEY nhưng NON-clustered
CREATE TABLE Orders (
    OrderId INT PRIMARY KEY NONCLUSTERED,  -- Primary key không phải clustered
    OrderDate DATETIME,
    CustomerId INT
);

Heap vs Clustered Table

-- Kiểm tra bảng có clustered index không (heap nếu type_desc = HEAP)
SELECT 
    t.name AS TableName,
    i.name AS IndexName,
    i.type_desc
FROM sys.tables t
LEFT JOIN sys.indexes i ON t.object_id = i.object_id AND i.type <= 1
ORDER BY t.name;

Chọn Clustered Index Key tốt

Một clustered index key tốt cần:

-- ✅ Tốt: INT IDENTITY - hẹp, unique, tăng dần
CREATE TABLE Orders (
    OrderId INT IDENTITY(1,1) PRIMARY KEY,
    ...
);

-- ❌ Kém: GUID ngẫu nhiên - random insert gây fragmentation cao
CREATE TABLE Orders (
    OrderId UNIQUEIDENTIFIER DEFAULT NEWID() PRIMARY KEY,
    ...
);

-- ✅ Dùng NEWSEQUENTIALID() nếu cần GUID
CREATE TABLE Orders (
    OrderId UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY,
    ...
);

3. Non-Clustered Index (NCX)

Khái niệm

Non-Clustered Index là cấu trúc B-tree riêng biệt với bảng dữ liệu:

• Leaf pages chứa key columns + row locator (clustered key hoặc RID)
• Mỗi bảng có thể có tối đa 999 non-clustered indexes

-- Tạo non-clustered index
CREATE NONCLUSTERED INDEX IX_Orders_CustomerId 
ON Orders (CustomerId);

-- Với included columns
CREATE NONCLUSTERED INDEX IX_Orders_CustomerId_Include
ON Orders (CustomerId)
INCLUDE (OrderDate, TotalAmount);

-- Composite key
CREATE NONCLUSTERED INDEX IX_OrderDetails_Composite
ON OrderDetails (OrderId, ProductId);

Key Columns vs Included Columns

Leaf Page của NCX:
┌─────────────────────────────────────────────┐
│ Key Column(s): CustomerId                   │
│ Included Columns: OrderDate, TotalAmount    │  ← Chỉ ở leaf level
│ Row Locator: OrderId (clustered key)        │
└─────────────────────────────────────────────┘

• Key columns: xuất hiện ở tất cả levels của B-tree, dùng cho seeking và sorting
• Included columns: chỉ ở leaf level, không dùng để seek nhưng tránh key lookup

-- Query này có thể được thỏa mãn hoàn toàn bởi index (covering index)
SELECT CustomerId, OrderDate, TotalAmount  -- Covered!
FROM Orders
WHERE CustomerId = 12345;                  -- Seek trên CustomerId

-- Nếu index không có TotalAmount → key lookup xảy ra
-- Với INCLUDE (TotalAmount) → không cần lookup

4. Index Pages: Page Splits và Fill Factor

Page Structure

SQL Server lưu dữ liệu theo pages 8KB. Mỗi page chứa nhiều rows.

Page Split

Khi INSERT vào giữa một clustered index mà page đã đầy:

1. SQL Server phải tạo page mới
2. Di chuyển ~50% dữ liệu sang page mới
3. Update pointer chain → tốn I/O, gây fragmentation

Trước split:        Sau split:
┌──────────┐        ┌──────────┐    ┌──────────┐
│  1, 2, 3 │  →    │  1, 2    │ →  │  2.5, 3  │
│  (full)  │        │ (50%)    │    │  (50%)   │
└──────────┘        └──────────┘    └──────────┘

Fill Factor

Fill Factor xác định % không gian trống để lại trên mỗi leaf page khi rebuild/create index.

-- Tạo index với fill factor 80% (20% để trống cho insert sau)
CREATE INDEX IX_Orders_OrderDate ON Orders (OrderDate)
WITH (FILLFACTOR = 80);

-- Rebuild với fill factor mới
ALTER INDEX IX_Orders_OrderDate ON Orders
REBUILD WITH (FILLFACTOR = 80);

-- Kiểm tra fill factor của các index
SELECT 
    i.name,
    i.fill_factor
FROM sys.indexes i
WHERE i.object_id = OBJECT_ID('Orders');

5. Covering Index

Một index được gọi là Covering Index khi nó chứa tất cả các cột mà query cần - không cần quay về bảng gốc để lấy thêm dữ liệu.

-- Query cần: WHERE CustomerId, SELECT OrderId, OrderDate, TotalAmount
SELECT OrderId, OrderDate, TotalAmount
FROM Orders
WHERE CustomerId = 12345
  AND OrderDate >= '2024-01-01';

-- ✅ Covering Index cho query trên
CREATE INDEX IX_Orders_Cover
ON Orders (CustomerId, OrderDate)     -- Key: dùng để seek + filter
INCLUDE (OrderId, TotalAmount);       -- Included: chỉ cần ở SELECT

-- ❌ Non-covering: chỉ có CustomerId
-- → SQL Server phải làm Key Lookup cho mỗi hàng tìm được
CREATE INDEX IX_Orders_CustomerId ON Orders (CustomerId);

Key Lookup vs Covering

-- Kiểm tra key lookup trong execution plan
-- Tìm queries có nhiều key lookups
SELECT TOP 20
    qs.execution_count,
    qs.total_logical_reads,
    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(qt.text)
          ELSE qs.statement_end_offset END - qs.statement_start_offset)/2)+1) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY qs.total_logical_reads DESC;

6. Index Seek vs Index Scan vs Table Scan

Index Seek

SQL Server đi qua B-tree từ root đến leaf để tìm đúng rows. Xảy ra khi:

• Có SARGable predicate (Search ARGument ABLE)
• Predicate match với leading key column của index

SARGable vs Non-SARGable

SARGable là predicate mà SQL Server có thể dùng để tìm kiếm trong index.

-- ✅ SARGable - có thể dùng index seek
WHERE CustomerId = 12345
WHERE OrderDate >= '2024-01-01'
WHERE LastName LIKE 'Nguyen%'     -- leading wildcard không có → SARGable
WHERE Price BETWEEN 100 AND 500

-- ❌ Non-SARGable - buộc index/table scan
WHERE YEAR(OrderDate) = 2024              -- Hàm trên cột
WHERE LEFT(LastName, 3) = 'Ngu'          -- Hàm trên cột
WHERE UPPER(Email) = 'TEST@GMAIL.COM'    -- Hàm trên cột
WHERE LastName LIKE '%Nguyen'             -- Leading wildcard
WHERE Price + 10 > 200                    -- Biểu thức trên cột
WHERE CAST(OrderId AS VARCHAR) = '123'   -- Implicit/explicit cast

-- ✅ Cách viết lại SARGable
-- Thay YEAR(OrderDate) = 2024
WHERE OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01'

-- Thay UPPER(Email) = 'TEST@GMAIL.COM'
-- Giải pháp: dùng collation case-insensitive (mặc định SQL Server)
WHERE Email = 'test@gmail.com'   -- CI collation → tự động case-insensitive

Khi SQL Server chọn Scan thay vì Seek

-- SQL Server chọn scan khi:
-- 1. Ước tính % rows được trả về cao (thường > 5-30%)
-- 2. Predicate không SARGable
-- 3. Không có thống kê tốt
-- 4. Index không phù hợp với query

-- Kiểm tra selectivity
SELECT 
    COUNT(DISTINCT CustomerId) * 1.0 / COUNT(*) AS Selectivity
FROM Orders;
-- Selectivity gần 1 = index seek rất hiệu quả
-- Selectivity gần 0 = có thể scan tốt hơn

7. Missing Index Recommendations

SQL Server tự động thu thập thông tin về các index mà nó “muốn có” trong sys.dm_db_missing_index_* DMVs.

-- Truy vấn missing indexes được khuyến nghị (sắp xếp theo impact)
SELECT TOP 20
    mid.statement AS TableName,
    migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) AS improvement_measure,
    migs.user_seeks,
    migs.user_scans,
    migs.avg_total_user_cost,
    migs.avg_user_impact,
    mid.equality_columns,
    mid.inequality_columns,
    mid.included_columns,
    -- Tạo lệnh CREATE INDEX gợi ý
    'CREATE INDEX IX_' + 
        REPLACE(REPLACE(mid.statement, '[', ''), ']', '') + '_' +
        ISNULL(REPLACE(mid.equality_columns, ', ', '_'), '') +
        ' ON ' + mid.statement + 
        ' (' + ISNULL(mid.equality_columns, '') + 
        CASE WHEN mid.inequality_columns IS NOT NULL 
             THEN CASE WHEN mid.equality_columns IS NOT NULL THEN ', ' ELSE '' END + mid.inequality_columns 
             ELSE '' END + ')' +
        ISNULL(' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON mig.index_group_handle = migs.group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE mid.database_id = DB_ID()
ORDER BY improvement_measure DESC;

Cảnh báo: Đừng tạo tất cả suggested indexes mù quáng. Cân nhắc:

• Có bị overlap với index hiện có không?
• Có thực sự cần thiết không (improvement_measure đủ cao)?
• Tổng số indexes không nên quá nhiều → ảnh hưởng write performance

8. Index Maintenance: REBUILD vs REORGANIZE

Kiểm tra Fragmentation

-- Kiểm tra mức độ fragmentation của tất cả index trong database
SELECT 
    t.name AS TableName,
    i.name AS IndexName,
    ips.index_type_desc,
    ips.avg_fragmentation_in_percent,
    ips.page_count
FROM sys.dm_db_index_physical_stats(
    DB_ID(),      -- Database ID (NULL = tất cả DB)
    NULL,         -- Object ID (NULL = tất cả tables)
    NULL,         -- Index ID (NULL = tất cả indexes)
    NULL,         -- Partition number
    'LIMITED'     -- Mode: LIMITED, SAMPLED, DETAILED
) ips
INNER JOIN sys.tables t ON ips.object_id = t.object_id
INNER JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE ips.page_count > 100   -- Chỉ xem index đủ lớn
ORDER BY ips.avg_fragmentation_in_percent DESC;

REORGANIZE vs REBUILD

-- REORGANIZE (online, ít lock)
ALTER INDEX IX_Orders_CustomerId ON Orders REORGANIZE;

-- REBUILD (offline, defragment hoàn toàn)
ALTER INDEX IX_Orders_CustomerId ON Orders REBUILD;

-- REBUILD ONLINE (SQL Server Enterprise)
ALTER INDEX IX_Orders_CustomerId ON Orders REBUILD WITH (ONLINE = ON);

-- REBUILD tất cả indexes của bảng
ALTER INDEX ALL ON Orders REBUILD WITH (FILLFACTOR = 85);

-- Script auto-maintain dựa trên fragmentation
DECLARE @fragmentation FLOAT;

SELECT @fragmentation = avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('Orders'), 
    INDEXPROPERTY(OBJECT_ID('Orders'), 'IX_Orders_CustomerId', 'IndexID'), NULL, 'LIMITED');

IF @fragmentation > 30
    ALTER INDEX IX_Orders_CustomerId ON Orders REBUILD;
ELSE IF @fragmentation > 10
    ALTER INDEX IX_Orders_CustomerId ON Orders REORGANIZE;

9. sys.indexes - Querying Index Metadata

-- Xem tất cả indexes của một bảng
SELECT 
    i.name AS IndexName,
    i.type_desc AS IndexType,
    i.is_unique,
    i.is_primary_key,
    i.fill_factor,
    -- Key columns
    STRING_AGG(
        CASE WHEN ic.is_included_column = 0 THEN c.name END, ', '
    ) WITHIN GROUP (ORDER BY ic.key_ordinal) AS KeyColumns,
    -- Included columns
    STRING_AGG(
        CASE WHEN ic.is_included_column = 1 THEN c.name END, ', '
    ) AS IncludedColumns
FROM sys.indexes i
INNER JOIN sys.index_columns ic ON i.object_id = ic.object_id AND i.index_id = ic.index_id
INNER JOIN sys.columns c ON ic.object_id = c.object_id AND ic.column_id = c.column_id
WHERE i.object_id = OBJECT_ID('Orders')
GROUP BY i.name, i.type_desc, i.is_unique, i.is_primary_key, i.fill_factor
ORDER BY i.type_desc, i.name;

-- Xem index usage statistics
SELECT 
    i.name AS IndexName,
    i.type_desc,
    ius.user_seeks,
    ius.user_scans,
    ius.user_lookups,
    ius.user_updates,
    ius.last_user_seek,
    ius.last_user_scan
FROM sys.indexes i
LEFT JOIN sys.dm_db_index_usage_stats ius 
    ON i.object_id = ius.object_id 
    AND i.index_id = ius.index_id 
    AND ius.database_id = DB_ID()
WHERE i.object_id = OBJECT_ID('Orders')
ORDER BY (ISNULL(ius.user_seeks, 0) + ISNULL(ius.user_scans, 0)) DESC;

-- Tìm các index không được dùng (candidates for removal)
SELECT 
    t.name AS TableName,
    i.name AS IndexName,
    ius.user_seeks,
    ius.user_scans,
    ius.user_updates,
    ius.last_user_seek
FROM sys.indexes i
INNER JOIN sys.tables t ON i.object_id = t.object_id
LEFT JOIN sys.dm_db_index_usage_stats ius 
    ON i.object_id = ius.object_id 
    AND i.index_id = ius.index_id 
    AND ius.database_id = DB_ID()
WHERE i.type_desc = 'NONCLUSTERED'
  AND i.is_primary_key = 0
  AND i.is_unique_constraint = 0
  AND (ius.user_seeks IS NULL OR ius.user_seeks = 0)   -- Chưa từng được seek
  AND (ius.user_scans IS NULL OR ius.user_scans = 0)   -- Chưa từng được scan
ORDER BY ISNULL(ius.user_updates, 0) DESC;  -- Vẫn tốn chi phí maintain

Index Nâng Cao

1. Filtered Index (Index có điều kiện WHERE)

Filtered Index là non-clustered index được xây dựng chỉ trên một tập con hàng thỏa mãn điều kiện WHERE. Kết quả: index nhỏ hơn, hiệu quả hơn, ít maintenance hơn.

-- Ví dụ 1: Chỉ index các đơn hàng chưa hoàn thành
CREATE NONCLUSTERED INDEX IX_Orders_Pending
ON Orders (OrderDate, CustomerId)
INCLUDE (TotalAmount)
WHERE Status = 'Pending';   -- Filtered predicate

-- Ví dụ 2: Soft delete - chỉ index active records
CREATE NONCLUSTERED INDEX IX_Products_Active
ON Products (CategoryId, Price)
WHERE IsDeleted = 0;

-- Ví dụ 3: Sparse column - chỉ index hàng có giá trị (không NULL)
CREATE NONCLUSTERED INDEX IX_Employees_Email
ON Employees (Email)
WHERE Email IS NOT NULL;

Khi nào dùng Filtered Index

-- Filtered Unique Index: Email phải unique giữa các active users
CREATE UNIQUE NONCLUSTERED INDEX UIX_Users_Email_Active
ON Users (Email)
WHERE IsDeleted = 0;

-- Filtered index CHỈ được dùng khi query có predicate tương thích
-- Ví dụ: query này SẼ dùng IX_Orders_Pending
SELECT OrderId, OrderDate, CustomerId, TotalAmount
FROM Orders
WHERE Status = 'Pending'          -- ✅ Match filtered predicate
  AND OrderDate >= '2024-01-01';

-- Query này KHÔNG dùng IX_Orders_Pending (không có WHERE Status = 'Pending')
SELECT OrderId FROM Orders WHERE CustomerId = 123;

2. Columnstore Index

Columnstore Index lưu dữ liệu theo cột thay vì theo hàng - tối ưu cho analytical queries (OLAP) với aggregation trên nhiều hàng.

Clustered Columnstore Index (CCI)

Thay thế hoàn toàn table heap/clustered row-store.

-- Tạo bảng với Clustered Columnstore Index
CREATE TABLE FactSales (
    SaleId BIGINT,
    ProductId INT,
    CustomerId INT,
    SaleDate DATE,
    Quantity INT,
    UnitPrice DECIMAL(18,2),
    TotalAmount DECIMAL(18,2)
);

CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSales ON FactSales;

-- Hoặc khi tạo bảng (SQL Server 2022+)
-- WITH (CLUSTERED COLUMNSTORE INDEX)

Non-Clustered Columnstore Index (NCCI)

Thêm analytical capability vào bảng OLTP mà không thay đổi row-store.

-- Thêm NCCI vào bảng Orders OLTP để hỗ trợ reporting queries
CREATE NONCLUSTERED COLUMNSTORE INDEX NCCI_Orders_Analytics
ON Orders (OrderDate, CustomerId, ProductId, TotalAmount, Status);

Cơ chế hoạt động

Columnstore Storage (theo cột):
ProductId column:  [1, 1, 2, 3, 3, 3, 5, 5, ...]  → Compress tốt (giá trị lặp lại)
SaleDate column:   [2024-01-01, 2024-01-01, ...]   → RLE compression
TotalAmount column:[99.99, 149.00, 49.99, ...]

Row-store (theo hàng):
Row 1: [1, 1, 2024-01-01, 99.99, ...]
Row 2: [1, 1, 2024-01-01, 149.00, ...]

Delta Store & Tuple Mover

Khi INSERT vào Columnstore:
1. Rows mới → Delta Store (row-store B-tree, nhỏ)
2. Khi Delta Store đủ lớn (~1M rows)
3. Tuple Mover (background) compress và chuyển vào Column Segments
4. Deleted rows → Delete Bitmap (không xóa ngay)

-- Kiểm tra trạng thái Delta Store và Deleted rows
SELECT 
    i.name,
    rg.state_desc,
    rg.total_rows,
    rg.deleted_rows,
    rg.size_in_bytes
FROM sys.column_store_row_groups rg
INNER JOIN sys.indexes i ON rg.object_id = i.object_id AND rg.index_id = i.index_id
WHERE rg.object_id = OBJECT_ID('FactSales');

Batch Mode Execution

Columnstore kích hoạt Batch Mode: xử lý 64-900 hàng cùng lúc thay vì từng hàng. Kết hợp với SIMD CPU instructions → nhanh hơn 5-100x cho analytical queries.

-- Query analytical hưởng lợi từ CCI + Batch Mode
SELECT 
    ProductId,
    YEAR(SaleDate) AS SaleYear,
    SUM(TotalAmount) AS Revenue,
    COUNT(*) AS TxnCount
FROM FactSales
GROUP BY ProductId, YEAR(SaleDate)
ORDER BY Revenue DESC;

3. Full-Text Index

Full-Text Index cho phép tìm kiếm ngôn ngữ tự nhiên trong văn bản - không thể làm được với LIKE hoặc standard index.

-- Bước 1: Tạo Full-Text Catalog
CREATE FULLTEXT CATALOG ftCatalog AS DEFAULT;

-- Bước 2: Tạo Full-Text Index
CREATE FULLTEXT INDEX ON Products (ProductName, Description)
KEY INDEX PK_Products  -- Phải có unique index
ON ftCatalog
WITH STOPLIST = SYSTEM;  -- Dùng stopword list mặc định

-- CONTAINS: tìm kiếm chính xác
SELECT ProductId, ProductName
FROM Products
WHERE CONTAINS(ProductName, 'laptop');

-- CONTAINS với nhiều từ
WHERE CONTAINS(Description, '"high performance" AND "gaming"')

-- FREETEXT: tìm kiếm ngôn ngữ tự nhiên (stemming, synonyms)
WHERE FREETEXT(Description, 'fast computer processor')

-- CONTAINSTABLE: trả về ranking
SELECT p.ProductId, p.ProductName, ft.RANK
FROM Products p
INNER JOIN CONTAINSTABLE(Products, Description, 'gaming laptop') ft
    ON p.ProductId = ft.[KEY]
ORDER BY ft.RANK DESC;

LIKE vs Full-Text

4. XML Index

Cho bảng có cột kiểu XML - tăng tốc XQuery và XPath expressions.

-- Bảng với cột XML
CREATE TABLE Orders (
    OrderId INT PRIMARY KEY,
    OrderDetails XML
);

-- Primary XML Index: bắt buộc tạo trước
CREATE PRIMARY XML INDEX PXML_Orders_Details
ON Orders (OrderDetails);

-- Secondary XML Indexes (tùy loại query)
CREATE XML INDEX SXML_Orders_PATH   ON Orders (OrderDetails) USING XML INDEX PXML_Orders_Details FOR PATH;
CREATE XML INDEX SXML_Orders_VALUE  ON Orders (OrderDetails) USING XML INDEX PXML_Orders_Details FOR VALUE;
CREATE XML INDEX SXML_Orders_PROPERTY ON Orders (OrderDetails) USING XML INDEX PXML_Orders_Details FOR PROPERTY;

5. Spatial Index

Cho cột kiểu GEOMETRY hoặc GEOGRAPHY.

-- Bảng với cột Geography
CREATE TABLE Locations (
    LocationId INT PRIMARY KEY,
    Name NVARCHAR(100),
    GeoPoint GEOGRAPHY
);

INSERT INTO Locations VALUES 
    (1, 'Hanoi', geography::STPointFromText('POINT(105.8412 21.0278)', 4326)),
    (2, 'Saigon', geography::STPointFromText('POINT(106.6297 10.8231)', 4326));

CREATE SPATIAL INDEX SIX_Locations_GeoPoint
ON Locations (GeoPoint)
USING GEOGRAPHY_GRID
WITH (GRIDS = (MEDIUM, MEDIUM, MEDIUM, MEDIUM), CELLS_PER_OBJECT = 16);

-- Query tìm locations trong vòng 10km từ một điểm
DECLARE @center GEOGRAPHY = geography::STPointFromText('POINT(105.8412 21.0278)', 4326);

SELECT Name, GeoPoint.STDistance(@center) AS DistanceMeters
FROM Locations
WHERE GeoPoint.STDistance(@center) <= 10000
ORDER BY DistanceMeters;

6. Unique Index

Đảm bảo không có giá trị trùng lặp trong cột/nhóm cột được index.

-- Unique index đơn giản
CREATE UNIQUE NONCLUSTERED INDEX UIX_Users_Email
ON Users (Email);

-- Unique index cho composite key
CREATE UNIQUE NONCLUSTERED INDEX UIX_Products_Category_Code
ON Products (CategoryId, ProductCode);

-- Xử lý NULL: Unique index cho phép nhiều NULL
-- (NULL != NULL trong SQL logic)
INSERT INTO Users (Email) VALUES (NULL);
INSERT INTO Users (Email) VALUES (NULL);  -- ✅ Thành công! NULL không vi phạm unique

-- Nếu muốn NULL cũng unique → dùng Filtered Index
CREATE UNIQUE NONCLUSTERED INDEX UIX_Users_Email_NotNull
ON Users (Email)
WHERE Email IS NOT NULL;

7. Index with INCLUDE Columns (Covering Index)

-- Composite key với INCLUDE: cân bằng between seek efficiency và covering
CREATE NONCLUSTERED INDEX IX_Orders_Customer_Date
ON Orders (CustomerId, OrderDate)   -- Key: dùng để seek, có thứ tự
INCLUDE (OrderId, Status, TotalAmount);  -- Chỉ ở leaf, không ảnh hưởng B-tree height

-- Tại sao không đưa tất cả vào key?
-- Key columns: xuất hiện ở mọi levels → làm B-tree rộng hơn → nhiều page hơn
-- INCLUDE: chỉ ở leaf level → không làm to B-tree → space hiệu quả hơn

Quyết định đưa cột vào Key hay INCLUDE

8. Composite Index: Thứ tự cột quan trọng

Column order trong composite index ảnh hưởng trực tiếp đến query nào có thể dùng index.

-- Index: (CustomerId, OrderDate, Status)
CREATE INDEX IX_Orders ON Orders (CustomerId, OrderDate, Status);

-- ✅ Có thể dùng index (leading columns match)
WHERE CustomerId = 100
WHERE CustomerId = 100 AND OrderDate = '2024-01-01'
WHERE CustomerId = 100 AND OrderDate BETWEEN '2024-01-01' AND '2024-12-31'
WHERE CustomerId = 100 AND OrderDate = '2024-01-01' AND Status = 'Active'

-- ⚠️ Partial use (chỉ dùng CustomerId cho seek, Status filter sau)
WHERE CustomerId = 100 AND Status = 'Active'  -- Bỏ qua OrderDate

-- ❌ KHÔNG thể dùng index seek (không có leading column)
WHERE OrderDate = '2024-01-01'
WHERE Status = 'Active'

Nguyên tắc chọn thứ tự cột

1. Equality first: Cột dùng = đặt trước
2. Range last: Cột dùng >, <, BETWEEN đặt sau
3. Selectivity: Cột có nhiều distinct values → seek hiệu quả hơn
4. ORDER BY / GROUP BY: Nếu order match với index → tránh Sort operator

-- Query: WHERE Status = 'Active' AND CreatedDate > '2024-01-01'
-- Status có 3 giá trị, CreatedDate rất nhiều giá trị

-- Option A: (Status, CreatedDate) → seek trên Status=Active, range scan CreatedDate
-- Option B: (CreatedDate, Status) → range scan CreatedDate, filter Status
-- → Option A thường tốt hơn vì seek trên equality trước

9. Index Intersection vs Index Covering

Index Intersection

SQL Server dùng nhiều indexes cho cùng một query và merge kết quả (AND/OR).

-- Có 2 indexes riêng
CREATE INDEX IX_Orders_CustomerId ON Orders (CustomerId);
CREATE INDEX IX_Orders_Status ON Orders (Status);

-- Query sau có thể trigger Index Intersection
WHERE CustomerId = 100 AND Status = 'Active';
-- SQL Server: seek IX_Orders_CustomerId → get OrderIds
--             seek IX_Orders_Status → get OrderIds
--             INTERSECT hai tập → key lookup cho rows trong cả hai

Index Covering vs Index Intersection

10. In-Memory OLTP Indexes (Memory-Optimized Tables)

In-Memory OLTP tables (Hekaton) dùng các loại index khác hoàn toàn.

-- Tạo memory-optimized table
CREATE TABLE dbo.SessionCache (
    SessionId NVARCHAR(100) NOT NULL,
    UserId INT NOT NULL,
    Data NVARCHAR(MAX),
    CreatedAt DATETIME2 NOT NULL,
    CONSTRAINT PK_SessionCache PRIMARY KEY NONCLUSTERED HASH (SessionId)
        WITH (BUCKET_COUNT = 1000000)
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY);

Hash Index (In-Memory)

-- Hash Index: O(1) point lookup, không hỗ trợ range
CONSTRAINT PK_Session PRIMARY KEY NONCLUSTERED HASH (SessionId)
    WITH (BUCKET_COUNT = 1000000);  -- Phải ước tính số distinct values

-- ✅ Tốt cho: = equality lookup
-- ❌ Không dùng được cho: range queries, ORDER BY

Range Index (Nonclustered, In-Memory)

-- Nonclustered range index: Bw-tree (lock-free B-tree)
-- Hỗ trợ range queries, ORDER BY
INDEX IX_Session_UserId NONCLUSTERED (UserId, CreatedAt)

11. Hypothetical Indexes (Index giả định)

SQL Server Database Engine Tuning Advisor (DTA) và một số tools dùng hypothetical indexes để test xem index có cải thiện query không mà không cần tạo thật.

-- Tạo hypothetical index (WITH STATISTICS_ONLY)
-- Tạo statistics nhưng KHÔNG tạo cấu trúc index thật
CREATE NONCLUSTERED INDEX IX_Orders_Test
ON Orders (CustomerId, OrderDate)
WITH STATISTICS_ONLY = -1;   -- Hypothetical

-- Bật chế độ cho phép optimizer dùng hypothetical indexes
DBCC AUTOPILOT(0, DB_ID(), OBJECT_ID('Orders'), ...);

-- Thực tế: Dùng Database Engine Tuning Advisor
-- 1. Capture workload (Profiler Trace hoặc Extended Events)
-- 2. Chạy DTA với workload
-- 3. DTA generates recommendations
-- 4. Review và apply các recommendations cần thiết

Thực tế: Hypothetical indexes hiếm khi dùng trực tiếp trong T-SQL. Chủ yếu là internal mechanism của DTA. Lập trình viên thường test bằng cách tạo index thật trên môi trường dev/staging.

Query Optimization - Tối Ưu Truy Vấn

1. Query Processing Pipeline

Mỗi khi SQL Server nhận một query, nó đi qua pipeline 4 bước:

SQL Text
   ↓
[1. Parser]          → Kiểm tra syntax, tạo Parse Tree
   ↓
[2. Algebrizer/Bind] → Resolve tên objects/columns, kiểm tra semantics
   ↓
[3. Query Optimizer] → Tạo Execution Plan tối ưu (cost-based)
   ↓
[4. Execution Engine]→ Thực thi plan, trả kết quả

Chi tiết từng bước

-- Bước 1: Parser - kiểm tra syntax
SELECCT * FROM Orders;   -- ❌ Syntax error tại Parser

-- Bước 2: Algebrizer - resolve objects
SELECT * FROM NonExistentTable;   -- ❌ Object not found tại Algebrizer

-- Bước 3: Optimizer - tạo plan
-- Optimizer thử nhiều alternatives, chọn plan có estimated cost thấp nhất
-- Không phải luôn chọn plan THỰC TẾ nhanh nhất (chỉ dựa vào statistics)

-- Bước 4: Execution
-- Thực thi plan, có thể khác với estimate nếu statistics không chính xác

2. Cost-Based Optimizer

SQL Server’s Query Optimizer (QO) là cost-based: nó tạo nhiều plan alternatives và chọn plan có estimated cost thấp nhất.

Cost dựa trên gì?

• Statistics: phân phối dữ liệu của cột (histogram)
• Cardinality estimates: ước tính số hàng mỗi operator trả về
• I/O cost: số page reads ước tính
• CPU cost: computational cost

-- Xem statistics của một column
DBCC SHOW_STATISTICS ('Orders', 'IX_Orders_CustomerId');
-- Kết quả: Header (stats), Density Vector, Histogram (phân phối giá trị)

-- Cập nhật statistics
UPDATE STATISTICS Orders IX_Orders_CustomerId WITH FULLSCAN;
UPDATE STATISTICS Orders;  -- Tất cả stats cho bảng

-- Xem khi statistics được update lần cuối
SELECT 
    s.name AS StatName,
    sp.last_updated,
    sp.rows,
    sp.rows_sampled,
    sp.modification_counter
FROM sys.stats s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE s.object_id = OBJECT_ID('Orders');

Estimated vs Actual Rows

-- Bật actual execution plan (Ctrl+M trong SSMS)
-- Xem: Estimated Rows vs Actual Rows trong mỗi operator
-- Nếu chênh lệch lớn → statistics không chính xác → plan không tốt

-- Ví dụ: Optimizer ước tính 10 rows nhưng thực tế 1,000,000 rows
-- → Optimizer chọn Nested Loops (tốt cho nhỏ) nhưng thực tế nên dùng Hash Join

3. SARGable Predicates

SARGable (Search ARGument ABLE) là predicate mà SQL Server có thể dùng để thực hiện index seek thay vì scan.

Nguyên tắc

Predicate không SARGable khi: cột indexed nằm bên trong một function hoặc biểu thức.

-- ❌ Non-SARGable: hàm trên cột
WHERE YEAR(OrderDate) = 2024
WHERE MONTH(OrderDate) = 6
WHERE UPPER(LastName) = 'NGUYEN'
WHERE LEN(PhoneNumber) = 10
WHERE SUBSTRING(ProductCode, 1, 3) = 'SKU'

-- ✅ Viết lại SARGable
WHERE OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01'
WHERE OrderDate >= '2024-06-01' AND OrderDate < '2024-07-01'
WHERE LastName = 'Nguyen'   -- CI collation → không cần UPPER
WHERE PhoneNumber LIKE '__________'   -- Nếu phải dùng LIKE
WHERE ProductCode LIKE 'SKU%'

-- ❌ Non-SARGable: biểu thức trên cột
WHERE Price * 1.1 > 100
WHERE Age + 5 = 30
WHERE OrderId + 1 = @Param

-- ✅ Viết lại: di chuyển biểu thức sang phía giá trị
WHERE Price > 100 / 1.1        -- ≈ 90.9
WHERE Age = 30 - 5             -- = 25
WHERE OrderId = @Param - 1

-- ❌ Non-SARGable: implicit/explicit conversion
WHERE CAST(OrderId AS VARCHAR) = '1234'
WHERE CONVERT(NVARCHAR, OrderDate, 103) = '01/01/2024'

-- ✅ Giữ đúng kiểu dữ liệu
WHERE OrderId = 1234           -- INT so sánh INT
WHERE OrderDate = '2024-01-01' -- Implicit convert từ string sang DATE là OK

4. Common Anti-Patterns (Lỗi phổ biến)

4.1 Function trong WHERE trên cột indexed

-- ❌ Buộc table scan
SELECT * FROM Orders WHERE YEAR(OrderDate) = 2024;

-- ✅ Index seek
SELECT * FROM Orders 
WHERE OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01';

4.2 LIKE với leading wildcard

-- ❌ Table/Index scan - không thể seek khi bắt đầu bằng %
SELECT * FROM Products WHERE ProductName LIKE '%phone%';

-- ✅ Tốt hơn: trailing wildcard có thể seek
SELECT * FROM Products WHERE ProductName LIKE 'Samsung%';

-- ✅ Nếu cần full-text search: dùng Full-Text Index + CONTAINS
SELECT * FROM Products WHERE CONTAINS(ProductName, 'phone');

4.3 Implicit Conversion

-- Bảng: CustomerCode NVARCHAR(20) (Unicode)
-- ❌ Parameter @code là VARCHAR → implicit conversion, index scan
DECLARE @code VARCHAR(20) = 'CUST001';
SELECT * FROM Customers WHERE CustomerCode = @code;
-- SQL Server phải convert tất cả CustomerCode sang VARCHAR để so sánh

-- ✅ Dùng đúng kiểu dữ liệu
DECLARE @code NVARCHAR(20) = N'CUST001';
SELECT * FROM Customers WHERE CustomerCode = @code;

-- Kiểm tra implicit conversion trong execution plan:
-- Tìm operator có "CONVERT_IMPLICIT" trong predicate

4.4 SELECT *

-- ❌ SELECT * - kéo về nhiều cột không cần thiết
SELECT * FROM Orders WHERE CustomerId = 100;

-- ✅ Chỉ lấy cột cần
SELECT OrderId, OrderDate, TotalAmount FROM Orders WHERE CustomerId = 100;
-- Lợi ích:
-- 1. Giảm network bandwidth
-- 2. Có thể dùng covering index (tránh key lookup)
-- 3. Tránh break code khi schema thay đổi

4.5 OR thay vì UNION ALL (đôi khi)

-- ❌ OR có thể không dùng được multiple indexes hiệu quả
SELECT * FROM Orders 
WHERE CustomerId = 100 OR Status = 'Urgent';

-- ✅ UNION ALL thường hiệu quả hơn
SELECT * FROM Orders WHERE CustomerId = 100
UNION ALL
SELECT * FROM Orders WHERE Status = 'Urgent' AND CustomerId <> 100;

4.6 NOT IN với NULL

-- ❌ Nguy hiểm: nếu BlacklistIds có NULL → query trả về rỗng
SELECT * FROM Orders WHERE CustomerId NOT IN (SELECT CustomerId FROM Blacklist);

-- ✅ An toàn
SELECT * FROM Orders o
WHERE NOT EXISTS (SELECT 1 FROM Blacklist b WHERE b.CustomerId = o.CustomerId);

5. JOIN Algorithms

SQL Server có 3 thuật toán join, optimizer chọn dựa trên kích thước bảng, indexes và statistics.

Nested Loops Join

For each row in Outer:
    Seek/Scan Inner table for matching rows

-- Nested Loops tốt khi:
-- 1. Outer table nhỏ (ít rows sau filter)
-- 2. Inner table có index trên join key
-- 3. Join selectivity cao (ít rows match)

-- Optimizer thường chọn Nested Loops cho:
SELECT c.Name, o.OrderDate
FROM Customers c                      -- Outer (nhỏ, vd: 1 khách)
INNER JOIN Orders o ON o.CustomerId = c.CustomerId  -- Inner (có index)
WHERE c.CustomerId = 12345;

Hash Join

Phase 1 (Build): Hash mọi hàng của Build Input vào hash table
Phase 2 (Probe): Với mỗi hàng Probe Input, lookup trong hash table

-- Hash Join tốt khi:
-- 1. Cả hai inputs lớn, không có index phù hợp
-- 2. Không yêu cầu sorted input
-- 3. Ước tính nhiều rows match

-- ⚠️ Khi hash table không vừa memory → spill sang TempDB (Hash Spill)
-- Xuất hiện trong execution plan là dấu hiệu cần index hoặc tăng memory

-- Xem Hash Spill warnings
SELECT * FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE CAST(qp.query_plan AS NVARCHAR(MAX)) LIKE '%SpillToTempDb%';

Merge Join

Cả hai inputs phải được SORT theo join key
Đọc song song, merge như merge sort

-- Merge Join tốt khi:
-- 1. Cả hai inputs đã sorted (từ index hoặc Sort operator)
-- 2. JOIN dạng equality (equi-join)
-- 3. Cả hai inputs tương đương lớn

-- Merge Join rất hiệu quả nếu đã có sorted index:
SELECT o.OrderId, od.ProductId
FROM Orders o                          -- Clustered index trên OrderId → sorted
INNER JOIN OrderDetails od ON o.OrderId = od.OrderId  -- Index trên OrderId → sorted
-- → Optimizer thường chọn Merge Join ở đây

So sánh

6. Query Hints

-- OPTION (RECOMPILE): Tạo plan mới mỗi lần, dùng actual parameter values
-- Hữu ích khi parameter sniffing gây vấn đề
SELECT * FROM Orders WHERE CustomerId = @Id
OPTION (RECOMPILE);

-- MAXDOP: Giới hạn số CPU dùng cho query
SELECT * FROM BigTable
OPTION (MAXDOP 4);  -- Tối đa 4 cores

SELECT * FROM SmallQuery
OPTION (MAXDOP 1);  -- Không dùng parallelism

-- OPTIMIZE FOR: Hint cho optimizer dùng giá trị giả định
SELECT * FROM Orders WHERE CustomerId = @Id
OPTION (OPTIMIZE FOR (@Id = 1000));   -- Optimize như thể @Id = 1000

-- OPTIMIZE FOR UNKNOWN: Không dùng cached value, dùng average statistics
SELECT * FROM Orders WHERE CustomerId = @Id
OPTION (OPTIMIZE FOR (@Id UNKNOWN));

-- USE PLAN: Ép dùng execution plan XML cụ thể (advanced)
SELECT * FROM Orders
OPTION (USE PLAN N'<ShowPlanXML.../>');

-- LOOP JOIN / HASH JOIN / MERGE JOIN: Ép thuật toán join
SELECT * FROM Orders o
INNER HASH JOIN Customers c ON o.CustomerId = c.CustomerId
OPTION (HASH JOIN);

-- FORCE ORDER: Ép optimizer join theo thứ tự viết trong query
SELECT * FROM A
INNER JOIN B ON A.Id = B.AId
INNER JOIN C ON B.Id = C.BId
OPTION (FORCE ORDER);

-- NO_PERFORMANCE_SPOOL: Tắt spool optimization
-- DISABLE_OPTIMIZER_ROWGOAL: Tắt row goal optimization
-- ENABLE_PARALLEL_PLAN_PREFERENCE: Ưu tiên plan song song

7. Plan Cache & Parameter Sniffing

Plan Cache

SQL Server cache execution plans để tránh compile lại mỗi lần.

-- Xem plans trong cache
SELECT 
    qs.execution_count,
    qs.total_logical_reads,
    qs.total_elapsed_time / 1000 AS total_ms,
    SUBSTRING(qt.text, 1, 300) AS query_text,
    qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_logical_reads DESC;

-- Xóa tất cả plan cache (chỉ dùng dev/troubleshooting!)
DBCC FREEPROCCACHE;

-- Xóa plan cụ thể
DBCC FREEPROCCACHE (@plan_handle);

Parameter Sniffing

Khi stored procedure compiles lần đầu, optimizer dùng giá trị parameter lúc đó để tạo plan. Plan này có thể tốt cho giá trị đó nhưng tệ cho giá trị khác.

-- Stored procedure
CREATE PROCEDURE GetOrdersByCustomer @CustomerId INT
AS
BEGIN
    SELECT OrderId, OrderDate, TotalAmount
    FROM Orders
    WHERE CustomerId = @CustomerId;
END;

-- Lần đầu gọi với CustomerId = 1 (có 1,000,000 orders → optimizer dùng Table Scan)
EXEC GetOrdersByCustomer 1;  -- Plan: Table Scan (tốt cho nhiều rows)

-- Lần sau gọi với CustomerId = 99999 (có 5 orders)
EXEC GetOrdersByCustomer 99999;  -- ❌ Dùng lại plan cũ (Table Scan cho 5 rows → rất chậm!)

Giải pháp Parameter Sniffing

-- Giải pháp 1: OPTION (RECOMPILE) - compile lại mỗi lần
CREATE PROCEDURE GetOrdersByCustomer @CustomerId INT
AS
BEGIN
    SELECT OrderId, OrderDate, TotalAmount
    FROM Orders
    WHERE CustomerId = @CustomerId
    OPTION (RECOMPILE);  -- Mất benefit của plan caching
END;

-- Giải pháp 2: OPTIMIZE FOR UNKNOWN
WHERE CustomerId = @CustomerId
OPTION (OPTIMIZE FOR (@CustomerId UNKNOWN));

-- Giải pháp 3: Local variable trick (không được sniff)
CREATE PROCEDURE GetOrdersByCustomer @CustomerId INT
AS
BEGIN
    DECLARE @LocalId INT = @CustomerId;  -- Optimizer không thể sniff local var
    SELECT * FROM Orders WHERE CustomerId = @LocalId;
END;

-- Giải pháp 4: Multiple procedures cho các scenarios khác nhau
IF @CustomerId IN (1, 2, 3)  -- Known "high volume" customers
    EXEC GetOrdersByCustomer_HighVolume @CustomerId
ELSE
    EXEC GetOrdersByCustomer_Normal @CustomerId

8. Recompilation

Khi nào plan bị recompile?

-- 1. Schema thay đổi (ALTER TABLE, CREATE INDEX, etc.)
-- 2. Statistics thay đổi (sau threshold = 20% of rows + 500 rows modified)
-- 3. SET options thay đổi trong session
-- 4. Database thay đổi (sp_recompile)
-- 5. OPTION (RECOMPILE) hint

-- Buộc recompile tất cả procedures liên quan đến table
EXEC sp_recompile 'Orders';

-- Xem recompilation events với Extended Events hoặc Profiler
-- Event: sql_statement_recompile (Extended Events)
-- Event Class: SP:Recompile (Profiler)

Xem Queries với nhiều recompiles

SELECT 
    qs.plan_generation_num,  -- Số lần plan được regenerate
    qs.execution_count,
    SUBSTRING(qt.text, 1, 200) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
WHERE qs.plan_generation_num > 10
ORDER BY qs.plan_generation_num DESC;

9. TempDB Usage

Temp Tables vs Table Variables

-- Temp Table (#)
CREATE TABLE #TempOrders (
    OrderId INT,
    CustomerId INT,
    TotalAmount DECIMAL(18,2)
);
-- Trong TempDB, có statistics, có thể có indexes
-- Scope: session (hoặc nested scope)

INSERT INTO #TempOrders SELECT OrderId, CustomerId, TotalAmount FROM Orders WHERE ...;

-- Table Variable (@)
DECLARE @TempOrders TABLE (
    OrderId INT,
    CustomerId INT,
    TotalAmount DECIMAL(18,2)
);
-- Không có statistics (optimizer assume 1 row!)
-- Scope: batch
-- Không commit/rollback riêng

Worktables trong TempDB

SQL Server tự tạo worktables trong TempDB cho:

• Hash Join spill (khi memory không đủ)
• Sort spill
• Spool operations
• Recursive CTE

-- Monitor TempDB usage
SELECT 
    r.session_id,
    r.total_elapsed_time,
    tdb.internal_objects_alloc_page_count AS temp_pages_allocated,
    SUBSTRING(qt.text, 1, 200) AS query_text
FROM sys.dm_exec_requests r
INNER JOIN sys.dm_db_task_space_usage tdb ON r.session_id = tdb.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) qt
WHERE tdb.internal_objects_alloc_page_count > 0
ORDER BY tdb.internal_objects_alloc_page_count DESC;

10. Parallelism (Xử lý song song)

Khi nào query đi parallel?

SQL Server sẽ cân nhắc parallel plan khi:

1. Estimated cost > cost threshold for parallelism (mặc định: 5)
2. MAXDOP không = 1
3. Query đủ phức tạp để benefit từ parallelism

-- Xem cấu hình parallelism
SELECT name, value_in_use
FROM sys.configurations 
WHERE name IN ('max degree of parallelism', 'cost threshold for parallelism');

-- Đổi cost threshold (khuyến nghị: 25-50 cho OLTP)
EXEC sp_configure 'cost threshold for parallelism', 50;
RECONFIGURE;

-- Đổi MAXDOP toàn server
EXEC sp_configure 'max degree of parallelism', 8;
RECONFIGURE;

MAXDOP Recommendations

-- Query-level MAXDOP
SELECT * FROM BigTable OPTION (MAXDOP 8);

-- Database-level MAXDOP (SQL Server 2016+)
ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 4;

Vấn đề với Parallelism

-- CXPACKET wait: worker threads chờ nhau trong parallel query
-- Xem top waits
SELECT TOP 10
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    max_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('SLEEP_TASK', 'BROKER_TO_FLUSH', 'WAITFOR', 'CLR_AUTO_EVENT')
ORDER BY wait_time_ms DESC;

-- CXPACKET cao có thể chỉ ra:
-- 1. Parallelism không cần thiết (tăng cost threshold)
-- 2. Skewed data distribution (uneven work distribution)
-- 3. Worker thread chờ I/O

11. DMVs for Performance Analysis

sys.dm_exec_query_stats

-- Top 20 queries tốn nhiều logical reads nhất
SELECT TOP 20
    qs.execution_count,
    qs.total_logical_reads,
    qs.total_logical_reads / qs.execution_count AS avg_logical_reads,
    qs.total_elapsed_time / 1000000 AS total_seconds,
    qs.total_elapsed_time / qs.execution_count / 1000 AS avg_ms,
    SUBSTRING(qt.text, (qs.statement_start_offset/2)+1, 
        ((CASE qs.statement_end_offset 
            WHEN -1 THEN DATALENGTH(qt.text) 
            ELSE qs.statement_end_offset END 
         - qs.statement_start_offset)/2)+1) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY qs.total_logical_reads DESC;

sys.dm_exec_requests

-- Xem các query đang chạy hiện tại
SELECT 
    r.session_id,
    r.status,
    r.blocking_session_id,
    r.wait_type,
    r.wait_time / 1000 AS wait_seconds,
    r.total_elapsed_time / 1000 AS elapsed_seconds,
    r.cpu_time,
    r.logical_reads,
    DB_NAME(r.database_id) AS database_name,
    SUBSTRING(qt.text, (r.statement_start_offset/2)+1, 200) AS current_statement
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) qt
WHERE r.session_id != @@SPID   -- Loại bỏ session hiện tại
ORDER BY r.total_elapsed_time DESC;

sys.dm_os_wait_stats

-- Phân tích wait statistics (reset sau mỗi lần restart hoặc DBCC SQLPERF)
SELECT TOP 20
    wait_type,
    waiting_tasks_count,
    wait_time_ms,
    max_wait_time_ms,
    signal_wait_time_ms,
    wait_time_ms - signal_wait_time_ms AS resource_wait_ms
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN (
    'SLEEP_TASK', 'BROKER_TO_FLUSH', 'BROKER_EVENTHANDLER',
    'CHECKPOINT_QUEUE', 'DBMIRROR_EVENTS_QUEUE', 'SQLTRACE_BUFFER_FLUSH',
    'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
    'HADR_FILESTREAM_IOMGR_IOCOMPLETION', 'HADR_WORK_QUEUE', 'LAZYWRITER_SLEEP',
    'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH',
    'RESOURCE_QUEUE', 'SERVER_IDLE_CHECK', 'SLEEP_DBSTARTUP', 'SLEEP_DCOMSTARTUP',
    'SLEEP_MASTERDBREADY', 'SLEEP_MASTERMDREADY', 'SLEEP_MASTERUPGRADED',
    'SLEEP_MSDBSTARTUP', 'SLEEP_SYSTEMTASK', 'SLEEP_TEMPDBSTARTUP',
    'SNI_HTTP_ACCEPT', 'SP_SERVER_DIAGNOSTICS_SLEEP', 'SQLTRACE_BUFFER_FLUSH',
    'WAIT_XTP_OFFLINE_CKPT_NEW_LOG', 'XE_DISPATCHER_WAIT', 'XE_TIMER_EVENT'
)
ORDER BY wait_time_ms DESC;

Common Wait Types

12. Extended Events vs SQL Trace

SQL Trace (Legacy - không dùng trên production mới)

-- SQL Trace (Profiler) - deprecated
-- Không dùng trên SQL Server 2019+ cho workloads mới

Extended Events (XE) - Modern approach

-- Tạo Extended Events session để capture slow queries (> 5 giây)
CREATE EVENT SESSION [SlowQueries] ON SERVER
ADD EVENT sqlserver.sql_statement_completed (
    ACTION (
        sqlserver.sql_text,
        sqlserver.client_hostname,
        sqlserver.username,
        sqlserver.database_name
    )
    WHERE (duration > 5000000)  -- > 5 giây (đơn vị: microseconds)
),
ADD EVENT sqlserver.rpc_completed (
    ACTION (sqlserver.sql_text)
    WHERE (duration > 5000000)
)
ADD TARGET package0.ring_buffer (SET max_memory = 51200)  -- 50MB buffer
WITH (MAX_DISPATCH_LATENCY = 5 SECONDS);

-- Bắt đầu session
ALTER EVENT SESSION [SlowQueries] ON SERVER STATE = START;

-- Đọc kết quả từ ring_buffer
SELECT  
    xdr.value('@name', 'nvarchar(50)') AS event_name,
    xdr.value('(action[@name="sql_text"]/value)[1]', 'nvarchar(max)') AS sql_text,
    xdr.value('(data[@name="duration"]/value)[1]', 'bigint') / 1000000.0 AS duration_sec,
    xdr.value('(data[@name="logical_reads"]/value)[1]', 'bigint') AS logical_reads,
    xdr.value('@timestamp', 'datetime2') AS event_time
FROM (
    SELECT CAST(target_data AS XML) AS target_data
    FROM sys.dm_xe_session_targets xst
    INNER JOIN sys.dm_xe_sessions xs ON xst.event_session_address = xs.address
    WHERE xs.name = 'SlowQueries' AND xst.target_name = 'ring_buffer'
) t
CROSS APPLY t.target_data.nodes('RingBufferTarget/event') AS xTable(xdr)
ORDER BY xdr.value('@timestamp', 'datetime2') DESC;

-- Dừng và xóa session
ALTER EVENT SESSION [SlowQueries] ON SERVER STATE = STOP;
DROP EVENT SESSION [SlowQueries] ON SERVER;

Query Store (SQL Server 2016+)

Query Store lưu lịch sử plans và performance - không cần XE session để track regressions.

-- Bật Query Store
ALTER DATABASE YourDB SET QUERY_STORE = ON;
ALTER DATABASE YourDB SET QUERY_STORE (
    OPERATION_MODE = READ_WRITE,
    CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 30),
    DATA_FLUSH_INTERVAL_SECONDS = 60,
    MAX_SIZE_MB = 1024,
    QUERY_CAPTURE_MODE = AUTO   -- Capture queries vượt ngưỡng
);

-- Top queries theo CPU trong Query Store
SELECT TOP 20
    q.query_id,
    qt.query_sql_text,
    rs.avg_cpu_time,
    rs.avg_logical_io_reads,
    rs.avg_duration,
    rs.count_executions
FROM sys.query_store_query q
INNER JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id
INNER JOIN sys.query_store_plan p ON q.query_id = p.query_id
INNER JOIN sys.query_store_runtime_stats rs ON p.plan_id = rs.plan_id
ORDER BY rs.avg_cpu_time DESC;

-- Force a specific plan (plan regression fix)
EXEC sp_query_store_force_plan @query_id = 1, @plan_id = 2;

So sánh XE vs Query Store vs Profiler

Statistics & Cardinality Estimation

Thống kê (Statistics) là gì?

Statistics là metadata mà SQL Server Query Optimizer sử dụng để ước tính số lượng rows (cardinality) sẽ được trả về bởi một query operation. Optimizer dùng thông tin này để chọn execution plan tối ưu nhất.

Thành phần của Statistics

Histogram

Histogram chia dữ liệu thành tối đa 200 steps (SQL Server 2016+), mỗi step chứa:

• RANGE_HI_KEY: Giá trị cao nhất trong step
• RANGE_ROWS: Số rows có giá trị trong range (không bao gồm boundary)
• EQ_ROWS: Số rows có giá trị bằng RANGE_HI_KEY
• DISTINCT_RANGE_ROWS: Số distinct values trong range
• AVG_RANGE_ROWS: Average rows per distinct value trong range

Density Vector

Density = 1 / number_of_distinct_values. Density Vector chứa density cho mọi prefix combination của index columns.

-- Xem density vector và histogram
DBCC SHOW_STATISTICS ('Sales.Orders', 'IX_Orders_CustomerID');
-- Hoặc chi tiết hơn
DBCC SHOW_STATISTICS ('Sales.Orders', 'IX_Orders_CustomerID') WITH HISTOGRAM;
DBCC SHOW_STATISTICS ('Sales.Orders', 'IX_Orders_CustomerID') WITH DENSITY_VECTOR;
DBCC SHOW_STATISTICS ('Sales.Orders', 'IX_Orders_CustomerID') WITH STAT_HEADER;

Auto-Create và Auto-Update Statistics

AUTO_CREATE_STATISTICS

SQL Server tự động tạo statistics khi optimizer cần thông tin cho một column chưa có statistics.

-- Kiểm tra setting của database
SELECT name, is_auto_create_stats_on, is_auto_update_stats_on,
       is_auto_update_stats_async_on
FROM sys.databases
WHERE name = 'YourDatabase';

-- Bật Auto Create Statistics
ALTER DATABASE YourDatabase SET AUTO_CREATE_STATISTICS ON;

-- Bật Async Auto Update
ALTER DATABASE YourDatabase SET AUTO_UPDATE_STATISTICS_ASYNC ON;

AUTO_UPDATE_STATISTICS

SQL Server tự động update statistics khi dữ liệu thay đổi vượt ngưỡng:

• SQL Server 2016 trở về trước: 20% rows thay đổi (+ 500 rows cho table nhỏ)
• SQL Server 2016+ với compatibility level 130+: Dynamic threshold (dùng sqrt(1000 * table_rows))

-- Bật Auto Update Statistics
ALTER DATABASE YourDatabase SET AUTO_UPDATE_STATISTICS ON;

-- Async update: query không cần chờ statistics update xong
ALTER DATABASE YourDatabase SET AUTO_UPDATE_STATISTICS_ASYNC ON;

Lưu ý: AUTO_UPDATE_STATISTICS_ASYNC ON giúp tránh blocking nhưng plan hiện tại có thể dùng statistics cũ cho query đó. Plan mới sẽ được dùng cho lần chạy tiếp theo.

Xem và Phân Tích Statistics

sys.statistics và sys.stats_columns

-- Xem tất cả statistics trên một table
SELECT 
    s.name AS stats_name,
    s.auto_created,
    s.user_created,
    s.has_filter,
    s.filter_definition,
    s.stats_id,
    STATS_DATE(s.object_id, s.stats_id) AS last_updated,
    sp.rows,
    sp.rows_sampled,
    sp.steps,
    sp.unfiltered_rows,
    sp.modification_counter
FROM sys.statistics s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE s.object_id = OBJECT_ID('Sales.Orders')
ORDER BY s.name;

-- Xem các columns trong statistics
SELECT 
    s.name AS stats_name,
    sc.stats_column_id,
    c.name AS column_name
FROM sys.statistics s
JOIN sys.stats_columns sc ON s.object_id = sc.object_id AND s.stats_id = sc.stats_id
JOIN sys.columns c ON sc.object_id = c.object_id AND sc.column_id = c.column_id
WHERE s.object_id = OBJECT_ID('Sales.Orders');

Kiểm tra Statistics Staleness

-- Tìm statistics cũ (chưa update > 7 ngày và có nhiều modifications)
SELECT 
    OBJECT_NAME(s.object_id) AS table_name,
    s.name AS stats_name,
    STATS_DATE(s.object_id, s.stats_id) AS last_updated,
    sp.modification_counter,
    sp.rows,
    CAST(100.0 * sp.modification_counter / NULLIF(sp.rows, 0) AS DECIMAL(5,2)) AS pct_modified
FROM sys.statistics s
CROSS APPLY sys.dm_db_stats_properties(s.object_id, s.stats_id) sp
WHERE sp.modification_counter > 0
    AND STATS_DATE(s.object_id, s.stats_id) < DATEADD(DAY, -7, GETDATE())
ORDER BY sp.modification_counter DESC;

Cập Nhật Statistics

UPDATE STATISTICS Options

-- Update tất cả statistics trên table với full scan
UPDATE STATISTICS Sales.Orders WITH FULLSCAN;

-- Update một statistics cụ thể
UPDATE STATISTICS Sales.Orders IX_Orders_CustomerID WITH FULLSCAN;

-- Dùng sample thay vì full scan (nhanh hơn, ít chính xác hơn)
UPDATE STATISTICS Sales.Orders WITH SAMPLE 30 PERCENT;
UPDATE STATISTICS Sales.Orders WITH SAMPLE 10000 ROWS;

-- Update tất cả statistics trong database
EXEC sp_updatestats; -- Chỉ update nếu có thay đổi

-- Update tất cả với full scan (chậm hơn nhưng chính xác nhất)
EXEC sp_msforeachtable 'UPDATE STATISTICS ? WITH FULLSCAN';

-- Dùng ROWCOUNT/PAGECOUNT để override (KHÔNG khuyến nghị cho production)
UPDATE STATISTICS Sales.Orders WITH ROWCOUNT = 5000000, PAGECOUNT = 100000;

UPDATE STATISTICS vs sp_updatestats

Statistics Update Thresholds

Old Threshold (trước SQL 2016)

Threshold = 500 + 20% of table rows

• Table 100 rows: update sau 520 changes
• Table 1,000,000 rows: update sau 200,500 changes
• Vấn đề: Table lớn rất khó trigger auto-update → outdated statistics

Dynamic Threshold (SQL 2016+ với Compat Level 130+)

Threshold = sqrt(1000 * table_rows)

• Table 1,000,000 rows: update sau ~31,623 changes (thay vì 200,500)
• Kích hoạt bằng cách set compatibility level ≥ 130

-- Kiểm tra compatibility level
SELECT name, compatibility_level FROM sys.databases WHERE name = DB_NAME();

-- Nâng compatibility level để dùng dynamic threshold
ALTER DATABASE YourDatabase SET COMPATIBILITY_LEVEL = 150; -- SQL 2019

-- Hoặc dùng trace flag 2371 (SQL 2008-2014 để enable dynamic threshold sớm)
DBCC TRACEON (2371, -1);

Trace Flag 2389 và 2390 — Ascending Key Problem

Vấn đề Ascending Key

Khi một column (thường là identity hoặc datetime) có giá trị mới liên tục được INSERT vào vượt ngoài histogram, optimizer sẽ ước tính 0 hoặc 1 row → chọn plan sai.

-- Ví dụ: OrderDate là ascending key
-- Histogram chỉ biết đến ngày hôm qua
-- Query hôm nay: optimizer estimate 1 row → chọn Nested Loops
-- Thực tế: 50,000 rows → cần Hash Join

SELECT * FROM Sales.Orders WHERE OrderDate >= '2024-01-01';

Giải pháp với Trace Flag

-- TF 2389: SQL Server detect ascending key statistic và mark histogram là "ascending"
-- TF 2390: Tương tự nhưng dùng cho unknown pattern (không chỉ ascending)
DBCC TRACEON (2389, -1);
DBCC TRACEON (2390, -1);

-- SQL Server 2016+ với CE 120+: Dùng Average Row Count thay vì estimate 1 row
-- Không cần trace flags nếu dùng CE mới

Giải pháp thực tế

-- 1. Update statistics thường xuyên hơn (sau batch insert lớn)
UPDATE STATISTICS Sales.Orders IX_Orders_OrderDate WITH FULLSCAN;

-- 2. Tạo Filtered Statistics cho range mới
CREATE STATISTICS ST_Orders_RecentDates 
ON Sales.Orders (OrderDate)
WHERE OrderDate >= '2024-01-01'
WITH FULLSCAN;

-- 3. Dùng OPTION (RECOMPILE) để force fresh estimate
SELECT * FROM Sales.Orders 
WHERE OrderDate >= @StartDate
OPTION (RECOMPILE);

Cardinality Estimation (CE)

CE70 vs CE120+

-- Kiểm tra CE model đang dùng
SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME();

-- Force CE70 (Legacy) cho một query cụ thể
SELECT * FROM Sales.Orders
WHERE CustomerID = 1 AND StatusID = 2
OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION'));

-- Force CE120
SELECT * FROM Sales.Orders
OPTION (USE HINT ('ENABLE_QUERY_OPTIMIZER_HOTFIXES'));

-- Force CE ở database level
ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION = ON;

Kiểm tra và Xác định CE Issues

-- So sánh estimated vs actual rows trong execution plan
-- Dùng STATISTICS XML để xem chi tiết
SET STATISTICS XML ON;
SELECT * FROM Sales.Orders WHERE CustomerID = 100;
SET STATISTICS XML OFF;

-- Dùng Query Store để tìm regressed queries
SELECT 
    qsq.query_id,
    qsq.query_hash,
    qsp.plan_id,
    qsrs.avg_logical_io_reads,
    qsrs.avg_cpu_time,
    TRY_CAST(qsp.query_plan AS XML) AS query_plan
FROM sys.query_store_query qsq
JOIN sys.query_store_plan qsp ON qsq.query_id = qsp.query_id
JOIN sys.query_store_runtime_stats qsrs ON qsp.plan_id = qsrs.plan_id
ORDER BY qsrs.avg_logical_io_reads DESC;

Cardinality Issues: Estimated vs Actual Row Count

Cách Identify CE Problems

1. Execution Plan: Nhìn vào “Estimated Number of Rows” vs “Actual Number of Rows”
2. Nếu ratio > 10x: Có thể có cardinality estimation problem
3. Triệu chứng: Nested Loops thay vì Hash Join, hoặc ngược lại

-- Query để tìm queries có cardinality mismatch lớn trong Query Store
SELECT TOP 20
    qsq.query_id,
    qsp.plan_id,
    qsrs.count_executions,
    qsrs.avg_logical_io_reads,
    (qsrs.avg_logical_io_reads * qsrs.count_executions) AS total_io,
    qsrs.avg_cpu_time / 1000.0 AS avg_cpu_ms,
    SUBSTRING(qsqt.query_sql_text, 1, 200) AS query_text
FROM sys.query_store_query qsq
JOIN sys.query_store_query_text qsqt ON qsq.query_text_id = qsqt.query_text_id
JOIN sys.query_store_plan qsp ON qsq.query_id = qsp.query_id
JOIN sys.query_store_runtime_stats qsrs ON qsp.plan_id = qsrs.plan_id
WHERE qsrs.avg_logical_io_reads > 10000
ORDER BY total_io DESC;

Filtered Statistics

Filtered Statistics cho phép tạo statistics chỉ trên một subset của data, giúp optimizer có thông tin chính xác hơn cho filtered queries.

-- Tạo filtered statistics cho orders của năm hiện tại
CREATE STATISTICS ST_Orders_Current_Year
ON Sales.Orders (CustomerID, OrderDate)
WHERE YEAR(OrderDate) = YEAR(GETDATE())
WITH FULLSCAN;

-- Tạo filtered statistics cho active products
CREATE STATISTICS ST_Products_Active
ON Products (CategoryID, Price)
WHERE IsActive = 1
WITH FULLSCAN;

-- Xem filtered statistics
SELECT 
    s.name,
    s.has_filter,
    s.filter_definition,
    STATS_DATE(s.object_id, s.stats_id) AS last_updated
FROM sys.statistics s
WHERE s.object_id = OBJECT_ID('Sales.Orders')
    AND s.has_filter = 1;

Multi-Column Statistics

Multi-column statistics cung cấp thông tin về correlation (sự tương quan) giữa các columns.

-- Tạo multi-column statistics
CREATE STATISTICS ST_Orders_Customer_Status
ON Sales.Orders (CustomerID, StatusID, OrderDate)
WITH FULLSCAN;

-- Xem density vector của multi-column statistics
-- Density càng thấp → column combination càng selective
DBCC SHOW_STATISTICS ('Sales.Orders', 'ST_Orders_Customer_Status') WITH DENSITY_VECTOR;

Density và Correlation

• Density = 1 / distinct_values: Density thấp = selective column
• Multi-column density giúp optimizer biết nếu kết hợp columns giảm result set bao nhiêu
• Nếu optimizer không có multi-column stats, nó assume column independence → ước tính sai

Statistics cho Non-Indexed Columns

SQL Server có thể auto-create statistics cho non-indexed columns (nếu AUTO_CREATE_STATISTICS ON). Bạn cũng có thể tạo thủ công:

-- Tạo statistics thủ công cho column không có index
CREATE STATISTICS ST_Orders_Notes
ON Sales.Orders (Notes)
WITH FULLSCAN;

-- Xem tất cả auto-created statistics (không phải từ index)
SELECT 
    OBJECT_NAME(s.object_id) AS table_name,
    s.name AS stats_name,
    s.auto_created,
    STATS_DATE(s.object_id, s.stats_id) AS last_updated
FROM sys.statistics s
WHERE s.auto_created = 1
    AND s.object_id > 100  -- Exclude system objects
ORDER BY OBJECT_NAME(s.object_id), s.name;

-- Xóa auto-created statistics không cần thiết
DROP STATISTICS Sales.Orders._WA_Sys_00000001_1ED998B2;

Statistics cho tempdb và In-Memory OLTP

tempdb Statistics

-- Statistics trong tempdb được tạo cho temp tables và table variables
-- Temp tables: auto-create and auto-update statistics (theo database setting)
-- Table variables: KHÔNG có statistics → optimizer assume 1 row

CREATE TABLE #TempOrders (
    OrderID INT,
    CustomerID INT,
    OrderDate DATE
);

-- Tạo statistics thủ công cho temp table
CREATE STATISTICS ST_TempOrders_Customer ON #TempOrders (CustomerID);

-- Verify
DBCC SHOW_STATISTICS ('#TempOrders', 'ST_TempOrders_Customer');

In-Memory OLTP Statistics

-- Memory-Optimized tables có statistics riêng
-- Xem statistics cho memory-optimized tables
SELECT 
    OBJECT_NAME(s.object_id) AS table_name,
    s.name AS stats_name,
    STATS_DATE(s.object_id, s.stats_id) AS last_updated
FROM sys.statistics s
JOIN sys.tables t ON s.object_id = t.object_id
WHERE t.is_memory_optimized = 1;

-- Update statistics cho memory-optimized table
UPDATE STATISTICS dbo.MemOptOrders WITH FULLSCAN;

Q&A theo Cấp Độ

Junior Level

Q: Statistics là gì và tại sao quan trọng?

A: Statistics là tập metadata mô tả phân phối dữ liệu trong một column hoặc set of columns. Query Optimizer dùng statistics để ước tính số rows sẽ được trả về (cardinality), từ đó chọn execution plan phù hợp (index scan vs seek, nested loops vs hash join). Statistics không chính xác → plan kém hiệu quả → query chậm.

Q: AUTO_CREATE_STATISTICS và AUTO_UPDATE_STATISTICS là gì?

A: AUTO_CREATE_STATISTICS ON cho phép SQL Server tự tạo statistics cho columns chưa có khi cần cho optimization. AUTO_UPDATE_STATISTICS ON cho phép SQL Server tự update statistics khi dữ liệu thay đổi vượt ngưỡng. Cả hai nên được bật trong hầu hết môi trường production.

Q: Làm sao xem statistics của một table?

A:

-- Xem danh sách statistics
SELECT name, STATS_DATE(object_id, stats_id) AS last_updated
FROM sys.statistics
WHERE object_id = OBJECT_ID('YourTable');

-- Xem chi tiết histogram
DBCC SHOW_STATISTICS ('YourTable', 'IndexOrStatsName');

Mid Level

Q: Giải thích vấn đề Ascending Key và cách giải quyết?

A: Vấn đề xảy ra khi column có giá trị mới luôn lớn hơn maximumvalue trong histogram (identity column, datetime). Optimizer không biết về các giá trị mới này và ước tính 0-1 row, dẫn đến plan sai. Giải pháp:

1. Update statistics thường xuyên hơn (sau batch insert lớn)
2. Dùng Trace Flag 2389/2390 (SQL 2014 trở về)
3. Nâng Compatibility Level ≥ 130 (CE 120 xử lý tốt hơn)
4. Dùng Filtered Statistics cho data mới
5. OPTION (RECOMPILE) cho ad-hoc queries

Q: Filtered Statistics là gì và khi nào nên dùng?

A: Filtered Statistics là statistics được tạo trên một subset của data (với WHERE clause). Dùng khi:

• Query thường xuyên filter trên một giá trị cụ thể hoặc range
• Auto statistics không đủ chính xác vì data distribution không đều
• Partition pruning cần statistics cho từng partition range

CREATE STATISTICS ST_Active_Customers
ON Customers (Region, CustomerType)
WHERE IsActive = 1
WITH FULLSCAN;

Q: Sự khác biệt giữa UPDATE STATISTICS WITH FULLSCAN và default sample rate?

A: Default sample rate tự động chọn dựa trên kích thước table (thường 20-30% cho table lớn). WITH FULLSCAN scan toàn bộ data → statistics chính xác nhất nhưng tốn I/O và thời gian nhất. Với table rất lớn (>100M rows), FULLSCAN có thể ảnh hưởng production. Trade-off: accuracy vs performance cost. Recommendation: dùng FULLSCAN trong maintenance window, sample rate cho frequent updates.

Senior Level

Q: Giải thích sự khác biệt giữa CE70 và CE120 và khi nào nên rollback về CE70?

A:

• CE70: Model cũ từ SQL 7.0, assume column independence cho multi-predicate (multiply selectivities). Đơn giản nhưng có thể overestimate hoặc underestimate.
• CE120: Model mới SQL 2014+, dùng exponential backoff cho multi-predicate (giảm dần impact của mỗi predicate sau), xử lý ascending keys tốt hơn, JOIN estimation sophistication hơn.

Khi nào rollback CE70: Sau khi nâng compatibility level, nếu một số query bị regression (chạy chậm hơn với CE120), có thể rollback:

• Database level: ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION = ON
• Query level: OPTION (USE HINT('FORCE_LEGACY_CARDINALITY_ESTIMATION'))
• Nên dùng Query Store để track regression trước khi quyết định

Q: Trong một hệ thống với table partitioning, làm sao manage statistics hiệu quả?

A:

1. Incremental Statistics (SQL 2014+): Update statistics chỉ cho partition có data thay đổi, không cần scan toàn bộ table.

-- Tạo partitioned table với incremental statistics
CREATE STATISTICS ST_Orders_OrderDate ON Sales.Orders (OrderDate)
WITH FULLSCAN, INCREMENTAL = ON;

-- Update statistics chỉ cho partition 5
UPDATE STATISTICS Sales.Orders ST_Orders_OrderDate
WITH RESAMPLE ON PARTITIONS (5);

2. Per-partition filtered statistics: Tạo filtered stats cho từng partition range để optimizer có thông tin chi tiết hơn về từng partition.

3. Monitor modification counter per partition: Dùng sys.dm_db_incremental_stats_properties thay vì sys.dm_db_stats_properties cho incremental stats.

Q: Làm sao diagnose và fix một slow query do cardinality estimation problem?

A: Step 1 - Identify: Bật Actual Execution Plan, so sánh “Estimated Rows” vs “Actual Rows”. Nếu ratio > 10x, có CE problem.

Step 2 - Root cause:

• Statistics cũ? → STATS_DATE() và modification_counter
• Ascending key? → Xem histogram, giá trị query có nằm ngoài RANGE_HI_KEY max không?
• Complex predicate? → Optimizer dùng correlation hay independence assumption?
• Parameter sniffing? → DBCC FREEPROCCACHE rồi chạy lại với actual parameter

Step 3 - Fix options (theo mức độ invasive):

1. UPDATE STATISTICS ... WITH FULLSCAN (least invasive)
2. Tạo Filtered Statistics hoặc Multi-column Statistics
3. OPTION (RECOMPILE) cho stored procedure với parameter sniffing
4. Query Store: Force good plan với sp_query_store_force_plan
5. Nâng/hạ Compatibility Level
6. Hint: OPTION (USE HINT ('ASSUME_JOIN_CONTAINMENT')) etc.

Execution Plans

Execution plans are the roadmap that SQL Server uses to retrieve data. Understanding how to read and analyze execution plans is crucial for performance tuning.

Topics

• Compute Scalar
• Clustered Index Scan

Overview

An execution plan shows how SQL Server will execute a query, including:

• Which indexes are used
• Join methods
• Scan types (table scan vs index scan/seek)
• Sort operations
• And various other operators

Why Execution Plans Matter

• Performance Tuning: Identify bottlenecks in queries
• Index Analysis: Understand if indexes are being used effectively
• Query Optimization: See why a query is slow and how to improve it
• Cardinality Estimates: Understand row count predictions

How to View Execution Plans

Using SSMS (SQL Server Management Studio)

1. Enable “Include Actual Execution Plan” (Ctrl + M)
2. Run your query
3. View the Execution Plan tab

Using T-SQL

SET STATISTICS XML ON;
-- Your query here
SET STATISTICS XML OFF;

Common Operators

Further Reading

For detailed information about specific operators, see the topics in this section.

Compute Scalar

Compute Scalar is an operator that computes new values from existing data within a row. It does not read data from disk, only processes data in memory.

Common Use Cases

• Calculations: Quantity * Price AS TotalAmount
• Functions: UPPER(FirstName), YEAR(OrderDate)
• Type Casting: CAST(OrderId AS VARCHAR)
• Concatenation: FirstName + ' ' + LastName

Parameters Explained

1. Physical Operation / Logical Operation

Physical Operation: Compute Scalar
Logical Operation: Compute Scalar

• Physical Operation: How SQL Server executes (compute scalar)
• Logical Operation: Logical meaning (also compute scalar)

In this case, both are the same since the operator has no special variants.

2. Estimated Execution Mode

Estimated Execution Mode: Row

• Row: Processes row-by-row
• Batch: Processes in batch mode (usually with columnstore indexes)

This is a simple operator, always running in row mode.

3. Estimated Operator Cost

Estimated Operator Cost: 0.001982 (2%)

Most important!

• 0.001982: Absolute cost of this operator
• (2%): Relative cost compared to the entire query (2% of total cost)

Meaning:

• This operator only takes 2% of the total query cost → NOT A BOTTLENECK
• If this number is > 30-50%, you should consider optimization

4. Estimated I/O Cost

Estimated I/O Cost: 0

• This is the I/O cost (reading from disk)
• 0 means this operator does not read data from disk, only processes data already in memory

✅ This is good - no I/O here.

5. Estimated Subtree Cost

Estimated Subtree Cost: 0.117937

• Total cost of the entire subtree from this operator downward
• Includes the current operator and all child operators

Meaning:

• This is the accumulated cost
• In the plan, you’ll see this value increase as you go up the tree toward the root

6. Estimated CPU Cost

Estimated CPU Cost: 0.001982

• CPU cost specifically for this operator
• In this case, it equals the Estimated Operator Cost (0.001982) because there is no I/O

Comparison with I/O Cost:

CPU Cost = 0.001982
I/O Cost = 0
Total = 0.001982

7. Estimated Number of Executions

Estimated Number of Executions: 1

• How many times this operator is executed
• 1 is normal for top-level operators
• If > 1, the operator may be in a loop (nested loop join) and could be a performance issue

8. Estimated Number of Rows

Estimated Number of Rows: 19820

• SQL Server estimates this operator will process 19,820 rows
• This is the cardinality estimate - very important for plan selection

Comparison with Actual Rows:

• If Actual Rows differs significantly from Estimated Rows → statistics issue

9. Estimated Row Size

Estimated Row Size: 56 B

• Each row takes approximately 56 bytes in memory
• Used to estimate memory grant

Calculation:

56 bytes × 19,820 rows ≈ 1.1 MB (memory required)

10. Node ID

Node ID: 0

• ID of the operator in the execution plan
• Used for referencing, debugging, or searching in the XML plan

Overall Analysis

Based on these parameters, here’s the assessment:

✅ Good Points:

⚠️ Needs Checking:

• Estimated Rows = 19,820: Compare with Actual Rows in the actual plan (SET STATISTICS XML ON)
• If Actual Rows >> 19,820 (e.g., 200,000) → Statistics outdated → Run UPDATE STATISTICS

Real-world Examples: When Compute Scalar Becomes an Issue?

Bad Case (bottleneck):

| Operator          | Cost    | Rows   | Executions |
|-------------------|---------|--------|------------|
| Compute Scalar    | 85%     | 1M     | 1000       |

→ Problem:

• Takes 85% CPU, runs 1000 times (in a loop)
• Consider: move calculation to application, use computed column, or optimize join logic

Your Case (good):

| Operator          | Cost    | Rows   | Executions |
|-------------------|---------|--------|------------|
| Compute Scalar    | 2%      | 19,820 | 1          |

→ No optimization needed, focus on other operators with higher cost.

How to View Actual vs Estimated in SSMS

To see actual metrics:

-- Enable Actual Execution Plan (Ctrl + M)
SET STATISTICS XML ON; -- Or use SSMS UI

-- Run your query
SELECT 
    OrderId,
    Quantity * Price AS TotalAmount, -- Compute Scalar will appear
    UPPER(CustomerName) AS UpperName
FROM Orders
WHERE OrderDate > '2024-01-01';

Then in the Execution Plan, hover over the operator to see both Estimated and Actual:

Actual Number of Rows: 19,820    (if it matches Estimated → good)
Actual Number of Executions: 1   (if > 1 → potential issue)

Summary

Conclusion: This Compute Scalar operator is not a problem to optimize. If the query is slow, look for operators with higher cost (table scan, index scan, hash join) or check if Estimated Rows differs significantly from Actual Rows.

Clustered Index Scan

Clustered Index Scan scans the entire clustered index (meaning the entire table, since clustered index stores all data). This is the most expensive operator in the execution plan (taking 97% of the cost).

What is Clustered Index Scan?

When SQL Server performs a Clustered Index Scan, it reads through every row in the clustered index. Since the clustered index contains the entire table data (the data rows are stored in the leaf nodes of the index), a scan means reading the entire table.

This operator is typically the most expensive because it reads all rows, not just a subset.

Common Use Cases

• No suitable index for the WHERE clause
• No WHERE clause at all (SELECT * FROM table)
• Non-sargable WHERE clause (e.g., WHERE YEAR(date) = 2024)
• Fetching too many rows (SQL Server estimates scan is faster than seek + bookmark lookup)

Parameters Explained

1. Storage

Storage: RowStore

• Data is stored in row format (horizontal) - traditional storage
• RowStore vs ColumnStore: RowStore is good for OLTP (many inserts/updates), ColumnStore is good for OLAP (aggregates on many rows)

2. Number of Rows - VERY IMPORTANT

Number of Rows Read: 19820
Actual Number of Rows: 19820
Estimated Number of Rows: 19820
Estimated Number of Rows to be Read: 19820

✅ GOOD POINT:

• Actual = Estimated = 19,820 rows
• Statistics are accurate, no cardinality estimation issues

Meaning:

• SQL Server correctly estimates the number of rows to process
• Query optimizer selects a plan appropriate for actual data

3. Cost - THE MAIN ISSUE

Estimated Operator Cost: 0.113973 (97%)
Estimated I/O Cost: 0.0920139
Estimated CPU Cost: 0.021959

⚠️ KEY POINTS:

Analysis:

• This operator takes 97% of the total query cost
• 81% of cost is I/O → reading data from disk, not from cache
• THIS IS THE MAIN BOTTLENECK of the query

4. Execution Parameters

Number of Executions: 1
Actual Rebinds: 0
Actual Rewinds: 0
Ordered: False

5. Row Size

Estimated Row Size: 47 B

• Each row ~47 bytes
• Total data: 47 × 19,820 ≈ 931 KB (less than 1 MB)

⚠️ Paradox:

• Data is only ~1 MB, but still scanning everything?
• The table may have more than 19,820 rows but the filter only selects 19,820 rows without a suitable index

Comparison with Compute Scalar

Observation:

• Clustered Index Scan is 57 times more expensive than Compute Scalar
• If the query is slow, the issue is here, not in Compute Scalar

How to Optimize

Method 1: Check if there’s a WHERE clause

-- Current query (assuming)
SELECT * FROM Orders
WHERE CustomerId = 12345  -- If there's no index on CustomerId

Solution: Create a non-clustered index

CREATE INDEX IX_Orders_CustomerId ON Orders(CustomerId)

After that, the plan will become:

Index Seek (NonClustered) → Key Lookup (Clustered) → Compute Scalar

Method 2: If query has no WHERE clause (SELECT all)

SELECT * FROM Orders  -- Fetching all 19,820 rows

Assessment:

• Scanning 20,000 rows is acceptable (I/O cost 0.09 is small)
• No optimization needed if data is small

Method 3: Check WHERE clause sargability

-- BAD (non-sargable)
WHERE YEAR(OrderDate) = 2024

-- GOOD (sargable)
WHERE OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01'

Method 4: Use covering index to avoid Key Lookup

If the query only needs a few columns:

-- Instead of SELECT *
CREATE INDEX IX_Orders_CustomerId_Include 
ON Orders(CustomerId) 
INCLUDE (OrderDate, TotalAmount)

The plan will become:

Index Seek (NonClustered) → Compute Scalar
(No Key Lookup needed)

Overall Assessment

✅ Good Points:

❌ Points to Improve:

Questions to Determine If Optimization is Needed

1. Does the query have a WHERE clause?

   • If yes: Need to create an index for the column in WHERE
   • If no: Scanning 20k rows is acceptable

2. What is the total number of rows in the table?

   • If ≈ 20,000: Scan is OK
   • If >> 20,000 (e.g., 1 million): Scan is a serious issue

3. How long does the query take?

   • If < 100ms: No optimization needed
   • If > 1s: Need to create an index

Summary

This Clustered Index Scan is the main bottleneck (97% cost).

Next steps:

1. View query text (F4 or hover over operator) to see WHERE clause
2. Check total rows in the table
3. If there’s a valid WHERE clause → create non-clustered index
4. If query actually runs slow (> 500ms) → optimize now
5. If query is fast (< 100ms) and data is small → can leave as is

Principle: Clustered Index Scan on 20,000 rows is not always bad. What’s important is execution frequency and actual time.

SQL Server Programming (T-SQL Programming)

Phần này tổng hợp kiến thức về lập trình T-SQL trong SQL Server, từ các khái niệm cơ bản đến kỹ thuật nâng cao. Đây là nền tảng quan trọng để xây dựng các ứng dụng database hiệu năng cao và bảo trì dễ dàng.

Các chủ đề chính

Tổng quan T-SQL Programming

Database Objects trong SQL Server

SQL Server Database Objects
├── Programmability
│   ├── Stored Procedures
│   ├── Functions
│   │   ├── Scalar Functions
│   │   ├── Table-Valued Functions
│   │   └── Aggregate Functions (CLR)
│   ├── Triggers
│   │   ├── DML Triggers
│   │   ├── DDL Triggers
│   │   └── Logon Triggers
│   └── Types
├── Views
│   ├── Standard Views
│   └── Indexed Views (Materialized)
└── Queries
    ├── CTEs (Common Table Expressions)
    ├── Window Functions
    └── Cursors

Khi nào dùng gì?

Q&A - Phỏng vấn T-SQL Programming

🟢 Junior Level

Q1: Stored Procedure là gì? Lợi ích so với việc gửi raw SQL từ application?

A: Stored Procedure (SP) là một tập hợp các câu lệnh T-SQL được biên dịch và lưu trong database. Lợi ích:

• Code reuse: Nhiều application/user dùng chung logic
• Security: Cấp quyền EXECUTE thay vì SELECT/INSERT/UPDATE trực tiếp
• Performance: Execution plan được cache lần đầu, các lần sau tái sử dụng
• Reduced network traffic: Chỉ gửi tên SP và tham số thay vì toàn bộ SQL text
• Maintainability: Thay đổi logic ở một nơi

-- Thay vì gửi raw SQL từ app:
-- SELECT * FROM Orders WHERE CustomerId = 1 AND Status = 'Active'

-- Dùng SP:
EXEC sp_GetActiveOrders @CustomerId = 1;

Q2: Sự khác nhau giữa Scalar Function và Table-Valued Function?

A:

Q3: Trigger là gì? Có mấy loại trigger trong SQL Server?

A: Trigger là một loại stored procedure đặc biệt, tự động thực thi khi xảy ra một sự kiện nhất định.

• DML Triggers: Kích hoạt bởi INSERT, UPDATE, DELETE
  • AFTER trigger: Chạy sau khi DML hoàn thành
  • INSTEAD OF trigger: Thay thế DML gốc
• DDL Triggers: Kích hoạt bởi CREATE, ALTER, DROP
• Logon Triggers: Kích hoạt khi user đăng nhập

Q4: View là gì? Khi nào nên dùng View?

A: View là một virtual table được định nghĩa bởi một câu SELECT. View không lưu dữ liệu (trừ Indexed View).

Nên dùng khi:

• Đơn giản hóa câu truy vấn phức tạp cho user
• Ẩn các cột nhạy cảm (security layer)
• Cung cấp interface ổn định khi schema thay đổi
• Tổng hợp dữ liệu từ nhiều bảng thường xuyên truy vấn

Q5: CTE là gì? Cú pháp cơ bản?

A: CTE (Common Table Expression) là một named temporary result set được định nghĩa trong phạm vi của một câu query.

WITH CTE_Name AS (
    SELECT column1, column2
    FROM TableName
    WHERE condition
)
SELECT * FROM CTE_Name;

CTE giúp code dễ đọc hơn, thay thế subquery phức tạp.

Q6: Window Function là gì? Cho ví dụ ROW_NUMBER()?

A: Window Function thực hiện tính toán trên một tập các rows liên quan đến row hiện tại (một “window”), không làm giảm số rows kết quả như GROUP BY.

SELECT
    EmployeeId,
    Department,
    Salary,
    ROW_NUMBER() OVER (PARTITION BY Department ORDER BY Salary DESC) AS RankInDept
FROM Employees;

Q7: Sự khác nhau giữa RANK(), DENSE_RANK() và ROW_NUMBER()?

A:

-- Dữ liệu: Salary = 5000, 4000, 4000, 3000
SELECT
    Salary,
    ROW_NUMBER() OVER (ORDER BY Salary DESC) AS RowNum,   -- 1, 2, 3, 4
    RANK()       OVER (ORDER BY Salary DESC) AS Rnk,      -- 1, 2, 2, 4
    DENSE_RANK() OVER (ORDER BY Salary DESC) AS DenseRnk  -- 1, 2, 2, 3
FROM Salaries;

• ROW_NUMBER: Luôn unique, không có ties
• RANK: Ties có cùng rank, skip numbers sau đó
• DENSE_RANK: Ties có cùng rank, không skip numbers

Q8: Cursor là gì? Tại sao nên tránh dùng cursor?

A: Cursor cho phép xử lý từng row một (row-by-row) thay vì set-based. Nên tránh vì:

• Chậm hơn set-based operations nhiều lần
• Tốn tài nguyên (memory, temp storage)
• Gây lock lâu hơn
• Hầu hết trường hợp đều có thể thay bằng set-based SQL hoặc window functions

Q9: DECLARE và SET khác nhau như thế nào với SELECT khi gán biến?

A:

DECLARE @Name NVARCHAR(100);

-- SET: chỉ gán một giá trị, nếu query trả về nhiều row thì lỗi
SET @Name = (SELECT Name FROM Employees WHERE Id = 1);

-- SELECT: gán giá trị cuối cùng nếu nhiều rows
SELECT @Name = Name FROM Employees WHERE DepartmentId = 5;
-- Nếu không có row nào thỏa điều kiện:
-- SET -> @Name = NULL
-- SELECT -> @Name giữ nguyên giá trị cũ (nguy hiểm!)

Q10: @@ROWCOUNT và @@ERROR dùng để làm gì?

A:

• @@ROWCOUNT: Số dòng bị ảnh hưởng bởi câu lệnh cuối cùng
• @@ERROR: Error number của lỗi cuối (0 nếu không có lỗi)

UPDATE Orders SET Status = 'Shipped' WHERE OrderId = 100;
IF @@ROWCOUNT = 0
    PRINT 'Không tìm thấy Order';

Lưu ý: @@ERROR bị reset sau mỗi câu lệnh. Dùng TRY...CATCH thay thế trong code hiện đại.

🟡 Mid Level

Q11: Parameter Sniffing trong Stored Procedure là gì? Cách xử lý?

A: Parameter Sniffing là cơ chế SQL Server compile execution plan dựa trên giá trị tham số đầu tiên được sử dụng. Plan tốt cho giá trị đó có thể rất tệ cho giá trị khác.

-- Vấn đề: Compile với @CustomerId = 1 (ít orders)
-- Plan dùng Index Seek. Nhưng khi gọi với @CustomerId = 999 (nhiều orders)
-- vẫn dùng plan cũ -> chậm

CREATE PROCEDURE GetCustomerOrders @CustomerId INT
AS
    SELECT * FROM Orders WHERE CustomerId = @CustomerId;

-- Giải pháp 1: OPTION (RECOMPILE) - recompile mỗi lần
CREATE PROCEDURE GetCustomerOrders @CustomerId INT
AS
    SELECT * FROM Orders WHERE CustomerId = @CustomerId
    OPTION (RECOMPILE);

-- Giải pháp 2: Local variables (ngăn sniffing, mất một số optimization)
CREATE PROCEDURE GetCustomerOrders @CustomerId INT
AS
    DECLARE @LocalCustomerId INT = @CustomerId;
    SELECT * FROM Orders WHERE CustomerId = @LocalCustomerId;

-- Giải pháp 3: WITH RECOMPILE ở SP level
CREATE PROCEDURE GetCustomerOrders @CustomerId INT
WITH RECOMPILE
AS
    SELECT * FROM Orders WHERE CustomerId = @CustomerId;

Q12: Dynamic SQL là gì? sp_executesql có lợi ích gì so với EXEC()?

A: Dynamic SQL là SQL được xây dựng và thực thi lúc runtime.

-- EXEC() - không parameterized, dễ SQL injection
EXEC ('SELECT * FROM ' + @TableName + ' WHERE Id = ' + @Id);

-- sp_executesql - parameterized, safe, plan reuse
DECLARE @SQL NVARCHAR(MAX);
DECLARE @Params NVARCHAR(500);

SET @SQL = N'SELECT * FROM Orders WHERE CustomerId = @CustId AND Status = @Status';
SET @Params = N'@CustId INT, @Status NVARCHAR(50)';

EXEC sp_executesql @SQL, @Params, 
    @CustId = @CustomerId, 
    @Status = @OrderStatus;

Lợi ích của sp_executesql:

1. Parameterized: Ngăn SQL injection
2. Plan caching: Cùng SQL text → tái sử dụng execution plan
3. Output parameters: Có thể nhận giá trị trả về

Q13: Indexed View (Materialized View) là gì? Yêu cầu để tạo Indexed View?

A: Indexed View là view có dữ liệu được vật lý hóa (stored) trên disk, cập nhật tự động khi base tables thay đổi.

Yêu cầu bắt buộc:

1. WITH SCHEMABINDING trong CREATE VIEW
2. Unique Clustered Index là index đầu tiên tạo trên view
3. Các function phải deterministic
4. Không dùng *, DISTINCT, TOP, OUTER JOIN, subqueries, CTEs
5. SET ANSI_NULLS ON và SET QUOTED_IDENTIFIER ON

CREATE VIEW dbo.vw_SalesSummary
WITH SCHEMABINDING
AS
    SELECT 
        p.CategoryId,
        COUNT_BIG(*) AS TotalOrders,
        SUM(od.Quantity * od.UnitPrice) AS TotalRevenue
    FROM dbo.OrderDetails od
    INNER JOIN dbo.Products p ON od.ProductId = p.ProductId
    GROUP BY p.CategoryId;
GO

-- Tạo unique clustered index để materialize
CREATE UNIQUE CLUSTERED INDEX IX_vw_SalesSummary
ON dbo.vw_SalesSummary (CategoryId);

Q14: Recursive CTE hoạt động như thế nào? Viết query duyệt cây phân cấp?

A: Recursive CTE gồm hai phần:

• Anchor member: Query không đệ quy, trả về điểm bắt đầu
• Recursive member: Query tham chiếu chính CTE đó

-- Bảng phân cấp nhân viên
-- EmployeeId, Name, ManagerId

WITH EmployeeHierarchy AS (
    -- Anchor: CEO (không có manager)
    SELECT 
        EmployeeId, Name, ManagerId,
        0 AS Level,
        CAST(Name AS NVARCHAR(MAX)) AS Path
    FROM Employees
    WHERE ManagerId IS NULL

    UNION ALL

    -- Recursive: tìm direct reports
    SELECT 
        e.EmployeeId, e.Name, e.ManagerId,
        eh.Level + 1,
        eh.Path + ' > ' + e.Name
    FROM Employees e
    INNER JOIN EmployeeHierarchy eh ON e.ManagerId = eh.EmployeeId
)
SELECT EmployeeId, Name, Level, Path
FROM EmployeeHierarchy
OPTION (MAXRECURSION 100); -- giới hạn độ sâu đệ quy

Q15: Sự khác nhau giữa AFTER trigger và INSTEAD OF trigger?

A:

-- INSTEAD OF trigger trên view cho phép update
CREATE TRIGGER trg_InsertOrderSummary
ON vw_OrderSummary
INSTEAD OF INSERT
AS
BEGIN
    -- Tự viết logic INSERT vào base tables
    INSERT INTO Orders (CustomerId, OrderDate)
    SELECT CustomerId, OrderDate FROM inserted;
END;

Q16: LAG() và LEAD() dùng để làm gì? Cho ví dụ tính month-over-month growth?

A:

-- LAG: lấy giá trị từ row trước
-- LEAD: lấy giá trị từ row sau
SELECT
    Month,
    Revenue,
    LAG(Revenue, 1, 0) OVER (ORDER BY Month) AS PrevMonthRevenue,
    LEAD(Revenue, 1, 0) OVER (ORDER BY Month) AS NextMonthRevenue,
    Revenue - LAG(Revenue, 1, 0) OVER (ORDER BY Month) AS MoMChange,
    CASE 
        WHEN LAG(Revenue, 1, 0) OVER (ORDER BY Month) = 0 THEN NULL
        ELSE CAST(
            (Revenue - LAG(Revenue, 1, 0) OVER (ORDER BY Month)) * 100.0 
            / LAG(Revenue, 1, 0) OVER (ORDER BY Month) 
            AS DECIMAL(10,2))
    END AS MoMGrowthPct
FROM MonthlySales
ORDER BY Month;

Q17: Running Total (Cumulative Sum) tính như thế nào với Window Functions?

A:

SELECT
    OrderDate,
    OrderAmount,
    SUM(OrderAmount) OVER (
        ORDER BY OrderDate
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS RunningTotal
FROM Orders;

-- So sánh ROWS vs RANGE:
-- ROWS BETWEEN: tính theo vị trí vật lý (exact)
-- RANGE BETWEEN: tính theo giá trị (bao gồm ties)
-- ROWS thường hiệu năng tốt hơn

Q18: Khi nào dùng CTE, khi nào dùng Temp Table, khi nào dùng Table Variable?

A:

Q19: SCHEMABINDING trong View và Function có tác dụng gì?

A: WITH SCHEMABINDING ràng buộc object (view/function) với schema của các base objects.

• Không thể DROP hoặc ALTER base tables/columns khi chưa DROP view/function trước
• Bắt buộc để tạo Indexed View
• Cho phép function/view được đánh dấu là deterministic → có thể dùng trong computed column, index

-- Không thể DROP Products.Price nếu còn view này
CREATE VIEW dbo.vw_ProductPrices
WITH SCHEMABINDING
AS
    SELECT ProductId, ProductName, Price
    FROM dbo.Products; -- Phải dùng schema name (dbo.)

Q20: TRY…CATCH trong T-SQL hoạt động như thế nào?

A:

BEGIN TRY
    BEGIN TRANSACTION;
    
    INSERT INTO Orders (CustomerId, Amount) VALUES (1, 500);
    UPDATE Inventory SET Stock = Stock - 1 WHERE ProductId = 10;
    
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;
    
    -- Lấy thông tin lỗi
    SELECT
        ERROR_NUMBER()    AS ErrorNumber,
        ERROR_MESSAGE()   AS ErrorMessage,
        ERROR_SEVERITY()  AS Severity,
        ERROR_STATE()     AS State,
        ERROR_LINE()      AS ErrorLine,
        ERROR_PROCEDURE() AS ErrorProcedure;
    
    -- Re-throw lỗi (SQL 2012+)
    THROW;
END CATCH;

Q21: RAISERROR và THROW khác nhau như thế nào?

A:

-- THROW re-throw trong CATCH
BEGIN CATCH
    ROLLBACK TRANSACTION;
    THROW; -- Re-throws original error với full context
END CATCH;

-- RAISERROR custom message
RAISERROR('Số lượng không được âm', 16, 1);

-- THROW custom
THROW 50001, 'Số lượng không được âm', 1;

🔴 Senior Level

Q22: Giải thích vấn đề “Halloween Protection” trong SQL Server và ảnh hưởng đến trigger?

A: Halloween Protection là cơ chế SQL Server đảm bảo rằng một row không bị thay đổi nhiều lần trong cùng một câu DML. SQL Server đôi khi phải dùng eager spool operator, có thể ảnh hưởng hiệu năng.

Với trigger, inserted và deleted tables chứa snapshot của rows bị ảnh hưởng, không phải toàn bộ bảng. Trigger phải xử lý multi-row operations:

-- Anti-pattern: Giả sử chỉ một row bị UPDATE
CREATE TRIGGER trg_AfterUpdate ON Orders AFTER UPDATE
AS
BEGIN
    DECLARE @OrderId INT = (SELECT OrderId FROM inserted); -- SAI khi nhiều rows!
    UPDATE OrderAudit SET ModifiedDate = GETDATE() WHERE OrderId = @OrderId;
END;

-- Đúng: Xử lý set-based
CREATE TRIGGER trg_AfterUpdate ON Orders AFTER UPDATE
AS
BEGIN
    UPDATE oa
    SET ModifiedDate = GETDATE()
    FROM OrderAudit oa
    INNER JOIN inserted i ON oa.OrderId = i.OrderId;
END;

Q23: Scalar UDF Inlining trong SQL Server 2019 là gì? Điều kiện để một UDF được inline?

A: Scalar UDF Inlining là tính năng SQL 2019 tự động chuyển đổi eligible scalar UDFs thành relational expressions (như inline views), cho phép:

• Parallelism (trước đây UDF bắt query dùng single-thread)
• Cost-based optimization
• Push predicates vào UDF

Điều kiện để được inline:

1. Chỉ có một RETURN statement
2. Không dùng EXECUTE
3. Không dùng recursive calls
4. Không dùng TRY...CATCH
5. Không dùng table variables
6. Không có side effects (chỉ SELECT)
7. Không gọi các functions không deterministic như RAND(), NEWID()

-- Kiểm tra UDF có được inline không
SELECT 
    name,
    is_inlineable
FROM sys.sql_modules sm
JOIN sys.objects o ON sm.object_id = o.object_id
WHERE o.type = 'FN';

-- Force inline (nếu không eligible tự động)
SELECT dbo.GetDiscount(ProductId) WITH INLINE = ON
-- hoặc disable:
SELECT dbo.GetDiscount(ProductId) WITH INLINE = OFF

Q24: Giải thích ROWS BETWEEN vs RANGE BETWEEN trong Window Functions. Performance implications?

A:

-- ROWS: frame theo vị trí vật lý (exact row count)
SUM(Amount) OVER (ORDER BY Date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)

-- RANGE: frame theo giá trị (bao gồm tất cả rows cùng giá trị ORDER BY)
SUM(Amount) OVER (ORDER BY Date RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)

Sự khác biệt với ties:

• Nếu có nhiều rows cùng Date:
  • ROWS: Running total tính đến chính xác row hiện tại
  • RANGE: Running total bao gồm tất cả rows cùng Date

Performance:

• RANGE BETWEEN yêu cầu spool operator (lưu tạm kết quả) → chậm hơn
• ROWS BETWEEN hiệu quả hơn, ít tốn memory hơn
• Khi không chỉ định: default là RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW → nên luôn explicit dùng ROWS

Q25: CDC (Change Data Capture) vs Triggers: khi nào dùng cái nào?

A:

CDC phù hợp hơn khi:

• Cần audit history mà không muốn ảnh hưởng performance
• ETL pipeline cần biết changed data
• Replication-like scenarios

Trigger phù hợp hơn khi:

• Cần real-time validation/enforcement
• Cần cascade business logic ngay lập tức
• Cần reject DML dựa trên điều kiện phức tạp

Q26: SAVE TRANSACTION (Savepoint) hoạt động như thế nào? Khi nào dùng?

A:

BEGIN TRANSACTION OuterTran;

    INSERT INTO AuditLog (Action) VALUES ('Start process');

    SAVE TRANSACTION SavePoint1; -- Tạo savepoint

    BEGIN TRY
        INSERT INTO Orders (CustomerId) VALUES (999); -- Có thể lỗi
        
        SAVE TRANSACTION SavePoint2;
        
        UPDATE Inventory SET Stock = Stock - 1 WHERE ProductId = 1;
        
    END TRY
    BEGIN CATCH
        -- Rollback về savepoint, không rollback toàn bộ
        ROLLBACK TRANSACTION SavePoint1;
        -- AuditLog INSERT vẫn còn
        INSERT INTO AuditLog (Action) VALUES ('Order failed: ' + ERROR_MESSAGE());
    END CATCH;

COMMIT TRANSACTION OuterTran;

Lưu ý quan trọng:

• ROLLBACK TRANSACTION SavepointName chỉ undo đến savepoint, không kết thúc transaction
• @@TRANCOUNT không thay đổi khi rollback về savepoint
• Savepoint không thực sự “commit” data, data chỉ commit khi outer transaction commit

Q27: COLUMNS_UPDATED() và UPDATE() function trong trigger dùng như thế nào?

A:

CREATE TRIGGER trg_OrderUpdate ON Orders AFTER UPDATE
AS
BEGIN
    -- UPDATE(column): kiểm tra column có trong UPDATE statement không
    IF UPDATE(Status) OR UPDATE(Amount)
    BEGIN
        INSERT INTO OrderAuditLog (OrderId, ChangedBy, ChangeTime)
        SELECT i.OrderId, SYSTEM_USER, GETDATE()
        FROM inserted i;
    END;

    -- COLUMNS_UPDATED(): bitmap của columns được update
    -- Ít dùng hơn vì phức tạp, phụ thuộc vào ordinal position
    IF (COLUMNS_UPDATED() & 4) = 4 -- Column thứ 3 (bit 3 = 4)
    BEGIN
        -- Column 3 được update
    END;
END;

Q28: Nested Stored Procedures và @@NESTLEVEL. Giới hạn là bao nhiêu?

A:

• SQL Server cho phép tối đa 32 levels của nested procedure calls
• @@NESTLEVEL trả về level hiện tại (0 = top level, 1 = called from top-level SP, …)

CREATE PROCEDURE dbo.OuterProc
AS
BEGIN
    SELECT @@NESTLEVEL; -- Returns 1
    EXEC dbo.InnerProc;
END;

CREATE PROCEDURE dbo.InnerProc
AS
BEGIN
    SELECT @@NESTLEVEL; -- Returns 2
    
    IF @@NESTLEVEL > 16
    BEGIN
        THROW 50001, 'Quá nhiều nested calls', 1;
    END;
END;

Q29: Gaps and Islands problem - giải quyết bằng Window Functions?

A: Bài toán tìm các dải liên tiếp (islands) và khoảng trống (gaps) trong dữ liệu.

-- Dữ liệu: LoginDate của user
-- Tìm các "dải" ngày liên tiếp user login

WITH LoginData AS (
    SELECT 
        UserId,
        LoginDate,
        ROW_NUMBER() OVER (PARTITION BY UserId ORDER BY LoginDate) AS RowNum
    FROM UserLogins
),
Islands AS (
    SELECT
        UserId,
        LoginDate,
        DATEADD(DAY, -RowNum, LoginDate) AS IslandGroup -- Ngày trừ đi row number
    FROM LoginData
)
SELECT
    UserId,
    MIN(LoginDate) AS IslandStart,
    MAX(LoginDate) AS IslandEnd,
    DATEDIFF(DAY, MIN(LoginDate), MAX(LoginDate)) + 1 AS ConsecutiveDays
FROM Islands
GROUP BY UserId, IslandGroup
ORDER BY UserId, IslandStart;

Q30: Giải thích “deferred name resolution” trong Stored Procedures. Ảnh hưởng gì?

A: SQL Server không verify tên của objects trong stored procedure tại thời điểm CREATE PROCEDURE, mà chỉ resolve khi SP được thực thi. Điều này có nghĩa:

-- Tạo SP thành công dù NonExistentTable chưa tồn tại
CREATE PROCEDURE dbo.MyProc
AS
    SELECT * FROM NonExistentTable; -- Không lỗi khi CREATE
GO

-- Chỉ lỗi khi EXEC
EXEC dbo.MyProc; -- Lỗi: Invalid object name 'NonExistentTable'

Ảnh hưởng:

• Cho phép tạo SP trước khi tables tồn tại (useful trong deployment scenarios)
• Có thể tạo ra lỗi runtime khó debug
• Ngoại lệ: Column names và data types được resolve lúc compile → lỗi nếu column không tồn tại

Best practice: Dùng sys.sql_modules hoặc sp_refreshsqlmodule để refresh dependencies sau khi schema thay đổi.

Q31: Viết query phân trang (pagination) hiệu năng cao với Window Functions?

A:

-- Cách 1: OFFSET/FETCH (SQL 2012+) - đơn giản nhưng chậm với large offset
SELECT *
FROM Products
ORDER BY ProductId
OFFSET (@Page - 1) * @PageSize ROWS
FETCH NEXT @PageSize ROWS ONLY;

-- Cách 2: Keyset pagination (Seek method) - hiệu năng cao
-- Dùng giá trị cuối của page trước thay vì OFFSET
SELECT TOP (@PageSize) *
FROM Products
WHERE ProductId > @LastProductId -- @LastProductId = ProductId cuối page trước
ORDER BY ProductId;

-- Cách 3: ROW_NUMBER() approach
WITH PagedData AS (
    SELECT
        *,
        ROW_NUMBER() OVER (ORDER BY ProductId) AS RowNum
    FROM Products
)
SELECT *
FROM PagedData
WHERE RowNum BETWEEN (@Page - 1) * @PageSize + 1 AND @Page * @PageSize;

So sánh hiệu năng:

• OFFSET/FETCH: Tốt cho small-medium datasets, dễ implement
• Keyset: Tốt nhất cho large datasets, nhưng không hỗ trợ random page access
• ROW_NUMBER(): Linh hoạt nhưng phải tính toán toàn bộ resultset

Q32: Sự khác nhau giữa FAST_FORWARD cursor và SET-BASED operations. Khi nào cursor thực sự cần thiết?

A: FAST_FORWARD là cursor type nhanh nhất (read-only, forward-only), nhưng vẫn chậm hơn set-based nhiều.

Cursor thực sự cần khi:

1. Gọi Stored Procedure cho mỗi row (không thể set-based)
2. Cần gửi kết quả row-by-row qua network stream
3. Logic quá phức tạp không thể biểu diễn bằng set-based

-- Cursor FAST_FORWARD (nhanh nhất nếu phải dùng cursor)
DECLARE @OrderId INT;

DECLARE cur CURSOR FAST_FORWARD FOR
    SELECT OrderId FROM Orders WHERE Status = 'Pending';

OPEN cur;
FETCH NEXT FROM cur INTO @OrderId;

WHILE @@FETCH_STATUS = 0
BEGIN
    EXEC ProcessOrder @OrderId; -- Gọi SP cho từng row
    FETCH NEXT FROM cur INTO @OrderId;
END;

CLOSE cur;
DEALLOCATE cur;

-- Thay thế bằng: EXECUTE dùng STRING_AGG hoặc XML để batch

Q33: Giải thích cách SQL Server cache execution plans. Khi nào plan bị invalidated?

A:

Plan caching mechanism:

1. SQL text được hash → tìm trong plan cache
2. Nếu tìm thấy → reuse (soft parse)
3. Nếu không → compile → lưu vào cache (hard parse)

Plan bị invalidated/evicted khi:

• Statistics được update (UPDATE STATISTICS)
• Index được tạo/drop/rebuild
• sp_recompile được gọi
• DBCC FREEPROCCACHE được chạy
• Bộ nhớ áp lực cao (cache eviction)
• Schema của referenced objects thay đổi
• SET options thay đổi (ANSI_NULLS, etc.)

-- Xem plan cache
SELECT 
    qs.execution_count,
    qs.total_elapsed_time / qs.execution_count AS avg_elapsed_time,
    SUBSTRING(qt.text, qs.statement_start_offset/2, 
        (CASE WHEN qs.statement_end_offset = -1 
              THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2 
              ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) AS query_text,
    qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY avg_elapsed_time DESC;

Stored Procedures

Stored Procedure (SP) là một tập hợp các câu lệnh T-SQL được biên dịch, đặt tên và lưu trữ trong database. SP là công cụ lập trình quan trọng nhất trong SQL Server, cho phép đóng gói business logic, tăng bảo mật và cải thiện hiệu năng.

1. Lợi ích của Stored Procedures

Execution Plan Caching

-- Lần đầu: SQL Server compile SP → lưu plan vào cache
EXEC dbo.GetCustomerOrders @CustomerId = 1;
-- Những lần sau: reuse plan từ cache (nhanh hơn)
EXEC dbo.GetCustomerOrders @CustomerId = 2;

-- Xem execution plan trong cache
SELECT 
    cp.usecounts,
    cp.objtype,
    qt.text
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) qt
WHERE qt.text LIKE '%GetCustomerOrders%';

2. Tạo và Gọi Stored Procedure

CREATE PROCEDURE

-- Cú pháp cơ bản
CREATE PROCEDURE dbo.GetActiveOrders
AS
BEGIN
    SET NOCOUNT ON; -- Tắt "X rows affected", giảm network traffic

    SELECT 
        OrderId,
        CustomerId,
        OrderDate,
        TotalAmount
    FROM Orders
    WHERE Status = 'Active'
    ORDER BY OrderDate DESC;
END;
GO

ALTER PROCEDURE và DROP PROCEDURE

-- Thay đổi SP (giữ nguyên permissions)
ALTER PROCEDURE dbo.GetActiveOrders
AS
BEGIN
    SET NOCOUNT ON;
    SELECT * FROM Orders WHERE Status = 'Active' AND IsDeleted = 0;
END;
GO

-- Xóa SP
DROP PROCEDURE IF EXISTS dbo.GetActiveOrders; -- SQL 2016+
-- hoặc
IF OBJECT_ID('dbo.GetActiveOrders', 'P') IS NOT NULL
    DROP PROCEDURE dbo.GetActiveOrders;

Input Parameters

CREATE PROCEDURE dbo.GetOrdersByCustomer
    @CustomerId     INT,
    @Status         NVARCHAR(50),
    @StartDate      DATE = NULL, -- Tham số có giá trị mặc định
    @EndDate        DATE = NULL,
    @MaxRows        INT = 100
AS
BEGIN
    SET NOCOUNT ON;

    SELECT TOP (@MaxRows)
        o.OrderId,
        o.OrderDate,
        o.TotalAmount,
        c.CustomerName
    FROM Orders o
    INNER JOIN Customers c ON o.CustomerId = c.CustomerId
    WHERE 
        o.CustomerId = @CustomerId
        AND o.Status = @Status
        AND (@StartDate IS NULL OR o.OrderDate >= @StartDate)
        AND (@EndDate IS NULL OR o.OrderDate <= @EndDate)
    ORDER BY o.OrderDate DESC;
END;
GO

-- Gọi SP với named parameters (khuyến cáo)
EXEC dbo.GetOrdersByCustomer
    @CustomerId = 1,
    @Status = 'Shipped',
    @StartDate = '2025-01-01';

-- Gọi với positional parameters (không khuyến cáo)
EXEC dbo.GetOrdersByCustomer 1, 'Shipped';

OUTPUT Parameters

CREATE PROCEDURE dbo.CreateOrder
    @CustomerId     INT,
    @TotalAmount    DECIMAL(18,2),
    @OrderId        INT OUTPUT,      -- OUTPUT parameter
    @ErrorMessage   NVARCHAR(500) OUTPUT
AS
BEGIN
    SET NOCOUNT ON;

    SET @ErrorMessage = NULL;

    IF @TotalAmount <= 0
    BEGIN
        SET @ErrorMessage = 'TotalAmount phải lớn hơn 0';
        SET @OrderId = -1;
        RETURN -1; -- Return code
    END;

    INSERT INTO Orders (CustomerId, TotalAmount, OrderDate, Status)
    VALUES (@CustomerId, @TotalAmount, GETDATE(), 'Pending');

    SET @OrderId = SCOPE_IDENTITY(); -- Lấy ID vừa insert

    RETURN 0; -- Thành công
END;
GO

-- Gọi SP với OUTPUT parameters
DECLARE @NewOrderId INT;
DECLARE @ErrMsg NVARCHAR(500);
DECLARE @ReturnCode INT;

EXEC @ReturnCode = dbo.CreateOrder
    @CustomerId   = 5,
    @TotalAmount  = 299.99,
    @OrderId      = @NewOrderId OUTPUT,
    @ErrorMessage = @ErrMsg OUTPUT;

IF @ReturnCode = 0
    PRINT 'Order created: ' + CAST(@NewOrderId AS VARCHAR);
ELSE
    PRINT 'Error: ' + @ErrMsg;

EXEC vs EXECUTE

-- Hai cú pháp tương đương
EXEC dbo.GetActiveOrders;
EXECUTE dbo.GetActiveOrders;

-- EXEC cũng có thể chạy dynamic string
EXEC ('SELECT GETDATE()');

3. Control Flow

IF/ELSE

CREATE PROCEDURE dbo.ProcessPayment
    @OrderId    INT,
    @Amount     DECIMAL(18,2)
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @CurrentBalance DECIMAL(18,2);

    SELECT @CurrentBalance = Balance 
    FROM CustomerAccounts 
    WHERE CustomerId = (SELECT CustomerId FROM Orders WHERE OrderId = @OrderId);

    IF @CurrentBalance >= @Amount
    BEGIN
        -- Block code khi điều kiện đúng
        UPDATE CustomerAccounts 
        SET Balance = Balance - @Amount
        WHERE CustomerId = (SELECT CustomerId FROM Orders WHERE OrderId = @OrderId);

        UPDATE Orders SET Status = 'Paid' WHERE OrderId = @OrderId;
        PRINT 'Thanh toán thành công';
    END
    ELSE IF @CurrentBalance > 0
    BEGIN
        PRINT 'Số dư không đủ. Còn: ' + CAST(@CurrentBalance AS VARCHAR(20));
    END
    ELSE
    BEGIN
        PRINT 'Tài khoản không có số dư';
    END;
END;

WHILE, BREAK, CONTINUE

CREATE PROCEDURE dbo.GenerateMonthlySummary
    @Year INT
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @Month INT = 1;

    WHILE @Month <= 12
    BEGIN
        -- CONTINUE: bỏ qua tháng nếu không có dữ liệu
        IF NOT EXISTS (SELECT 1 FROM Orders 
                       WHERE YEAR(OrderDate) = @Year 
                       AND MONTH(OrderDate) = @Month)
        BEGIN
            SET @Month = @Month + 1;
            CONTINUE;
        END;

        -- Xử lý tháng hiện tại
        INSERT INTO MonthlySummary (Year, Month, TotalOrders, TotalRevenue)
        SELECT 
            @Year,
            @Month,
            COUNT(*),
            SUM(TotalAmount)
        FROM Orders
        WHERE YEAR(OrderDate) = @Year AND MONTH(OrderDate) = @Month;

        -- BREAK: dừng vòng lặp nếu đủ 6 tháng đầu
        IF @Month = 6
        BEGIN
            BREAK;
        END;

        SET @Month = @Month + 1;
    END;
END;

RETURN

CREATE PROCEDURE dbo.ValidateCustomer
    @CustomerId INT
AS
BEGIN
    IF @CustomerId <= 0
    BEGIN
        RETURN -1; -- Return code âm = lỗi
    END;

    IF NOT EXISTS (SELECT 1 FROM Customers WHERE CustomerId = @CustomerId AND IsActive = 1)
    BEGIN
        RETURN -2; -- Customer không tồn tại hoặc inactive
    END;

    -- Tiếp tục xử lý...
    RETURN 0; -- Thành công
END;
GO

DECLARE @Result INT;
EXEC @Result = dbo.ValidateCustomer @CustomerId = 5;
IF @Result <> 0
    PRINT 'Validation failed with code: ' + CAST(@Result AS VARCHAR);

GOTO (Tại sao nên tránh)

-- GOTO làm code khó đọc, khó maintain - NÊN TRÁNH
CREATE PROCEDURE dbo.ProcessWithGoto
AS
BEGIN
    DECLARE @Counter INT = 0;
    
    StartLoop:
        IF @Counter >= 10 GOTO EndLoop;
        SET @Counter = @Counter + 1;
        
        IF @Counter = 5 GOTO SkipFive;
        PRINT @Counter;
        
    SkipFive:
        GOTO StartLoop;
    
    EndLoop:
        PRINT 'Done';
END;

-- THAY THẾ BẰNG: WHILE với CONTINUE là rõ ràng hơn

4. Variables

CREATE PROCEDURE dbo.CalculateOrderStats
    @CustomerId INT
AS
BEGIN
    SET NOCOUNT ON;

    -- DECLARE nhiều biến
    DECLARE 
        @TotalOrders    INT,
        @TotalSpent     DECIMAL(18,2),
        @AverageOrder   DECIMAL(18,2),
        @CustomerName   NVARCHAR(200);

    -- SET: gán một giá trị cụ thể
    SET @CustomerName = (
        SELECT CustomerName 
        FROM Customers 
        WHERE CustomerId = @CustomerId
    );

    -- SELECT: gán từ query (linh hoạt hơn cho multiple columns)
    SELECT 
        @TotalOrders  = COUNT(*),
        @TotalSpent   = SUM(TotalAmount)
    FROM Orders
    WHERE CustomerId = @CustomerId AND Status = 'Completed';

    -- Tính toán
    SET @AverageOrder = CASE 
        WHEN @TotalOrders > 0 THEN @TotalSpent / @TotalOrders 
        ELSE 0 
    END;

    -- Kết quả
    SELECT 
        @CustomerName AS CustomerName,
        @TotalOrders  AS TotalOrders,
        @TotalSpent   AS TotalSpent,
        @AverageOrder AS AverageOrderValue;
END;

Lưu ý quan trọng: Nếu SELECT @Variable = column FROM table WHERE condition không tìm thấy row nào, biến giữ nguyên giá trị trước đó (không về NULL). Đây là một nguy cơ bug phổ biến!

5. Temp Tables trong Stored Procedures

Local Temp Table (#) vs Global Temp Table (##)

CREATE PROCEDURE dbo.ProcessLargeDataset
    @BatchSize INT = 1000
AS
BEGIN
    SET NOCOUNT ON;

    -- LOCAL temp table: chỉ visible trong session hiện tại
    -- Tự động drop khi SP kết thúc
    CREATE TABLE #TempOrders (
        OrderId     INT,
        CustomerId  INT,
        TotalAmount DECIMAL(18,2),
        INDEX IX_Temp_CustomerId (CustomerId) -- Có thể thêm index!
    );

    INSERT INTO #TempOrders (OrderId, CustomerId, TotalAmount)
    SELECT OrderId, CustomerId, TotalAmount
    FROM Orders
    WHERE Status = 'Pending' AND ProcessedFlag = 0;

    -- GLOBAL temp table: visible cho tất cả sessions
    -- Dùng khi cần share data giữa các sessions/connections
    -- CREATE TABLE ##GlobalTemp (...)  -- Hiếm khi dùng

    -- Xử lý từng batch
    WHILE EXISTS (SELECT 1 FROM #TempOrders WHERE ProcessedFlag IS NULL)
    BEGIN
        UPDATE TOP (@BatchSize) #TempOrders
        SET ProcessedFlag = 1
        OUTPUT inserted.OrderId, inserted.TotalAmount
        INTO OrderProcessingLog (OrderId, Amount)
        WHERE ProcessedFlag IS NULL;
    END;

    -- Explicit drop (optional, sẽ tự drop khi SP kết thúc)
    DROP TABLE IF EXISTS #TempOrders;
END;

Temp Table vs Table Variable

-- Table Variable: nhỏ, no statistics, ít log overhead
DECLARE @OrderSummary TABLE (
    CustomerId  INT,
    OrderCount  INT,
    TotalAmount DECIMAL(18,2)
);

INSERT INTO @OrderSummary
SELECT CustomerId, COUNT(*), SUM(TotalAmount)
FROM Orders
GROUP BY CustomerId;

-- Temp Table: lớn, có statistics, optimizer dùng được
CREATE TABLE #OrderSummary (
    CustomerId  INT PRIMARY KEY,
    OrderCount  INT,
    TotalAmount DECIMAL(18,2)
);

-- Dùng Temp Table khi:
-- 1. Dataset lớn (> vài nghìn rows)
-- 2. Cần index phức tạp
-- 3. Cần thống kê (statistics) để optimizer plan tốt
-- 4. Reuse trong nhiều queries

6. Error Handling

TRY…CATCH

CREATE PROCEDURE dbo.TransferFunds
    @FromAccountId  INT,
    @ToAccountId    INT,
    @Amount         DECIMAL(18,2)
AS
BEGIN
    SET NOCOUNT ON;

    IF @Amount <= 0
        THROW 50001, 'Số tiền chuyển phải lớn hơn 0', 1;

    BEGIN TRY
        BEGIN TRANSACTION;

        -- Kiểm tra số dư
        DECLARE @Balance DECIMAL(18,2);
        SELECT @Balance = Balance FROM Accounts WHERE AccountId = @FromAccountId;

        IF @Balance < @Amount
            THROW 50002, 'Số dư không đủ để thực hiện giao dịch', 1;

        -- Thực hiện transfer
        UPDATE Accounts SET Balance = Balance - @Amount WHERE AccountId = @FromAccountId;
        UPDATE Accounts SET Balance = Balance + @Amount WHERE AccountId = @ToAccountId;

        -- Ghi log
        INSERT INTO TransactionLog (FromAccount, ToAccount, Amount, TransactionDate)
        VALUES (@FromAccountId, @ToAccountId, @Amount, GETDATEUTCDATE());

        COMMIT TRANSACTION;
        PRINT 'Transfer thành công';

    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0
            ROLLBACK TRANSACTION;

        -- Lấy thông tin lỗi
        DECLARE 
            @ErrorNumber    INT = ERROR_NUMBER(),
            @ErrorMessage   NVARCHAR(4000) = ERROR_MESSAGE(),
            @ErrorSeverity  INT = ERROR_SEVERITY(),
            @ErrorState     INT = ERROR_STATE(),
            @ErrorLine      INT = ERROR_LINE(),
            @ErrorProc      NVARCHAR(200) = ERROR_PROCEDURE();

        -- Ghi log lỗi
        INSERT INTO ErrorLog (ErrorNumber, ErrorMessage, ErrorProcedure, ErrorLine, CreatedAt)
        VALUES (@ErrorNumber, @ErrorMessage, @ErrorProc, @ErrorLine, GETDATE());

        -- Re-throw lỗi cho caller
        THROW;
    END CATCH;
END;

ERROR_ Functions

-- Các function lấy thông tin lỗi trong CATCH block
BEGIN CATCH
    SELECT
        ERROR_NUMBER()    AS ErrorNumber,    -- Số hiệu lỗi
        ERROR_MESSAGE()   AS ErrorMessage,   -- Thông điệp lỗi
        ERROR_SEVERITY()  AS ErrorSeverity,  -- Mức độ nghiêm trọng (1-25)
        ERROR_STATE()     AS ErrorState,     -- State code
        ERROR_LINE()      AS ErrorLine,      -- Dòng code gây lỗi
        ERROR_PROCEDURE() AS ErrorProcedure; -- Tên SP/trigger gây lỗi
END CATCH;

RAISERROR vs THROW

-- RAISERROR (cũ, nhưng vẫn dùng)
RAISERROR('Lỗi xử lý đơn hàng %d', 16, 1, @OrderId);
-- %d = int placeholder, %s = string placeholder

-- THROW (SQL 2012+, khuyến cáo dùng)
THROW 50001, 'Lỗi xử lý đơn hàng', 1;

-- Re-throw trong CATCH (không tham số)
BEGIN CATCH
    ROLLBACK TRANSACTION;
    THROW; -- Giữ nguyên error number, message, state gốc
END CATCH;

7. Nested Stored Procedures

-- SP cấp 1: Outer
CREATE PROCEDURE dbo.ProcessDailyBatch
AS
BEGIN
    SET NOCOUNT ON;
    PRINT 'NESTLEVEL: ' + CAST(@@NESTLEVEL AS VARCHAR); -- 1

    -- Gọi SP khác
    EXEC dbo.ValidateOrders;
    EXEC dbo.UpdateInventory;
    EXEC dbo.SendNotifications;
END;

-- SP cấp 2: Inner
CREATE PROCEDURE dbo.ValidateOrders
AS
BEGIN
    SET NOCOUNT ON;
    PRINT 'NESTLEVEL: ' + CAST(@@NESTLEVEL AS VARCHAR); -- 2

    EXEC dbo.CheckOrderRules; -- Level 3
END;

-- Giới hạn: tối đa 32 levels
-- @@NESTLEVEL = 0 khi gọi trực tiếp từ client

8. Transactions trong Stored Procedures

CREATE PROCEDURE dbo.PlaceOrder
    @CustomerId     INT,
    @Items          OrderItemType READONLY, -- Table-valued parameter
    @OrderId        INT OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
    SET XACT_ABORT ON; -- Tự động rollback khi có lỗi runtime

    BEGIN TRY
        BEGIN TRANSACTION;

        -- Tạo Order
        INSERT INTO Orders (CustomerId, OrderDate, Status)
        VALUES (@CustomerId, GETDATE(), 'Pending');

        SET @OrderId = SCOPE_IDENTITY();

        -- Insert Order Items
        INSERT INTO OrderItems (OrderId, ProductId, Quantity, UnitPrice)
        SELECT @OrderId, ProductId, Quantity, UnitPrice
        FROM @Items;

        -- Cập nhật stock
        UPDATE p
        SET p.Stock = p.Stock - i.Quantity
        FROM Products p
        INNER JOIN @Items i ON p.ProductId = i.ProductId;

        -- Kiểm tra stock âm
        IF EXISTS (SELECT 1 FROM Products p INNER JOIN @Items i ON p.ProductId = i.ProductId WHERE p.Stock < 0)
            THROW 50003, 'Sản phẩm không đủ hàng trong kho', 1;

        COMMIT TRANSACTION;

    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0
            ROLLBACK TRANSACTION;
        THROW;
    END CATCH;
END;

@@TRANCOUNT và SAVE TRANSACTION

CREATE PROCEDURE dbo.UpdateWithSavepoint
AS
BEGIN
    -- @@TRANCOUNT: số transaction đang active
    PRINT '@@TRANCOUNT trước: ' + CAST(@@TRANCOUNT AS VARCHAR); -- 0

    BEGIN TRANSACTION; -- @@TRANCOUNT = 1

    INSERT INTO AuditLog (Event) VALUES ('Process started');

    SAVE TRANSACTION MySavepoint; -- Tạo savepoint

    BEGIN TRY
        -- Thao tác có thể lỗi
        INSERT INTO Orders (CustomerId, TotalAmount) VALUES (999999, -100);
    END TRY
    BEGIN CATCH
        -- Rollback về savepoint, giữ lại INSERT AuditLog
        ROLLBACK TRANSACTION MySavepoint;
        INSERT INTO AuditLog (Event) VALUES ('Order insert failed: ' + ERROR_MESSAGE());
    END CATCH;

    COMMIT TRANSACTION; -- Commit AuditLog inserts
END;

9. Dynamic SQL

sp_executesql (Khuyến cáo)

CREATE PROCEDURE dbo.SearchProducts
    @SearchTerm     NVARCHAR(100),
    @CategoryId     INT = NULL,
    @SortColumn     NVARCHAR(50) = 'ProductName',
    @SortDirection  NVARCHAR(4) = 'ASC'
AS
BEGIN
    SET NOCOUNT ON;

    -- Whitelist cho sort columns (ngăn SQL injection)
    IF @SortColumn NOT IN ('ProductName', 'Price', 'CreatedDate', 'Stock')
        SET @SortColumn = 'ProductName';

    IF @SortDirection NOT IN ('ASC', 'DESC')
        SET @SortDirection = 'ASC';

    DECLARE @SQL NVARCHAR(MAX);
    DECLARE @Params NVARCHAR(500);

    SET @SQL = N'
        SELECT ProductId, ProductName, Price, CategoryId
        FROM Products
        WHERE 
            (ProductName LIKE @SearchTerm OR Description LIKE @SearchTerm)
            AND (@CategoryId IS NULL OR CategoryId = @CategoryId)
            AND IsActive = 1
        ORDER BY ' + QUOTENAME(@SortColumn) + ' ' + @SortDirection; -- QUOTENAME bảo vệ tên column

    SET @Params = N'@SearchTerm NVARCHAR(100), @CategoryId INT';

    EXEC sp_executesql 
        @SQL, 
        @Params,
        @SearchTerm = '%' + @SearchTerm + '%',
        @CategoryId = @CategoryId;
END;

Nguy hiểm SQL Injection với EXEC()

-- ĐỪNG làm thế này - dễ bị SQL injection
DECLARE @SQL NVARCHAR(MAX);
SET @SQL = 'SELECT * FROM Products WHERE Name = ''' + @UserInput + '''';
EXEC (@SQL);
-- Nếu @UserInput = "'; DROP TABLE Products; --" thì GG!

-- ĐÚNG: Dùng sp_executesql với parameters
SET @SQL = N'SELECT * FROM Products WHERE Name = @Name';
EXEC sp_executesql @SQL, N'@Name NVARCHAR(200)', @Name = @UserInput;

10. Recompilation và Parameter Sniffing

Vấn đề Parameter Sniffing

-- SP này có vấn đề parameter sniffing
CREATE PROCEDURE dbo.GetOrders @CustomerId INT
AS
    SELECT * FROM Orders WHERE CustomerId = @CustomerId;
-- Nếu compile với CustomerId = 1 (ít orders) → Index Seek plan
-- Khi gọi với CustomerId = 999 (nhiều orders) → vẫn dùng Seek plan → chậm!

Các giải pháp

-- Giải pháp 1: OPTION (RECOMPILE) trên query
-- Recompile query này mỗi lần, tốt cho queries không consistent
CREATE PROCEDURE dbo.GetOrders @CustomerId INT
AS
    SELECT * FROM Orders 
    WHERE CustomerId = @CustomerId
    OPTION (RECOMPILE); -- Recompile mỗi lần, overhead nhỏ

-- Giải pháp 2: WITH RECOMPILE trên SP
-- Recompile toàn bộ SP mỗi lần
CREATE PROCEDURE dbo.GetOrders @CustomerId INT
WITH RECOMPILE -- Không cache plan
AS
    SELECT * FROM Orders WHERE CustomerId = @CustomerId;

-- Giải pháp 3: Local variable (ngăn sniffing)
-- Optimizer không biết giá trị → dùng statistics thay vì parameter value
CREATE PROCEDURE dbo.GetOrders @CustomerId INT
AS
    DECLARE @LocalId INT = @CustomerId;
    SELECT * FROM Orders WHERE CustomerId = @LocalId;

-- Giải pháp 4: OPTIMIZE FOR hint
CREATE PROCEDURE dbo.GetOrders @CustomerId INT
AS
    SELECT * FROM Orders 
    WHERE CustomerId = @CustomerId
    OPTION (OPTIMIZE FOR (@CustomerId = 100)); -- Optimize cho giá trị điển hình

-- Giải pháp 5: OPTIMIZE FOR UNKNOWN
CREATE PROCEDURE dbo.GetOrders @CustomerId INT
AS
    SELECT * FROM Orders 
    WHERE CustomerId = @CustomerId
    OPTION (OPTIMIZE FOR (@CustomerId UNKNOWN)); -- Dùng statistics thay vì parameter value

sp_recompile

-- Force recompile SP lần sau khi gọi
EXEC sp_recompile 'dbo.GetOrders';

-- Force recompile tất cả SPs dùng bảng này
EXEC sp_recompile 'dbo.Orders';

11. System Stored Procedures

-- Thông tin về object
EXEC sp_help 'Orders';              -- Thông tin table/view
EXEC sp_helpindex 'Orders';         -- Danh sách indexes
EXEC sp_helpconstraint 'Orders';    -- Constraints

-- Monitoring
EXEC sp_who2;                       -- Các connections hiện tại
EXEC sp_lock;                       -- Locks đang active

-- Dynamic SQL (đã nói ở trên)
EXEC sp_executesql @SQL, @Params;

-- Thống kê
EXEC sp_updatestats;                -- Update tất cả statistics

-- Metadata
SELECT 
    name, 
    OBJECT_DEFINITION(object_id) AS Definition,
    create_date,
    modify_date
FROM sys.procedures
WHERE name LIKE 'GetOrder%';

-- Tìm SP nào reference đến một table
SELECT DISTINCT 
    o.name AS ProcedureName
FROM sys.sql_modules m
INNER JOIN sys.objects o ON m.object_id = o.object_id
WHERE 
    o.type = 'P'
    AND m.definition LIKE '%Orders%';

Best Practices Tóm Tắt

-- Template cho một Stored Procedure chuẩn
CREATE PROCEDURE dbo.MyProcedure
    @Param1 INT,
    @Param2 NVARCHAR(100) = NULL
AS
BEGIN
    SET NOCOUNT ON;      -- Tắt "X rows affected"
    SET XACT_ABORT ON;   -- Auto rollback khi lỗi

    -- Validate inputs
    IF @Param1 IS NULL OR @Param1 <= 0
        THROW 50001, 'Param1 không hợp lệ', 1;

    BEGIN TRY
        BEGIN TRANSACTION;

        -- Business logic ở đây

        COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF @@TRANCOUNT > 0
            ROLLBACK TRANSACTION;

        -- Log error
        INSERT INTO dbo.ErrorLog (ErrorMessage, ErrorProcedure, ErrorLine, CreatedAt)
        VALUES (ERROR_MESSAGE(), ERROR_PROCEDURE(), ERROR_LINE(), GETDATE());

        THROW; -- Re-throw cho caller
    END CATCH;
END;
GO

User-Defined Functions (UDFs)

User-Defined Functions (UDFs) trong SQL Server cho phép đóng gói logic tái sử dụng, trả về giá trị đơn hoặc tập kết quả dạng bảng. Khác với Stored Procedures, functions có thể được dùng trực tiếp trong câu SELECT, WHERE, và JOIN.

1. Loại Functions

Tổng quan

User-Defined Functions
├── Scalar Functions          → Trả về một giá trị đơn
├── Table-Valued Functions
│   ├── Inline TVF (iTVF)    → Một câu SELECT duy nhất
│   └── Multi-Statement TVF  → Nhiều câu lệnh, explicit table variable
└── CLR Aggregate Functions  → Tùy chỉnh aggregate (cần CLR)

Scalar Functions

-- Syntax cơ bản
CREATE FUNCTION dbo.CalculateAge
(
    @BirthDate DATE
)
RETURNS INT -- Trả về một giá trị đơn
AS
BEGIN
    DECLARE @Age INT;
    
    SET @Age = DATEDIFF(YEAR, @BirthDate, GETDATE())
        - CASE 
            WHEN MONTH(@BirthDate) > MONTH(GETDATE())
              OR (MONTH(@BirthDate) = MONTH(GETDATE()) AND DAY(@BirthDate) > DAY(GETDATE()))
            THEN 1 
            ELSE 0 
          END;
    
    RETURN @Age;
END;
GO

-- Sử dụng Scalar Function trong SELECT
SELECT 
    EmployeeId,
    FullName,
    BirthDate,
    dbo.CalculateAge(BirthDate) AS Age
FROM Employees;

-- Trong WHERE clause
SELECT * FROM Employees
WHERE dbo.CalculateAge(BirthDate) >= 30;

Inline Table-Valued Functions (iTVF)

-- Inline TVF: Chỉ một câu SELECT, không có BEGIN...END
CREATE FUNCTION dbo.GetOrdersByCustomer
(
    @CustomerId INT,
    @MinAmount  DECIMAL(18,2) = 0
)
RETURNS TABLE -- Không chỉ định cấu trúc table
AS
RETURN
(
    SELECT 
        o.OrderId,
        o.OrderDate,
        o.TotalAmount,
        o.Status,
        c.CustomerName
    FROM Orders o
    INNER JOIN Customers c ON o.CustomerId = c.CustomerId
    WHERE 
        o.CustomerId = @CustomerId
        AND o.TotalAmount >= @MinAmount
);
GO

-- Sử dụng iTVF: dùng như view có tham số
SELECT * FROM dbo.GetOrdersByCustomer(5, 100.00);

-- JOIN với iTVF (CROSS APPLY)
SELECT 
    c.CustomerId,
    c.CustomerName,
    o.OrderId,
    o.TotalAmount
FROM Customers c
CROSS APPLY dbo.GetOrdersByCustomer(c.CustomerId, 0) o
WHERE c.IsActive = 1;

-- OUTER APPLY: giữ lại customers không có orders
SELECT 
    c.CustomerId,
    c.CustomerName,
    o.OrderId,
    o.TotalAmount
FROM Customers c
OUTER APPLY dbo.GetOrdersByCustomer(c.CustomerId, 0) o;

Multi-Statement Table-Valued Functions (msTVF)

-- msTVF: Có BEGIN...END, định nghĩa rõ ràng cấu trúc return table
CREATE FUNCTION dbo.GetEmployeeHierarchy
(
    @ManagerId INT
)
RETURNS @Result TABLE -- Khai báo return table
(
    EmployeeId  INT,
    FullName    NVARCHAR(200),
    Level       INT,
    ManagerId   INT
)
AS
BEGIN
    -- Có thể có nhiều câu lệnh
    INSERT INTO @Result (EmployeeId, FullName, Level, ManagerId)
    VALUES (@ManagerId, (SELECT FullName FROM Employees WHERE EmployeeId = @ManagerId), 0, NULL);

    DECLARE @CurrentLevel INT = 0;

    WHILE EXISTS (
        SELECT 1 FROM Employees e
        INNER JOIN @Result r ON e.ManagerId = r.EmployeeId
        WHERE r.Level = @CurrentLevel
        AND e.EmployeeId NOT IN (SELECT EmployeeId FROM @Result)
    )
    BEGIN
        INSERT INTO @Result (EmployeeId, FullName, Level, ManagerId)
        SELECT 
            e.EmployeeId,
            e.FullName,
            @CurrentLevel + 1,
            e.ManagerId
        FROM Employees e
        INNER JOIN @Result r ON e.ManagerId = r.EmployeeId
        WHERE r.Level = @CurrentLevel
        AND e.EmployeeId NOT IN (SELECT EmployeeId FROM @Result);

        SET @CurrentLevel = @CurrentLevel + 1;
    END;

    RETURN; -- Không cần return value, data đã trong @Result
END;
GO

-- Sử dụng msTVF
SELECT EmployeeId, FullName, Level
FROM dbo.GetEmployeeHierarchy(1)
ORDER BY Level, FullName;

2. So Sánh iTVF vs msTVF: Performance

-- DEMO: So sánh execution plan

-- iTVF: Optimizer có thể thấy bên trong và optimize
CREATE FUNCTION dbo.GetActiveOrders_iTVF(@Status NVARCHAR(50))
RETURNS TABLE AS RETURN
(
    SELECT OrderId, CustomerId, TotalAmount
    FROM Orders
    WHERE Status = @Status
);

-- msTVF: Optimizer không nhìn thấy bên trong
CREATE FUNCTION dbo.GetActiveOrders_msTVF(@Status NVARCHAR(50))
RETURNS @T TABLE (OrderId INT, CustomerId INT, TotalAmount DECIMAL(18,2))
AS
BEGIN
    INSERT @T
    SELECT OrderId, CustomerId, TotalAmount
    FROM Orders
    WHERE Status = @Status;
    RETURN;
END;

-- Query với JOIN - iTVF sẽ tốt hơn vì optimizer có thể push predicate vào function
SELECT c.CustomerName, o.TotalAmount
FROM Customers c
CROSS APPLY dbo.GetActiveOrders_iTVF('Shipped') o  -- Better
WHERE c.CustomerId = o.CustomerId
  AND c.Region = 'North';

Kết luận: Luôn ưu tiên iTVF khi có thể.

3. Deterministic vs Non-Deterministic Functions

-- DETERMINISTIC: Cùng input → luôn cùng output
-- Ví dụ: UPPER(), LOWER(), LEN(), DATEADD(), SQRT()

-- NON-DETERMINISTIC: Cùng input có thể khác output
-- Ví dụ: GETDATE(), RAND(), NEWID(), GETUTCDATE()

-- Tại sao quan trọng?
-- 1. Indexed columns/computed columns chỉ chấp nhận deterministic functions
-- 2. Indexed views yêu cầu deterministic
-- 3. WITH SCHEMABINDING function được đánh dấu deterministic nếu eligible

-- UDF deterministic khi:
-- - Sử dụng WITH SCHEMABINDING
-- - Chỉ gọi deterministic built-in functions
-- - Không access database objects (bảng, views...)

CREATE FUNCTION dbo.FormatCurrency
(
    @Amount DECIMAL(18,2),
    @CurrencyCode CHAR(3)
)
RETURNS NVARCHAR(50)
WITH SCHEMABINDING -- Cần để mark deterministic
AS
BEGIN
    RETURN @CurrencyCode + ' ' + FORMAT(@Amount, 'N2');
END;
GO

-- Kiểm tra function có deterministic không
SELECT 
    name, 
    is_deterministic 
FROM sys.objects o
JOIN sys.sql_modules m ON o.object_id = m.object_id
WHERE o.type IN ('FN', 'TF', 'IF');

-- Dùng deterministic function trong computed column
ALTER TABLE Products
ADD FormattedPrice AS dbo.FormatCurrency(Price, 'USD') PERSISTED;
-- PERSISTED: lưu vật lý, cập nhật khi Price thay đổi

4. Function Restrictions (Những gì KHÔNG được làm)

-- Functions KHÔNG được phép:
-- 1. INSERT/UPDATE/DELETE trên real tables
-- 2. CREATE/DROP tables (ngoại trừ table variables)
-- 3. Gọi Stored Procedures
-- 4. TRY...CATCH (có thể dùng trong msTVF nhưng hạn chế)
-- 5. Dynamic SQL với EXEC() (sp_executesql với SELECT được phép trong một số trường hợp)
-- 6. Thay đổi state database (SET options, COMMIT/ROLLBACK cấp cao)

-- VI DỤ LỖI:
CREATE FUNCTION dbo.BadFunction(@Id INT)
RETURNS INT
AS
BEGIN
    -- LỖI: Không thể INSERT vào real table trong function
    INSERT INTO AuditLog (Action) VALUES ('Called'); -- ERROR!
    
    RETURN 1;
END;

-- GIẢI PHÁP: Dùng Stored Procedure thay vì Function khi cần side effects

5. Performance Caveat của Scalar UDFs

Vấn đề Row-by-Row Execution

-- Scalar UDF chạy row-by-row, KHÔNG thể parallelize (trước SQL 2019)
CREATE FUNCTION dbo.GetCustomerTier(@CustomerId INT)
RETURNS NVARCHAR(50)
AS
BEGIN
    DECLARE @TotalSpent DECIMAL(18,2);
    
    SELECT @TotalSpent = SUM(TotalAmount)
    FROM Orders
    WHERE CustomerId = @CustomerId;
    
    RETURN CASE 
        WHEN @TotalSpent >= 10000 THEN 'Platinum'
        WHEN @TotalSpent >= 5000  THEN 'Gold'
        WHEN @TotalSpent >= 1000  THEN 'Silver'
        ELSE 'Bronze'
    END;
END;
GO

-- Query này sẽ gọi function 1 TRIỆU lần nếu có 1 triệu customers!
-- Serial execution, rất chậm
SELECT 
    CustomerId,
    CustomerName,
    dbo.GetCustomerTier(CustomerId) AS Tier -- Row-by-row!
FROM Customers;

-- GIẢI PHÁP: Viết set-based thay thế
SELECT
    CustomerId,
    CustomerName,
    CASE 
        WHEN SUM(o.TotalAmount) >= 10000 THEN 'Platinum'
        WHEN SUM(o.TotalAmount) >= 5000  THEN 'Gold'
        WHEN SUM(o.TotalAmount) >= 1000  THEN 'Silver'
        ELSE 'Bronze'
    END AS Tier
FROM Customers c
LEFT JOIN Orders o ON c.CustomerId = o.CustomerId
GROUP BY c.CustomerId, c.CustomerName;

6. Scalar UDF Inlining trong SQL Server 2019+

-- SQL Server 2019 tự động inline eligible scalar UDFs
-- Biến scalar UDF thành relational expression, cho phép:
-- - Parallelism
-- - Cost-based optimization  
-- - Predicate pushdown

-- Điều kiện để được inline tự động:
-- ✅ Chỉ một RETURN statement
-- ✅ Không gọi EXECUTE
-- ✅ Không đệ quy
-- ✅ Không dùng TRY...CATCH
-- ✅ Không dùng table variables (ngoại trừ trong subquery)
-- ✅ Không có side effects
-- ❌ Không gọi RAND(), NEWID() (non-deterministic)

-- Kiểm tra function có được inline không
SELECT 
    o.name AS FunctionName,
    m.is_inlineable
FROM sys.sql_modules m
JOIN sys.objects o ON m.object_id = o.object_id
WHERE o.type = 'FN'; -- Scalar functions

-- Force inline cho một query cụ thể
SELECT 
    CustomerId,
    dbo.GetCustomerTier(CustomerId) AS Tier
FROM Customers
OPTION (USE HINT('ENABLE_TSQL_SCALAR_UDF_INLINING')); -- Force enable

-- Disable inline nếu gây vấn đề
SELECT 
    CustomerId,
    dbo.GetCustomerTier(CustomerId) WITH (INLINE = OFF) AS Tier -- SQL 2019+
FROM Customers;

-- Database level control
ALTER DATABASE MyDatabase
SET TSQL_SCALAR_UDF_INLINING = ON; -- Default ON trong compatibility 150+

7. Rewriting Scalar UDFs như iTVFs (Performance Pattern)

Đây là pattern quan trọng nhất để cải thiện hiệu năng function.

-- BEFORE: Scalar UDF - chậm, không parallel
CREATE FUNCTION dbo.GetProductDiscount_Scalar(@ProductId INT, @Quantity INT)
RETURNS DECIMAL(5,2)
AS
BEGIN
    DECLARE @Discount DECIMAL(5,2) = 0;
    DECLARE @Category NVARCHAR(50);
    
    SELECT @Category = CategoryName
    FROM Products p
    JOIN Categories c ON p.CategoryId = c.CategoryId
    WHERE p.ProductId = @ProductId;
    
    IF @Category = 'Electronics' AND @Quantity >= 10
        SET @Discount = 0.15;
    ELSE IF @Quantity >= 20
        SET @Discount = 0.10;
    ELSE IF @Quantity >= 5
        SET @Discount = 0.05;
    
    RETURN @Discount;
END;
GO

-- AFTER: Inline TVF - nhanh, optimizer can see inside
CREATE FUNCTION dbo.GetProductDiscount_iTVF(@ProductId INT, @Quantity INT)
RETURNS TABLE
AS
RETURN
(
    SELECT 
        CASE 
            WHEN c.CategoryName = 'Electronics' AND @Quantity >= 10 THEN 0.15
            WHEN @Quantity >= 20 THEN 0.10
            WHEN @Quantity >= 5  THEN 0.05
            ELSE 0.00
        END AS Discount
    FROM Products p
    JOIN Categories c ON p.CategoryId = c.CategoryId
    WHERE p.ProductId = @ProductId
);
GO

-- Sử dụng iTVF với CROSS APPLY
SELECT 
    od.OrderDetailId,
    od.ProductId,
    od.Quantity,
    d.Discount,
    od.UnitPrice * od.Quantity * (1 - d.Discount) AS FinalAmount
FROM OrderDetails od
CROSS APPLY dbo.GetProductDiscount_iTVF(od.ProductId, od.Quantity) d;

8. CLR Aggregate Functions

-- CLR Aggregate cần code C# và assembly registration
-- Ví dụ use case: Concatenate strings (như STRING_AGG trong SQL 2017+)

-- Sau khi deploy CLR assembly:
-- CREATE AGGREGATE dbo.StringConcat(@value NVARCHAR(MAX), @delimiter NVARCHAR(10))
-- RETURNS NVARCHAR(MAX)
-- EXTERNAL NAME MyAssembly.[MyNamespace.StringConcatAggregate];

-- Trong SQL Server 2017+, dùng STRING_AGG thay vì CLR:
SELECT 
    DepartmentId,
    STRING_AGG(FullName, ', ') WITHIN GROUP (ORDER BY FullName) AS EmployeeNames
FROM Employees
GROUP BY DepartmentId;

9. System Functions Overview

Metadata Functions

-- OBJECT_ID: Lấy object_id từ tên
SELECT OBJECT_ID('dbo.Orders');          -- Trả về INT hoặc NULL
SELECT OBJECT_ID('dbo.Orders', 'U');     -- 'U' = User table

-- OBJECT_NAME: Ngược lại OBJECT_ID
SELECT OBJECT_NAME(OBJECT_ID('dbo.Orders'));

-- SCHEMA_NAME: Lấy tên schema từ schema_id
SELECT SCHEMA_NAME(1); -- 'dbo'

-- Kiểm tra tồn tại trước khi create/drop
IF OBJECT_ID('dbo.MyFunction', 'FN') IS NOT NULL
    DROP FUNCTION dbo.MyFunction;
GO
CREATE FUNCTION dbo.MyFunction...

-- SQL 2016+: DROP IF EXISTS
DROP FUNCTION IF EXISTS dbo.MyFunction;

-- COLUMNPROPERTY: Thông tin về column
SELECT COLUMNPROPERTY(OBJECT_ID('Orders'), 'TotalAmount', 'Precision');

-- INDEX_COL: Tên column trong index
SELECT INDEX_COL('dbo.Orders', 1, 1); -- (table, index_id, key_ordinal)

Security Functions

-- USER_NAME(): Tên user hiện tại trong database
SELECT USER_NAME(); -- 'dbo', 'john', etc.

-- SYSTEM_USER: Login name
SELECT SYSTEM_USER; -- 'DOMAIN\john'

-- IS_MEMBER: Kiểm tra membership trong role
SELECT IS_MEMBER('db_datareader'); -- 1 = Yes, 0 = No, NULL = lỗi

-- IS_ROLEMEMBER: Tương tự nhưng rõ ràng hơn
SELECT IS_ROLEMEMBER('db_owner', 'john_user');

-- HAS_PERMS_BY_NAME: Kiểm tra quyền
SELECT HAS_PERMS_BY_NAME('dbo.Orders', 'OBJECT', 'SELECT'); -- 1 nếu có quyền

-- Trong Function để dynamic security
CREATE FUNCTION dbo.GetSensitiveData(@RequestUserId INT)
RETURNS TABLE
AS
RETURN
(
    SELECT *
    FROM SensitiveTable
    WHERE 
        IS_MEMBER('SensitiveDataViewers') = 1
        OR RequestedBy = @RequestUserId
);

10. Ví dụ So Sánh Toàn Diện

-- SCENARIO: Lấy discount percentage cho orderdetail

-- ❌ OPTION 1: Scalar UDF (tệ nhất)
CREATE FUNCTION dbo.GetDiscount_Scalar(@ProductId INT, @Quantity INT)
RETURNS DECIMAL(5,2)
AS
BEGIN
    DECLARE @Discount DECIMAL(5,2);
    SELECT TOP 1 @Discount = DiscountRate
    FROM DiscountRules
    WHERE ProductId = @ProductId AND MinQuantity <= @Quantity
    ORDER BY MinQuantity DESC;
    RETURN ISNULL(@Discount, 0);
END;

SELECT od.*, dbo.GetDiscount_Scalar(od.ProductId, od.Quantity) AS Disc
FROM OrderDetails od; -- N lần gọi function = N lần query DiscountRules

-- ✅ OPTION 2: Inline TVF (tốt)
CREATE FUNCTION dbo.GetDiscount_iTVF(@ProductId INT, @Quantity INT)
RETURNS TABLE AS RETURN
(
    SELECT TOP 1 DiscountRate AS Discount
    FROM DiscountRules
    WHERE ProductId = @ProductId AND MinQuantity <= @Quantity
    ORDER BY MinQuantity DESC
);

SELECT od.*, d.Discount
FROM OrderDetails od
CROSS APPLY dbo.GetDiscount_iTVF(od.ProductId, od.Quantity) d;
-- Optimizer có thể join và optimize toàn bộ query!

-- ✅ OPTION 3: Set-based JOIN (tốt nhất)
SELECT 
    od.*,
    ISNULL(dr.DiscountRate, 0) AS Discount
FROM OrderDetails od
OUTER APPLY (
    SELECT TOP 1 DiscountRate
    FROM DiscountRules dr
    WHERE dr.ProductId = od.ProductId AND dr.MinQuantity <= od.Quantity
    ORDER BY dr.MinQuantity DESC
) dr;

Checklist Khi Viết Functions

Triggers

Trigger là một loại stored procedure đặc biệt tự động thực thi (kích hoạt) khi xảy ra một sự kiện nhất định trên database. Trigger không được gọi trực tiếp - chúng phản ứng với các events.

Cảnh báo: Trigger là công cụ mạnh nhưng dễ lạm dụng. Luôn cân nhắc kỹ trước khi dùng.

1. Loại Triggers

SQL Server Triggers
├── DML Triggers (Data Manipulation Language)
│   ├── AFTER (FOR) Trigger
│   │   ├── AFTER INSERT
│   │   ├── AFTER UPDATE
│   │   └── AFTER DELETE
│   └── INSTEAD OF Trigger
│       ├── INSTEAD OF INSERT
│       ├── INSTEAD OF UPDATE
│       └── INSTEAD OF DELETE
├── DDL Triggers (Data Definition Language)
│   ├── Database-level (CREATE, ALTER, DROP objects)
│   └── Server-level (CREATE DATABASE, etc.)
└── Logon Triggers
    └── LOGON event

2. DML Triggers: inserted và deleted Tables

Khi DML trigger kích hoạt, SQL Server tạo hai bảng ảo (pseudo-tables):

• inserted: Chứa rows mới (sau INSERT hoặc sau UPDATE)
• deleted: Chứa rows cũ (trước DELETE hoặc trước UPDATE)

-- AFTER INSERT Trigger: Audit khi thêm đơn hàng
CREATE TRIGGER trg_Orders_AfterInsert
ON dbo.Orders
AFTER INSERT
AS
BEGIN
    SET NOCOUNT ON;

    INSERT INTO dbo.OrderAuditLog (
        OrderId, 
        CustomerId, 
        TotalAmount, 
        Action, 
        ActionBy, 
        ActionDate
    )
    SELECT 
        i.OrderId,
        i.CustomerId,
        i.TotalAmount,
        'INSERT',
        SYSTEM_USER,
        GETDATE()
    FROM inserted i; -- inserted có thể chứa NHIỀU rows!
END;
GO

-- AFTER DELETE Trigger: Soft delete / archive
CREATE TRIGGER trg_Products_AfterDelete
ON dbo.Products
AFTER DELETE
AS
BEGIN
    SET NOCOUNT ON;

    -- Lưu vào archive trước khi mất
    INSERT INTO dbo.ProductsArchive (
        ProductId, ProductName, Price, CategoryId, DeletedBy, DeletedDate
    )
    SELECT 
        d.ProductId,
        d.ProductName,
        d.Price,
        d.CategoryId,
        SYSTEM_USER,
        GETDATE()
    FROM deleted d;
END;
GO

-- AFTER UPDATE Trigger: Track thay đổi
CREATE TRIGGER trg_Employees_AfterUpdate
ON dbo.Employees
AFTER UPDATE
AS
BEGIN
    SET NOCOUNT ON;

    -- So sánh inserted (mới) và deleted (cũ)
    INSERT INTO dbo.EmployeeChangeLog (
        EmployeeId,
        ColumnChanged,
        OldValue,
        NewValue,
        ChangedBy,
        ChangedDate
    )
    SELECT
        i.EmployeeId,
        'Salary',
        CAST(d.Salary AS NVARCHAR(50)),
        CAST(i.Salary AS NVARCHAR(50)),
        SYSTEM_USER,
        GETDATE()
    FROM inserted i
    INNER JOIN deleted d ON i.EmployeeId = d.EmployeeId
    WHERE i.Salary <> d.Salary; -- Chỉ log khi Salary thực sự thay đổi
END;
GO

3. INSTEAD OF Triggers

INSTEAD OF trigger thay thế (intercept) DML gốc. DML gốc không chạy trừ khi trigger tự thực hiện nó.

INSTEAD OF trên View (Updatable Views)

-- View join nhiều bảng - mặc định không update được
CREATE VIEW dbo.vw_EmployeeDetails
AS
SELECT 
    e.EmployeeId,
    e.FirstName,
    e.LastName,
    e.Salary,
    d.DepartmentName,
    d.DepartmentId
FROM Employees e
INNER JOIN Departments d ON e.DepartmentId = d.DepartmentId;
GO

-- INSTEAD OF INSERT: Cho phép INSERT qua view
CREATE TRIGGER trg_vw_EmployeeDetails_InsteadOfInsert
ON dbo.vw_EmployeeDetails
INSTEAD OF INSERT
AS
BEGIN
    SET NOCOUNT ON;

    -- Validate
    IF EXISTS (SELECT 1 FROM inserted WHERE Salary < 0)
    BEGIN
        THROW 50001, 'Salary không được âm', 1;
    END;

    -- Thực hiện INSERT vào base table
    INSERT INTO dbo.Employees (FirstName, LastName, Salary, DepartmentId)
    SELECT i.FirstName, i.LastName, i.Salary, i.DepartmentId
    FROM inserted i;
END;
GO

-- INSTEAD OF UPDATE: Xử lý update phức tạp
CREATE TRIGGER trg_vw_EmployeeDetails_InsteadOfUpdate
ON dbo.vw_EmployeeDetails
INSTEAD OF UPDATE
AS
BEGIN
    SET NOCOUNT ON;

    -- Chỉ cho phép update các cột employee, không cho phép update department tên
    UPDATE e
    SET 
        e.FirstName = i.FirstName,
        e.LastName  = i.LastName,
        e.Salary    = i.Salary
    FROM Employees e
    INNER JOIN inserted i ON e.EmployeeId = i.EmployeeId;
    
    -- Nếu muốn update DepartmentId, xử lý riêng
    UPDATE e
    SET e.DepartmentId = i.DepartmentId
    FROM Employees e
    INNER JOIN inserted i ON e.EmployeeId = i.EmployeeId
    WHERE e.DepartmentId <> i.DepartmentId;
END;
GO

INSTEAD OF DELETE với Soft Delete

-- Thay vì xóa thật, mark IsDeleted = 1
CREATE TRIGGER trg_Orders_InsteadOfDelete
ON dbo.Orders
INSTEAD OF DELETE
AS
BEGIN
    SET NOCOUNT ON;

    UPDATE o
    SET 
        o.IsDeleted = 1,
        o.DeletedBy = SYSTEM_USER,
        o.DeletedDate = GETDATE()
    FROM dbo.Orders o
    INNER JOIN deleted d ON o.OrderId = d.OrderId;

    -- Không INSERT/DELETE thật → records không bị xóa
END;
GO

4. Trigger Context: @@ROWCOUNT, COLUMNS_UPDATED(), UPDATE()

CREATE TRIGGER trg_OrderDetails_Update
ON dbo.OrderDetails
AFTER UPDATE
AS
BEGIN
    SET NOCOUNT ON;

    -- @@ROWCOUNT: Số rows bị ảnh hưởng
    -- Nếu 0 rows thì không cần xử lý
    IF @@ROWCOUNT = 0 RETURN;

    -- UPDATE(column): TRUE nếu column được include trong UPDATE statement
    -- Lưu ý: TRUE cả khi giá trị không đổi!
    IF UPDATE(Quantity) OR UPDATE(UnitPrice)
    BEGIN
        -- Recalculate LineTotal
        UPDATE od
        SET od.LineTotal = od.Quantity * od.UnitPrice
        FROM dbo.OrderDetails od
        INNER JOIN inserted i ON od.OrderDetailId = i.OrderDetailId;
    END;

    -- COLUMNS_UPDATED(): Bitmask của columns được update
    -- ít dùng vì phụ thuộc vào ordinal position của column
    -- Column 1 = bit 1 (1), Column 2 = bit 2 (2), Column 3 = bit 3 (4)...
    -- COLUMNS_UPDATED() & 4 = 4 → Column 3 được update
    DECLARE @ChangedColumns VARBINARY(10) = COLUMNS_UPDATED();
    IF (@ChangedColumns & 2) = 2 -- Column 2 (Quantity)
    BEGIN
        INSERT INTO AuditLog (TableName, Event, ChangedAt)
        VALUES ('OrderDetails', 'Quantity Changed', GETDATE());
    END;
END;
GO

5. Nested và Recursive Triggers

-- NESTED TRIGGERS: Trigger A fires trigger B
-- Controlled bởi: sp_configure 'nested triggers', 1/0
-- Mặc định: ON (nested triggers enabled)

-- Ví dụ nested: 
-- UPDATE Orders → trg_Orders_Update → UPDATE OrderSummary → trg_OrderSummary_Update

-- Kiểm tra setting
SELECT name, value_in_use
FROM sys.configurations
WHERE name = 'nested triggers';

-- Disable nested triggers
EXEC sp_configure 'nested triggers', 0;
RECONFIGURE;

-- RECURSIVE TRIGGERS: Trigger gọi lại chính nó
-- Controlled bởi: ALTER DATABASE ... SET RECURSIVE_TRIGGERS ON/OFF
-- Mặc định: OFF

ALTER DATABASE MyDatabase SET RECURSIVE_TRIGGERS ON;

-- Ví dụ recursive trigger (CẦN THẬN - dễ gây infinite loop!)
CREATE TRIGGER trg_Categories_Update
ON dbo.Categories
AFTER UPDATE
AS
BEGIN
    SET NOCOUNT ON;
    
    -- Nếu không có guard condition → infinite loop!
    IF UPDATE(ParentCategoryId)
    BEGIN
        -- Update parent's child count
        UPDATE c
        SET c.ChildCount = (SELECT COUNT(*) FROM Categories WHERE ParentCategoryId = c.CategoryId)
        FROM Categories c
        WHERE c.CategoryId IN (SELECT ParentCategoryId FROM inserted WHERE ParentCategoryId IS NOT NULL);
        -- Điều này có thể trigger lại trigger này!
    END;
END;

6. Thứ Tự Trigger: sp_settriggerorder

-- Khi có nhiều AFTER trigger trên cùng một event, 
-- có thể chỉ định trigger nào chạy FIRST và LAST

-- Ví dụ: 3 triggers trên Orders AFTER INSERT
-- trg_Validate → trg_Audit → trg_Notify

EXEC sp_settriggerorder 
    @triggername = 'trg_Orders_Validate',
    @order = 'FIRST',
    @stmttype = 'INSERT';

EXEC sp_settriggerorder 
    @triggername = 'trg_Orders_Notify',
    @order = 'LAST',
    @stmttype = 'INSERT';

-- Triggers ở giữa không có guaranteed order

-- Xem trigger order
SELECT 
    t.name AS TriggerName,
    te.type_desc AS EventType,
    t.is_disabled
FROM sys.triggers t
JOIN sys.trigger_events te ON t.object_id = te.object_id
WHERE t.parent_id = OBJECT_ID('dbo.Orders')
ORDER BY t.name;

7. DDL Triggers: Audit Schema Changes

-- DATABASE-LEVEL DDL Trigger: Khi ai đó thay đổi schema
CREATE TRIGGER trg_DDL_AuditSchemaChanges
ON DATABASE
FOR CREATE_TABLE, ALTER_TABLE, DROP_TABLE,
    CREATE_PROCEDURE, ALTER_PROCEDURE, DROP_PROCEDURE,
    CREATE_VIEW, ALTER_VIEW, DROP_VIEW,
    CREATE_INDEX, DROP_INDEX
AS
BEGIN
    SET NOCOUNT ON;

    -- EVENTDATA(): Trả về XML mô tả sự kiện DDL
    DECLARE @EventData XML = EVENTDATA();

    INSERT INTO dbo.SchemaChangeLog (
        EventType,
        ObjectName,
        ObjectType,
        SchemaName,
        CommandText,
        LoginName,
        HostName,
        EventTime
    )
    SELECT
        @EventData.value('(/EVENT_INSTANCE/EventType)[1]',    'NVARCHAR(100)'),
        @EventData.value('(/EVENT_INSTANCE/ObjectName)[1]',   'NVARCHAR(200)'),
        @EventData.value('(/EVENT_INSTANCE/ObjectType)[1]',   'NVARCHAR(100)'),
        @EventData.value('(/EVENT_INSTANCE/SchemaName)[1]',   'NVARCHAR(100)'),
        @EventData.value('(/EVENT_INSTANCE/TSQLCommand)[1]',  'NVARCHAR(MAX)'),
        @EventData.value('(/EVENT_INSTANCE/LoginName)[1]',    'NVARCHAR(200)'),
        HOST_NAME(),
        GETDATE();
END;
GO

-- SERVER-LEVEL DDL Trigger: Audit database creation
CREATE TRIGGER trg_Server_PreventDropDatabase
ON ALL SERVER
FOR DROP_DATABASE
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @EventData XML = EVENTDATA();
    DECLARE @DbName NVARCHAR(200) = @EventData.value('(/EVENT_INSTANCE/DatabaseName)[1]', 'NVARCHAR(200)');

    -- Chặn xóa production databases
    IF @DbName LIKE 'PROD_%'
    BEGIN
        RAISERROR('Không được phép DROP production database!', 16, 1);
        ROLLBACK; -- Hủy lệnh DROP DATABASE
    END;
END;
GO

8. Performance Impact của Triggers

Tại sao Triggers ảnh hưởng Performance?

1. Synchronous: Trigger chạy trong cùng transaction với DML gốc
2. Blocking: DML phải chờ trigger hoàn thành mới commit
3. inserted/deleted tables: Phải tạo copy của data vào tempdb
4. Locks: Transaction dài hơn → lock lâu hơn → deadlock potential
5. Invisible overhead: Developer không thấy trigger khi viết DML

-- Đo hiệu năng trigger
SET STATISTICS TIME ON;
SET STATISTICS IO ON;

-- DML với trigger
UPDATE Orders SET Status = 'Shipped' WHERE OrderId = 1;
-- Xem output để thấy trigger time

-- Disable trigger để so sánh
DISABLE TRIGGER trg_Orders_AfterUpdate ON Orders;
UPDATE Orders SET Status = 'Shipped' WHERE OrderId = 1;
ENABLE TRIGGER trg_Orders_AfterUpdate ON Orders;

9. Trigger Anti-Patterns

Anti-Pattern 1: Giả sử Chỉ Có Một Row

-- ❌ SAI: Giả sử một row mỗi lần
CREATE TRIGGER trg_Bad_SingleRow ON Orders AFTER INSERT
AS
BEGIN
    -- GetDate với SCALAR - chỉ lấy một row!
    DECLARE @OrderId INT = (SELECT OrderId FROM inserted);
    DECLARE @CustomerId INT = (SELECT CustomerId FROM inserted);
    
    -- Nếu INSERT nhiều rows → lỗi hoặc lấy row tùy ý!
    
    EXEC dbo.SendOrderConfirmation @OrderId, @CustomerId;
END;

-- ✅ ĐÚNG: Xử lý multi-row
CREATE TRIGGER trg_Good_MultiRow ON Orders AFTER INSERT
AS
BEGIN
    SET NOCOUNT ON;
    
    -- Xử lý tất cả rows trong inserted
    INSERT INTO NotificationQueue (OrderId, CustomerId, QueuedAt)
    SELECT OrderId, CustomerId, GETDATE()
    FROM inserted;
    -- SP để xử lý từng notification sẽ được gọi bởi job riêng
END;

Anti-Pattern 2: CURSOR trong Trigger

-- ❌ SAI: Cursor trong trigger = rất chậm
CREATE TRIGGER trg_Bad_CursorInTrigger ON Orders AFTER INSERT
AS
BEGIN
    DECLARE @OrderId INT;
    DECLARE cur CURSOR FOR SELECT OrderId FROM inserted;
    OPEN cur;
    FETCH NEXT FROM cur INTO @OrderId;
    WHILE @@FETCH_STATUS = 0
    BEGIN
        EXEC dbo.ProcessOrder @OrderId; -- Gọi SP cho từng row
        FETCH NEXT FROM cur INTO @OrderId;
    END;
    CLOSE cur;
    DEALLOCATE cur;
END;

-- ✅ TỐT HƠN: Batch vào queue, xử lý async
CREATE TRIGGER trg_Good_BatchQueue ON Orders AFTER INSERT
AS
BEGIN
    SET NOCOUNT ON;
    INSERT INTO ProcessingQueue (OrderId, QueuedAt, Status)
    SELECT OrderId, GETDATE(), 'Pending'
    FROM inserted;
    -- Background job sẽ xử lý queue
END;

Anti-Pattern 3: Business Logic Phức Tạp trong Trigger

-- ❌ TRÁNH: Quá nhiều logic trong trigger
-- → Khó debug, khó test, khó maintain
-- → Developer INSERT vào Orders không biết trigger làm gì

-- ✅ THAY BẰNG: Application logic hoặc Stored Procedure rõ ràng

10. Alternatives to Triggers

Computed Columns (thay vì trigger calculate)

-- Thay vì trigger tính LineTotal
-- ❌ Trigger approach
CREATE TRIGGER trg_CalcLineTotal ON OrderDetails AFTER INSERT, UPDATE
AS UPDATE od SET od.LineTotal = od.Quantity * od.UnitPrice
FROM OrderDetails od INNER JOIN inserted i ON od.OrderDetailId = i.OrderDetailId;

-- ✅ Computed Column approach (tự động, không cần trigger)
ALTER TABLE OrderDetails
ADD LineTotal AS (Quantity * UnitPrice) PERSISTED;

Filtered Indexes (thay vì trigger validate)

-- Thay vì trigger ngăn duplicate active orders
-- ✅ Unique filtered index
CREATE UNIQUE INDEX UIX_ActiveOrders_Customer
ON Orders (CustomerId)
WHERE Status = 'Active'; -- Chỉ enforce unique khi Active

CDC (Change Data Capture) thay vì Audit Trigger

-- Enable CDC cho bảng Orders
EXEC sys.sp_cdc_enable_db; -- Enable cho database

EXEC sys.sp_cdc_enable_table
    @source_schema = 'dbo',
    @source_name   = 'Orders',
    @role_name     = NULL, -- Security role
    @capture_instance = 'dbo_Orders',
    @supports_net_changes = 1;

-- Query changes (không cần trigger!)
SELECT 
    __$operation, -- 1=DELETE, 2=INSERT, 3=before UPDATE, 4=after UPDATE
    __$start_lsn,
    OrderId,
    TotalAmount,
    Status
FROM cdc.fn_cdc_get_all_changes_dbo_Orders(
    @from_lsn, @to_lsn, 'all'
);

11. DISABLE / ENABLE TRIGGER

-- Disable một trigger cụ thể
DISABLE TRIGGER trg_Orders_AfterInsert ON dbo.Orders;

-- Enable lại
ENABLE TRIGGER trg_Orders_AfterInsert ON dbo.Orders;

-- Disable TẤT CẢ triggers trên một table
DISABLE TRIGGER ALL ON dbo.Orders;
ENABLE TRIGGER ALL ON dbo.Orders;

-- Disable TẤT CẢ DDL triggers trên database
DISABLE TRIGGER ALL ON DATABASE;
ENABLE TRIGGER ALL ON DATABASE;

-- Use case: Import dữ liệu lớn mà không muốn trigger chạy
DISABLE TRIGGER ALL ON dbo.Orders;
-- BulkInsert...
ENABLE TRIGGER ALL ON dbo.Orders;

-- Kiểm tra trigger nào đang enabled/disabled
SELECT 
    t.name,
    t.is_disabled,
    te.type_desc AS EventType,
    OBJECT_NAME(t.parent_id) AS TableName
FROM sys.triggers t
JOIN sys.trigger_events te ON t.object_id = te.object_id
WHERE t.parent_id = OBJECT_ID('dbo.Orders');

12. Logon Triggers

-- Logon Trigger: Kiểm soát ai được phép login
CREATE TRIGGER trg_LimitConnections
ON ALL SERVER
WITH EXECUTE AS 'sa'
FOR LOGON
AS
BEGIN
    -- Giới hạn số connections của một login
    IF ORIGINAL_LOGIN() = 'ReportUser'
    BEGIN
        IF (
            SELECT COUNT(*) 
            FROM sys.dm_exec_sessions 
            WHERE login_name = 'ReportUser'
        ) > 5
        BEGIN
            RAISERROR('Quá nhiều connections cho ReportUser', 16, 1);
            ROLLBACK; -- Từ chối connection
        END;
    END;

    -- Block connections ngoài giờ làm việc
    IF ORIGINAL_LOGIN() NOT IN ('sa', 'AdminUser')
    BEGIN
        IF DATEPART(HOUR, GETDATE()) < 8 OR DATEPART(HOUR, GETDATE()) > 18
        BEGIN
            RAISERROR('Chỉ được kết nối trong giờ làm việc (8:00-18:00)', 16, 1);
            ROLLBACK;
        END;
    END;
END;
GO

-- CẢNH BÁO: Logon trigger lỗi có thể chặn TẤT CẢ connections, kể cả sa!
-- Nếu bị lock out, phải dùng Dedicated Admin Connection (DAC):
-- sqlcmd -S server -A (hoặc Admin: prefix trong SSMS)
-- DISABLE TRIGGER trg_LimitConnections ON ALL SERVER;

Tóm Tắt: Khi Nào Dùng Trigger?

Golden Rule: Trigger là công cụ cuối cùng. Nếu có thể giải quyết bằng constraints, computed columns, application logic, hoặc CDC - hãy dùng chúng thay thế.

Views, CTEs & Window Functions

Phần này bao gồm các kỹ thuật truy vấn nâng cao trong SQL Server: Views (bao gồm Indexed Views), CTEs (Common Table Expressions), Window Functions, và Cursors.

PHẦN 1: Views

1.1 Tạo và Quản Lý Views

-- Tạo view cơ bản
CREATE VIEW dbo.vw_ActiveOrders
AS
SELECT 
    o.OrderId,
    o.OrderDate,
    o.TotalAmount,
    o.Status,
    c.CustomerName,
    c.Email,
    c.Region
FROM dbo.Orders o
INNER JOIN dbo.Customers c ON o.CustomerId = c.CustomerId
WHERE o.IsDeleted = 0;
GO

-- Sửa view (giữ nguyên permissions)
ALTER VIEW dbo.vw_ActiveOrders
AS
SELECT 
    o.OrderId,
    o.OrderDate,
    o.TotalAmount,
    o.Status,
    c.CustomerName,
    c.Email,
    c.Region,
    o.ShippedDate -- Thêm cột mới
FROM dbo.Orders o
INNER JOIN dbo.Customers c ON o.CustomerId = c.CustomerId
WHERE o.IsDeleted = 0 AND o.Status <> 'Cancelled';
GO

-- Xóa view
DROP VIEW IF EXISTS dbo.vw_ActiveOrders;

-- Xem định nghĩa view
SELECT OBJECT_DEFINITION(OBJECT_ID('dbo.vw_ActiveOrders'));
-- hoặc
EXEC sp_helptext 'dbo.vw_ActiveOrders';

1.2 WITH SCHEMABINDING

-- SCHEMABINDING: Ngăn thay đổi base objects
-- BẮT BUỘC cho Indexed Views
-- Yêu cầu: Phải dùng tên đầy đủ (schema.table)

CREATE VIEW dbo.vw_ProductPriceList
WITH SCHEMABINDING -- Khóa schema
AS
SELECT 
    p.ProductId,
    p.ProductName,
    p.Price,
    c.CategoryName
FROM dbo.Products p           -- Phải có dbo.
INNER JOIN dbo.Categories c ON p.CategoryId = c.CategoryId
WHERE p.IsActive = 1;
GO

-- Thử DROP column của base table → LỖI
-- ALTER TABLE dbo.Products DROP COLUMN Price;
-- ERROR: Cannot DROP COLUMN 'Price' because it is referenced by view 'vw_ProductPriceList'

-- Kiểm tra view có SCHEMABINDING không
SELECT 
    v.name,
    v.with_check_option,
    m.is_schema_bound
FROM sys.views v
JOIN sys.sql_modules m ON v.object_id = m.object_id
WHERE v.name = 'vw_ProductPriceList';

1.3 WITH CHECK OPTION

-- CHECK OPTION: Đảm bảo INSERT/UPDATE qua view phải thỏa WHERE của view
CREATE VIEW dbo.vw_ActiveProducts
AS
SELECT ProductId, ProductName, Price, IsActive
FROM dbo.Products
WHERE IsActive = 1
WITH CHECK OPTION; -- Ngăn INSERT/UPDATE tạo ra rows không visible trong view

-- INSERT thỏa điều kiện → OK
INSERT INTO dbo.vw_ActiveProducts (ProductName, Price, IsActive)
VALUES ('New Product', 99.99, 1);

-- INSERT vi phạm điều kiện → ERROR
INSERT INTO dbo.vw_ActiveProducts (ProductName, Price, IsActive)
VALUES ('Inactive Product', 99.99, 0);
-- ERROR: The attempted insert or update failed because the target view
-- either specifies WITH CHECK OPTION or spans a view that specifies WITH CHECK OPTION

1.4 Updatable Views

View có thể UPDATE/INSERT/DELETE nếu thỏa:

-- View đơn giản → updatable
CREATE VIEW dbo.vw_EmployeeNames AS
SELECT EmployeeId, FirstName, LastName FROM Employees;

-- UPDATE trực tiếp qua view
UPDATE dbo.vw_EmployeeNames 
SET LastName = 'Nguyen' 
WHERE EmployeeId = 1;
-- Tương đương: UPDATE Employees SET LastName = 'Nguyen' WHERE EmployeeId = 1

-- View join nhiều bảng → KHÔNG updatable trực tiếp
-- Dùng INSTEAD OF trigger (xem phần Triggers)

1.5 Indexed Views (Materialized Views)

Indexed View lưu kết quả vật lý trên disk, tự động cập nhật khi base tables thay đổi.

-- Bước 1: Tạo view với SCHEMABINDING (bắt buộc)
CREATE VIEW dbo.vw_DailySalesSummary
WITH SCHEMABINDING
AS
SELECT 
    CAST(o.OrderDate AS DATE) AS SaleDate,
    p.CategoryId,
    COUNT_BIG(*) AS OrderCount,      -- Phải dùng COUNT_BIG(*), không phải COUNT(*)
    SUM(od.Quantity * od.UnitPrice) AS TotalRevenue,
    SUM(CAST(od.Quantity AS BIGINT)) AS TotalQuantity
FROM dbo.Orders o
INNER JOIN dbo.OrderDetails od ON o.OrderId = od.OrderId
INNER JOIN dbo.Products p ON od.ProductId = p.ProductId
WHERE o.IsDeleted = 0
GROUP BY CAST(o.OrderDate AS DATE), p.CategoryId;
GO

-- Bước 2: Tạo UNIQUE CLUSTERED INDEX → materialize view
CREATE UNIQUE CLUSTERED INDEX UCIX_vw_DailySalesSummary
ON dbo.vw_DailySalesSummary (SaleDate, CategoryId);
GO

-- Bước 3 (Optional): Thêm non-clustered indexes
CREATE INDEX IX_vw_DailySalesSummary_Revenue
ON dbo.vw_DailySalesSummary (TotalRevenue DESC);

-- Optimizer tự động dùng indexed view khi profitable
-- (với ENTERPRISE edition, STANDARD cần NOEXPAND hint)

-- Force dùng indexed view (STANDARD edition)
SELECT SaleDate, CategoryId, TotalRevenue
FROM dbo.vw_DailySalesSummary WITH (NOEXPAND)
WHERE SaleDate = '2025-01-01';

Yêu cầu cho Indexed View:

1.6 sys.views và INFORMATION_SCHEMA.VIEWS

-- Liệt kê tất cả views
SELECT 
    v.name AS ViewName,
    s.name AS SchemaName,
    v.create_date,
    v.modify_date,
    m.is_schema_bound,
    m.uses_ansi_nulls
FROM sys.views v
JOIN sys.schemas s ON v.schema_id = s.schema_id
JOIN sys.sql_modules m ON v.object_id = m.object_id
ORDER BY s.name, v.name;

-- INFORMATION_SCHEMA.VIEWS: Portable across SQL products
SELECT 
    TABLE_SCHEMA,
    TABLE_NAME,
    VIEW_DEFINITION
FROM INFORMATION_SCHEMA.VIEWS
WHERE TABLE_NAME LIKE 'vw_%';

-- Tìm views phụ thuộc vào một bảng
SELECT DISTINCT 
    v.name AS ViewName
FROM sys.views v
JOIN sys.sql_expression_dependencies d ON v.object_id = d.referencing_id
JOIN sys.objects o ON d.referenced_id = o.object_id
WHERE o.name = 'Orders';

PHẦN 2: CTEs (Common Table Expressions)

2.1 Cú Pháp Cơ Bản

-- CTE cơ bản
WITH OrderSummary AS (
    SELECT 
        CustomerId,
        COUNT(*) AS TotalOrders,
        SUM(TotalAmount) AS TotalSpent
    FROM Orders
    WHERE Status = 'Completed'
    GROUP BY CustomerId
)
SELECT 
    c.CustomerName,
    c.Email,
    os.TotalOrders,
    os.TotalSpent
FROM Customers c
INNER JOIN OrderSummary os ON c.CustomerId = os.CustomerId
WHERE os.TotalSpent > 1000
ORDER BY os.TotalSpent DESC;

2.2 Multiple CTEs trong Một Query

WITH
-- CTE 1: High-value customers
HighValueCustomers AS (
    SELECT CustomerId, SUM(TotalAmount) AS TotalSpent
    FROM Orders
    GROUP BY CustomerId
    HAVING SUM(TotalAmount) >= 5000
),
-- CTE 2: Recent orders (dùng bảng gốc)
RecentOrders AS (
    SELECT CustomerId, COUNT(*) AS OrdersLast30Days
    FROM Orders
    WHERE OrderDate >= DATEADD(DAY, -30, GETDATE())
    GROUP BY CustomerId
),
-- CTE 3: Combine (có thể reference các CTEs trước)
CustomerInsights AS (
    SELECT 
        hvc.CustomerId,
        hvc.TotalSpent,
        ISNULL(ro.OrdersLast30Days, 0) AS RecentOrders
    FROM HighValueCustomers hvc
    LEFT JOIN RecentOrders ro ON hvc.CustomerId = ro.CustomerId
)
-- Final query sử dụng CTE cuối cùng
SELECT 
    c.CustomerName,
    ci.TotalSpent,
    ci.RecentOrders,
    CASE 
        WHEN ci.RecentOrders >= 3 THEN 'Very Active'
        WHEN ci.RecentOrders >= 1 THEN 'Active'
        ELSE 'Inactive'
    END AS ActivityStatus
FROM Customers c
INNER JOIN CustomerInsights ci ON c.CustomerId = ci.CustomerId
ORDER BY ci.TotalSpent DESC;

2.3 Recursive CTEs

-- CẤU TRÚC:
-- Anchor Member UNION ALL Recursive Member

-- EXAMPLE 1: Traversal hierarchy nhân viên
WITH EmployeeTree AS (
    -- ANCHOR: CEO (không có manager)
    SELECT 
        EmployeeId,
        FullName,
        ManagerId,
        JobTitle,
        0 AS Level,
        CAST(FullName AS NVARCHAR(MAX)) AS HierarchyPath,
        CAST(EmployeeId AS NVARCHAR(MAX)) AS IdPath
    FROM Employees
    WHERE ManagerId IS NULL

    UNION ALL

    -- RECURSIVE: Direct reports của các employees đã có
    SELECT 
        e.EmployeeId,
        e.FullName,
        e.ManagerId,
        e.JobTitle,
        et.Level + 1 AS Level,
        et.HierarchyPath + ' > ' + e.FullName,
        et.IdPath + '.' + CAST(e.EmployeeId AS NVARCHAR(10))
    FROM Employees e
    INNER JOIN EmployeeTree et ON e.ManagerId = et.EmployeeId
)
SELECT 
    REPLICATE('  ', Level) + FullName AS OrgChart,
    JobTitle,
    Level,
    HierarchyPath
FROM EmployeeTree
ORDER BY IdPath;
-- OPTION (MAXRECURSION 100); -- Giới hạn depth (default là 100, 0 = unlimited)

-- EXAMPLE 2: Đếm ngày làm việc (trừ cuối tuần)
WITH DateSeries AS (
    -- Anchor: ngày bắt đầu
    SELECT CAST('2025-01-01' AS DATE) AS WorkDate

    UNION ALL

    -- Recursive: thêm từng ngày
    SELECT DATEADD(DAY, 1, WorkDate)
    FROM DateSeries
    WHERE WorkDate < '2025-12-31'
)
SELECT COUNT(*) AS WorkingDays
FROM DateSeries
WHERE DATENAME(WEEKDAY, WorkDate) NOT IN ('Saturday', 'Sunday')
OPTION (MAXRECURSION 366);

-- EXAMPLE 3: Tìm routes giữa các nodes (graph traversal)
WITH RouteSearch AS (
    SELECT 
        FromCity, ToCity, 
        Distance AS TotalDistance,
        CAST(FromCity + ' → ' + ToCity AS NVARCHAR(MAX)) AS Route,
        1 AS Hops
    FROM Routes
    WHERE FromCity = 'Hanoi'

    UNION ALL

    SELECT 
        rs.FromCity, r.ToCity,
        rs.TotalDistance + r.Distance,
        rs.Route + ' → ' + r.ToCity,
        rs.Hops + 1
    FROM RouteSearch rs
    INNER JOIN Routes r ON rs.ToCity = r.FromCity
    WHERE rs.Hops < 5 -- Giới hạn số bước
    AND rs.Route NOT LIKE '%' + r.ToCity + '%' -- Tránh cycle
)
SELECT Route, TotalDistance
FROM RouteSearch
WHERE ToCity = 'HCMC'
ORDER BY TotalDistance;

2.4 CTE cho DELETE và UPDATE

-- DELETE với CTE (xóa duplicates)
WITH DuplicateOrders AS (
    SELECT 
        OrderId,
        ROW_NUMBER() OVER (
            PARTITION BY CustomerId, OrderDate, TotalAmount
            ORDER BY OrderId
        ) AS RowNum
    FROM Orders
)
DELETE FROM DuplicateOrders WHERE RowNum > 1;
-- Thực tế: DELETE ảnh hưởng đến bảng Orders gốc

-- UPDATE với CTE (cập nhật với ranking)
WITH RankedSalary AS (
    SELECT 
        EmployeeId,
        Salary,
        DENSE_RANK() OVER (PARTITION BY DepartmentId ORDER BY Salary DESC) AS SalaryRank
    FROM Employees
)
UPDATE RankedSalary
SET Salary = Salary * 1.10 -- Tăng 10% cho top earner
WHERE SalaryRank = 1;

2.5 CTE vs Subquery vs Temp Table

PHẦN 3: Window Functions

3.1 Cú Pháp OVER()

function_name(args) OVER (
    [PARTITION BY partition_expression]
    [ORDER BY sort_expression [ASC|DESC]]
    [ROWS|RANGE BETWEEN frame_start AND frame_end]
)

-- Frame options:
-- UNBOUNDED PRECEDING: Từ đầu partition
-- CURRENT ROW: Row hiện tại
-- UNBOUNDED FOLLOWING: Đến cuối partition
-- N PRECEDING: N rows trước
-- N FOLLOWING: N rows sau

3.2 Ranking Functions

SELECT 
    EmployeeId,
    FullName,
    Department,
    Salary,
    
    -- ROW_NUMBER: Sequential, không ties
    ROW_NUMBER() OVER (PARTITION BY Department ORDER BY Salary DESC) AS RowNum,
    
    -- RANK: Ties có cùng rank, skip sau
    RANK() OVER (PARTITION BY Department ORDER BY Salary DESC) AS Rnk,
    
    -- DENSE_RANK: Ties có cùng rank, không skip
    DENSE_RANK() OVER (PARTITION BY Department ORDER BY Salary DESC) AS DenseRnk,
    
    -- NTILE: Chia thành N buckets đều nhau
    NTILE(4) OVER (PARTITION BY Department ORDER BY Salary DESC) AS Quartile
FROM Employees
ORDER BY Department, Salary DESC;

/*
Kết quả ví dụ (cùng Department, Salary: 10000, 8000, 8000, 6000):
FullName  Salary  RowNum  Rnk  DenseRnk  Quartile
Alice     10000   1       1    1         1
Bob       8000    2       2    2         2
Carol     8000    3       2    2         2
David     6000    4       4    3         3
*/

3.3 Offset Functions

SELECT
    OrderDate,
    Revenue,
    
    -- LAG: Giá trị từ row TRƯỚC đó
    LAG(Revenue, 1, 0) OVER (ORDER BY OrderDate) AS PrevRevenue,
    LAG(Revenue, 2, 0) OVER (ORDER BY OrderDate) AS TwoPeriodsAgo,
    
    -- LEAD: Giá trị từ row SAU đó
    LEAD(Revenue, 1, 0) OVER (ORDER BY OrderDate) AS NextRevenue,
    
    -- FIRST_VALUE: Giá trị đầu tiên trong partition/window
    FIRST_VALUE(Revenue) OVER (PARTITION BY YEAR(OrderDate) ORDER BY OrderDate
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS FirstRevenueOfYear,
    
    -- LAST_VALUE: Giá trị cuối cùng (cần explicit frame!)
    LAST_VALUE(Revenue) OVER (PARTITION BY YEAR(OrderDate) ORDER BY OrderDate
        ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING) AS LastRevenueOfYear,
    
    -- Month-over-Month Growth %
    CASE 
        WHEN LAG(Revenue) OVER (ORDER BY OrderDate) = 0 THEN NULL
        ELSE ROUND(
            (Revenue - LAG(Revenue) OVER (ORDER BY OrderDate)) * 100.0 
            / LAG(Revenue) OVER (ORDER BY OrderDate), 
            2)
    END AS MoMGrowthPct

FROM MonthlySales
ORDER BY OrderDate;

3.4 Aggregate Window Functions

-- RUNNING TOTAL (Cumulative Sum)
SELECT
    OrderDate,
    OrderAmount,
    
    -- Running total toàn bộ
    SUM(OrderAmount) OVER (
        ORDER BY OrderDate
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS RunningTotal,
    
    -- Running total theo năm (PARTITION BY)
    SUM(OrderAmount) OVER (
        PARTITION BY YEAR(OrderDate)
        ORDER BY OrderDate
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS YearlyRunningTotal,
    
    -- Moving Average: trung bình 7 ngày gần nhất
    AVG(OrderAmount) OVER (
        ORDER BY OrderDate
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) AS MovingAvg7Day,
    
    -- Running Count
    COUNT(*) OVER (
        PARTITION BY CustomerId
        ORDER BY OrderDate
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ) AS CustomerOrderNumber,

    -- Percent of total
    ROUND(
        OrderAmount * 100.0 / SUM(OrderAmount) OVER (),
        2
    ) AS PctOfTotal,
    
    -- Percent of year total
    ROUND(
        OrderAmount * 100.0 / SUM(OrderAmount) OVER (PARTITION BY YEAR(OrderDate)),
        2
    ) AS PctOfYearTotal

FROM Orders
ORDER BY OrderDate;

3.5 Ví Dụ Thực Tế

Pagination với ROW_NUMBER()

DECLARE @Page INT = 2;
DECLARE @PageSize INT = 10;

WITH PagedOrders AS (
    SELECT 
        OrderId,
        OrderDate,
        TotalAmount,
        CustomerName,
        ROW_NUMBER() OVER (ORDER BY OrderDate DESC, OrderId DESC) AS RowNum
    FROM Orders o
    JOIN Customers c ON o.CustomerId = c.CustomerId
    WHERE o.IsDeleted = 0
)
SELECT OrderId, OrderDate, TotalAmount, CustomerName
FROM PagedOrders
WHERE RowNum BETWEEN (@Page - 1) * @PageSize + 1 AND @Page * @PageSize;

-- Modern approach: OFFSET/FETCH (SQL 2012+)
SELECT OrderId, OrderDate, TotalAmount
FROM Orders
ORDER BY OrderDate DESC, OrderId DESC
OFFSET (@Page - 1) * @PageSize ROWS
FETCH NEXT @PageSize ROWS ONLY;

Tìm và Xóa Duplicates

-- Xem duplicates
WITH DuplicateDetection AS (
    SELECT 
        *,
        ROW_NUMBER() OVER (
            PARTITION BY Email, FirstName, LastName -- Cột xác định duplicate
            ORDER BY CustomerId ASC -- Keep: record có ID nhỏ nhất
        ) AS RowNum,
        COUNT(*) OVER (PARTITION BY Email, FirstName, LastName) AS DupeCount
    FROM Customers
)
SELECT * FROM DuplicateDetection WHERE DupeCount > 1;

-- Xóa duplicates (giữ record đầu tiên)
WITH DuplicateDetection AS (
    SELECT 
        CustomerId,
        ROW_NUMBER() OVER (
            PARTITION BY Email, FirstName, LastName
            ORDER BY CustomerId ASC
        ) AS RowNum
    FROM Customers
)
DELETE FROM DuplicateDetection WHERE RowNum > 1;

Running Total với ROWS vs RANGE

-- ROWS: Tính theo vị trí vật lý (accurate)
SELECT 
    SaleDate, Amount,
    SUM(Amount) OVER (ORDER BY SaleDate ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS RunningTotal_ROWS
FROM Sales;

-- RANGE: Tính theo giá trị, bao gồm cả ties (có thể không chính xác với duplicates)
SELECT 
    SaleDate, Amount,
    SUM(Amount) OVER (ORDER BY SaleDate RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS RunningTotal_RANGE
FROM Sales;

-- Khi có 2 rows cùng SaleDate:
-- ROWS: Row 1 là subtotal đến row 1, Row 2 là subtotal đến row 2
-- RANGE: Cả hai rows đều hiển thị cùng tổng (tổng đến cuối ngày đó)
-- ROWS nhanh hơn và thường là điều bạn muốn

Gaps and Islands

-- Tìm các dải ngày liên tiếp user login (Islands)
WITH LoginDates AS (
    SELECT DISTINCT UserId, CAST(LoginDateTime AS DATE) AS LoginDate
    FROM UserLogins
),
Ranked AS (
    SELECT 
        UserId, LoginDate,
        ROW_NUMBER() OVER (PARTITION BY UserId ORDER BY LoginDate) AS RowNum
    FROM LoginDates
),
Islands AS (
    SELECT
        UserId,
        LoginDate,
        DATEADD(DAY, -RowNum, LoginDate) AS IslandKey -- Ngày - RowNum = hằng số khi liên tiếp
    FROM Ranked
)
SELECT
    UserId,
    MIN(LoginDate) AS StreakStart,
    MAX(LoginDate) AS StreakEnd,
    COUNT(*) AS ConsecutiveDays,
    DATEDIFF(DAY, MIN(LoginDate), MAX(LoginDate)) + 1 AS TotalDays
FROM Islands
GROUP BY UserId, IslandKey
HAVING COUNT(*) >= 3 -- Chỉ những streak >= 3 ngày
ORDER BY UserId, StreakStart;

-- Tìm Gaps (khoảng trống)
WITH AllDates AS (
    SELECT 
        UserId, LoginDate,
        LEAD(LoginDate) OVER (PARTITION BY UserId ORDER BY LoginDate) AS NextLogin
    FROM (
        SELECT DISTINCT UserId, CAST(LoginDateTime AS DATE) AS LoginDate
        FROM UserLogins
    ) d
)
SELECT 
    UserId, 
    LoginDate AS GapStart,
    NextLogin AS GapEnd,
    DATEDIFF(DAY, LoginDate, NextLogin) - 1 AS GapDays
FROM AllDates
WHERE DATEDIFF(DAY, LoginDate, NextLogin) > 1; -- Gap lớn hơn 1 ngày

PHẦN 4: Cursors

4.1 Cú Pháp Cursor

-- Cú pháp đầy đủ
DECLARE cursor_name CURSOR
    [LOCAL | GLOBAL]
    [FORWARD_ONLY | SCROLL]
    [STATIC | KEYSET | DYNAMIC | FAST_FORWARD]
    [READ_ONLY | SCROLL_LOCKS | OPTIMISTIC]
FOR
    select_statement
[FOR UPDATE [OF column_name [,...n]]];

OPEN cursor_name;

FETCH [NEXT | PRIOR | FIRST | LAST | ABSOLUTE n | RELATIVE n] 
FROM cursor_name INTO @var1 [, @var2 ...];

WHILE @@FETCH_STATUS = 0
BEGIN
    -- Process...
    FETCH NEXT FROM cursor_name INTO @var1;
END;

CLOSE cursor_name;
DEALLOCATE cursor_name;

4.2 Cursor Types

-- FAST_FORWARD: Nhanh nhất, chỉ read-only, forward
DECLARE @OrderId INT;
DECLARE @Amount DECIMAL(18,2);

DECLARE cur_Orders CURSOR FAST_FORWARD FOR
    SELECT OrderId, TotalAmount
    FROM Orders
    WHERE Status = 'Pending'
    ORDER BY OrderId;

OPEN cur_Orders;
FETCH NEXT FROM cur_Orders INTO @OrderId, @Amount;

WHILE @@FETCH_STATUS = 0
BEGIN
    -- Gọi SP cho từng order (lý do duy nhất dùng cursor)
    EXEC dbo.ProcessPendingOrder @OrderId, @Amount;
    
    FETCH NEXT FROM cur_Orders INTO @OrderId, @Amount;
END;

CLOSE cur_Orders;
DEALLOCATE cur_Orders;

4.3 Tại Sao Tránh Cursors

-- BENCHMARK: Cursor vs Set-based

-- Cursor approach: O(n) round trips
DECLARE @Id INT;
DECLARE cur CURSOR FOR SELECT ProductId FROM Products;
OPEN cur;
FETCH NEXT FROM cur INTO @Id;
WHILE @@FETCH_STATUS = 0
BEGIN
    UPDATE Products SET Stock = Stock - 1 WHERE ProductId = @Id; -- 1 update mỗi lần
    FETCH NEXT FROM cur INTO @Id;
END;
CLOSE cur; DEALLOCATE cur;
-- Với 100,000 products: 100,000 update statements, 100,000 lock acquisitions

-- Set-based approach: O(1) - một câu lệnh
UPDATE Products SET Stock = Stock - 1; -- 1 update cho tất cả
-- Với 100,000 products: 1 operation, optimized I/O, parallel execution

4.4 Alternatives to Cursors

-- THAY CURSOR BẰNG:

-- 1. Set-based operations
-- Cursor: update từng row
-- Better: UPDATE Table SET col = expr WHERE condition

-- 2. Window Functions
-- Cursor: dùng biến để track previous row
-- Better: LAG(), ROW_NUMBER(), SUM() OVER()

-- 3. Recursive CTE
-- Cursor: duyệt hierarchy từng node
-- Better: Recursive CTE

-- 4. APPLY (cho SP/function per row)
-- Cursor: EXEC SP cho từng row
-- Nếu SP có thể convert thành TVF, dùng CROSS APPLY

-- 5. Batch processing (nếu phải xử lý từng batch)
DECLARE @BatchSize INT = 1000;
DECLARE @LastId INT = 0;

WHILE 1 = 1
BEGIN
    UPDATE TOP (@BatchSize) p
    SET p.ProcessedFlag = 1
    OUTPUT inserted.ProductId
    FROM Products p
    WHERE p.ProcessedFlag = 0 AND p.ProductId > @LastId
    ORDER BY p.ProductId;

    IF @@ROWCOUNT = 0 BREAK;
    
    SET @LastId = @LastId + @BatchSize;
    WAITFOR DELAY '00:00:01'; -- Giảm tải
END;

-- 6. STRING_AGG thay vì cursor concatenate strings
-- Cursor approach: dùng biến + concatenation
-- Better:
SELECT 
    DepartmentId,
    STRING_AGG(FullName, ', ') WITHIN GROUP (ORDER BY FullName) AS EmployeeList
FROM Employees
GROUP BY DepartmentId;

Tóm Tắt So Sánh

Khi nào dùng gì?

Performance Quick Reference

-- Checking view dependencies
SELECT 
    referencing_entity_name,
    referenced_entity_name
FROM sys.dm_sql_referencing_entities('dbo.Orders', 'OBJECT');

-- Find expensive window function queries
SELECT TOP 10
    qs.total_elapsed_time / qs.execution_count AS avg_elapsed_time,
    qs.execution_count,
    SUBSTRING(qt.text, 1, 200) AS query_snippet
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
WHERE qt.text LIKE '%OVER%'
ORDER BY avg_elapsed_time DESC;

Transactions & Concurrency - Tổng quan

Phần này bao gồm các kiến thức về Giao dịch (Transactions) và Kiểm soát đồng thời (Concurrency Control) trong SQL Server — hai chủ đề cốt lõi trong phát triển ứng dụng enterprise và phỏng vấn kỹ thuật.

Các chủ đề con

Q&A Phỏng vấn

🟢 Junior Level

Q1: ACID là gì? Giải thích từng thuộc tính.

A:

• Atomicity (Tính nguyên tử): Tất cả các thao tác trong transaction phải thành công toàn bộ hoặc không có thao tác nào được thực hiện. Nếu một bước thất bại, toàn bộ transaction sẽ bị ROLLBACK.
• Consistency (Tính nhất quán): Transaction phải đưa database từ trạng thái hợp lệ này sang trạng thái hợp lệ khác. Các ràng buộc (constraints), triggers, cascade phải được đảm bảo.
• Isolation (Tính cô lập): Các transaction đang chạy đồng thời không được nhìn thấy dữ liệu lẫn nhau ở trạng thái trung gian. Mức độ cô lập được điều chỉnh qua Isolation Levels.
• Durability (Tính bền vững): Sau khi transaction COMMIT, dữ liệu phải được lưu trữ vĩnh viễn kể cả khi hệ thống bị sập. SQL Server đảm bảo điều này qua Write-Ahead Logging (WAL).

Q2: Cú pháp cơ bản của Transaction trong SQL Server là gì?

A:

BEGIN TRANSACTION;
    UPDATE Accounts SET Balance = Balance - 100 WHERE AccountId = 1;
    UPDATE Accounts SET Balance = Balance + 100 WHERE AccountId = 2;
COMMIT TRANSACTION;

-- Hoặc khi có lỗi:
BEGIN TRANSACTION;
    UPDATE Accounts SET Balance = Balance - 100 WHERE AccountId = 1;
    -- Phát hiện lỗi...
ROLLBACK TRANSACTION;

Q3: Sự khác biệt giữa COMMIT và ROLLBACK là gì?

A:

• COMMIT: Xác nhận tất cả thay đổi trong transaction, ghi vĩnh viễn vào database.
• ROLLBACK: Hủy bỏ tất cả thay đổi trong transaction, đưa dữ liệu về trạng thái trước khi bắt đầu transaction.

Q4: Isolation Level mặc định của SQL Server là gì?

A: READ COMMITTED — ngăn chặn Dirty Read nhưng vẫn cho phép Non-repeatable Read và Phantom Read. Đây là mức cân bằng tốt giữa tính nhất quán và hiệu suất.

Q5: Dirty Read là gì? Cho ví dụ.

A: Dirty Read xảy ra khi một transaction đọc dữ liệu mà transaction khác đang sửa đổi nhưng chưa COMMIT. Nếu transaction kia sau đó ROLLBACK, dữ liệu đã đọc là không hợp lệ.

-- Session 1: Cập nhật nhưng chưa commit
BEGIN TRANSACTION;
UPDATE Products SET Price = 999 WHERE ProductId = 1;
-- Chưa COMMIT

-- Session 2 (READ UNCOMMITTED): Đọc được giá 999 - là Dirty Read
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT Price FROM Products WHERE ProductId = 1; -- Trả về 999

-- Session 1: Rollback
ROLLBACK; -- Giá thực tế vẫn là giá cũ

Q6: Blocking trong SQL Server là gì?

A: Blocking xảy ra khi một transaction đang giữ lock trên resource, khiến transaction khác phải chờ. Ví dụ: Session A đang UPDATE mà chưa COMMIT, Session B muốn SELECT cùng row đó sẽ bị block.

Q7: Làm thế nào để xem các blocking session hiện tại?

A:

-- Cách nhanh nhất
EXEC sp_who2;

-- Chi tiết hơn
SELECT 
    r.session_id,
    r.blocking_session_id,
    r.wait_type,
    r.wait_time,
    r.status,
    t.text AS QueryText
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.blocking_session_id > 0;

Q8: Deadlock là gì?

A: Deadlock xảy ra khi hai hoặc nhiều transaction đều đang chờ nhau giải phóng lock theo dạng vòng tròn (circular dependency). SQL Server tự động phát hiện deadlock, chọn một transaction làm deadlock victim và ROLLBACK nó, giải phóng deadlock.

Q9: NOLOCK hint là gì và có rủi ro gì không?

A: WITH (NOLOCK) tương đương với READ UNCOMMITTED — cho phép đọc dữ liệu chưa commit. Rủi ro nghiêm trọng:

• Đọc được dữ liệu sẽ bị ROLLBACK (Dirty Read)
• Có thể bỏ sót rows (skip rows)
• Có thể đọc trùng rows (duplicate rows)
• Không nên dùng trong hệ thống tài chính, báo cáo cần chính xác.

Q10: @@TRANCOUNT là gì?

A: @@TRANCOUNT trả về số lượng transaction đang mở trong session hiện tại. Mỗi BEGIN TRANSACTION tăng giá trị lên 1, mỗi COMMIT giảm 1, chỉ ROLLBACK mới đặt về 0.

🟡 Mid Level

Q11: Phantom Read là gì? Isolation level nào ngăn chặn nó?

A: Phantom Read xảy ra khi một transaction thực hiện cùng một query hai lần nhưng nhận được kết quả khác nhau vì transaction khác đã INSERT/DELETE rows phù hợp với điều kiện query giữa hai lần đọc.

Chỉ SERIALIZABLE isolation level mới ngăn chặn Phantom Read hoàn toàn (dùng key-range locks). SNAPSHOT ISOLATION cũng ngăn phantom read nhờ row versioning.

Q12: READ COMMITTED SNAPSHOT ISOLATION (RCSI) khác READ COMMITTED như thế nào?

A:

RCSI cho writers và readers không block nhau — tốt hơn cho concurrency cao. Bật bằng: ALTER DATABASE MyDB SET READ_COMMITTED_SNAPSHOT ON.

Q13: Giải thích Lock Escalation và khi nào nó xảy ra.

A: SQL Server bắt đầu với row-level locks. Khi số locks trong một statement vượt ngưỡng (~5000 locks), SQL Server escalate (nâng cấp) thành table lock để tiết kiệm bộ nhớ. Điều này giảm overhead quản lý lock nhưng giảm concurrency vì table bị lock toàn bộ.

Để hạn chế lock escalation:

-- Tắt lock escalation cho table cụ thể
ALTER TABLE dbo.BigTable SET (LOCK_ESCALATION = DISABLE);

-- Dùng ROWLOCK hint trong query
SELECT * FROM BigTable WITH (ROWLOCK) WHERE Id = 1;

Q14: TRY-CATCH với Transaction hoạt động như thế nào?

A:

BEGIN TRANSACTION;
BEGIN TRY
    UPDATE Accounts SET Balance = Balance - 500 WHERE AccountId = 1;
    UPDATE Accounts SET Balance = Balance + 500 WHERE AccountId = 2;
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;
    -- Re-throw error
    THROW;
END CATCH;

Lưu ý: Luôn kiểm tra @@TRANCOUNT > 0 trước khi ROLLBACK để tránh lỗi khi transaction đã bị rollback do XACT_ABORT.

Q15: XACT_ABORT là gì và khi nào nên dùng?

A: SET XACT_ABORT ON khiến SQL Server tự động ROLLBACK toàn bộ transaction khi có bất kỳ lỗi runtime nào xảy ra (thay vì chỉ fail statement đó). Đây là best practice trong stored procedures.

SET XACT_ABORT ON;
BEGIN TRANSACTION;
    -- Nếu bất kỳ statement nào fail, toàn bộ transaction sẽ rollback tự động
    INSERT INTO Orders ...;
    INSERT INTO OrderDetails ...;
COMMIT TRANSACTION;

Q16: Savepoints là gì và dùng khi nào?

A: Savepoints cho phép ROLLBACK một phần của transaction về đến điểm lưu, không phải toàn bộ transaction.

BEGIN TRANSACTION;
    INSERT INTO Log VALUES ('Step 1');
    SAVE TRANSACTION step1; -- Đặt savepoint

    INSERT INTO Orders VALUES (...);
    -- Nếu có lỗi, rollback về step1, không phải về đầu transaction
    ROLLBACK TRANSACTION step1;

    INSERT INTO Log VALUES ('Step 1 still committed');
COMMIT TRANSACTION;

Q17: Làm thế nào để phát hiện và xử lý Deadlock?

A:

Phát hiện:

-- Bật trace flag để log deadlock vào SQL Server Error Log
DBCC TRACEON(1222, -1); -- Detailed deadlock info
DBCC TRACEON(1204, -1); -- Basic deadlock info

-- Hoặc dùng Extended Events (recommended)
-- Event: xml_deadlock_report

Xử lý:

-- Retry pattern trong application
-- Trong SQL: Bắt error 1205 (Deadlock victim)
BEGIN TRY
    -- Transaction code
END TRY
BEGIN CATCH
    IF ERROR_NUMBER() = 1205 -- Deadlock victim
    BEGIN
        PRINT 'Deadlock detected, retry...';
        -- Application logic để retry
    END
    ELSE THROW;
END CATCH;

Q18: Sự khác biệt giữa Shared Lock (S) và Exclusive Lock (X)?

A:

• Shared Lock (S): Dùng cho READ. Nhiều shared locks có thể tồn tại cùng lúc trên cùng resource. Không cho phép Exclusive lock.
• Exclusive Lock (X): Dùng cho WRITE (INSERT, UPDATE, DELETE). Chỉ một exclusive lock được phép tại một thời điểm. Không compatible với bất kỳ lock nào khác.

Q19: Update Lock (U Lock) là gì? Tại sao cần thiết?

A: Update Lock (U) là bước trung gian khi SQL Server chuẩn bị UPDATE:

1. Đầu tiên acquire U lock để đọc row (scan)
2. Sau đó convert sang X lock khi thực sự ghi

Lý do cần thiết: Ngăn chặn deadlock trong trường hợp hai session cùng đọc rồi cùng update. Nếu dùng S lock rồi convert X lock, hai session có thể deadlock. U lock chỉ tương thích với S lock (không phải U), nên chỉ một session có thể giữ U lock tại một thời điểm.

Q20: Non-repeatable Read là gì? Khác Phantom Read như thế nào?

A:

• Non-repeatable Read: Cùng một row được đọc hai lần trong transaction cho kết quả khác nhau (row bị UPDATE/DELETE bởi transaction khác giữa hai lần đọc).
• Phantom Read: Cùng một query (với WHERE condition) trả về số lượng rows khác nhau (rows mới bị INSERT bởi transaction khác).

🔴 Senior Level

Q21: Giải thích Write-Ahead Logging (WAL) và vai trò của nó trong Durability.

A: WAL là nguyên tắc cốt lõi đảm bảo Durability:

1. Trước khi ghi data page vào disk, SQL Server phải ghi log record tương ứng vào Transaction Log trước.
2. Khi COMMIT, SQL Server chỉ cần đảm bảo log records được flush to disk (không cần data pages).
3. Nếu hệ thống crash, SQL Server dùng transaction log để REDO (áp lại các committed transactions) và UNDO (rollback các uncommitted transactions) trong quá trình recovery.

Checkpoint process: SQL Server định kỳ thực hiện checkpoint để flush dirty data pages từ buffer pool xuống disk, giảm thời gian recovery.

Q22: Tại sao Long-running Transactions lại nguy hiểm?

A:

1. Transaction Log không thể reuse: Log không thể truncate nếu transaction vẫn đang mở, gây log file phình to.
2. Blocking: Giữ locks lâu dài, blocking các session khác.
3. Version Store bloat (nếu dùng RCSI/SI): Row versions phải giữ trong tempdb cho đến khi transaction kết thúc.
4. Rollback time: Transaction chạy 2 giờ có thể mất 2 giờ để rollback.

Giải pháp: Chia nhỏ batch, dùng WAITFOR DELAY ‘00:00:00’ để nhường CPU, monitor với sys.dm_exec_requests.

Q23: Distributed Transaction và MSDTC hoạt động như thế nào?

A: Distributed Transaction span qua nhiều resource managers (nhiều SQL Server instances, hoặc SQL Server + Message Queue). Microsoft Distributed Transaction Coordinator (MSDTC) điều phối 2-Phase Commit:

1. Phase 1 - Prepare: MSDTC yêu cầu tất cả participants chuẩn bị commit và báo cáo trạng thái.
2. Phase 2 - Commit/Rollback: Nếu tất cả sẵn sàng, MSDTC ra lệnh commit. Nếu bất kỳ participant nào fail, toàn bộ rollback.

-- Linked server distributed transaction
BEGIN DISTRIBUTED TRANSACTION;
    UPDATE LocalDB.dbo.Table1 SET Col = 1;
    UPDATE [RemoteServer].RemoteDB.dbo.Table2 SET Col = 2;
COMMIT;

Nhược điểm: Latency cao, MSDTC là single point of failure. Modern architecture thường dùng Saga pattern thay thế.

Q24: Giải thích SNAPSHOT ISOLATION và sự khác biệt với RCSI.

A:

SNAPSHOT ISOLATION hay phát hiện update conflicts: Nếu row đã bị modify bởi transaction khác kể từ khi snapshot được tạo, transaction hiện tại sẽ fail với lỗi.

Q25: Làm thế nào để tune performance khi có nhiều Blocking?

A:

1. Tìm blocking chain:

SELECT 
    blocking.session_id AS blocker_session,
    blocked.session_id AS blocked_session,
    blocked.wait_time / 1000 AS wait_seconds,
    blocked.wait_type,
    SUBSTRING(sqltext.text, (blocked.statement_start_offset/2)+1, 
        ((CASE blocked.statement_end_offset WHEN -1 THEN DATALENGTH(sqltext.text)
          ELSE blocked.statement_end_offset END - blocked.statement_start_offset)/2)+1) AS blocked_query
FROM sys.dm_exec_requests blocked
INNER JOIN sys.dm_exec_sessions blocking 
    ON blocked.blocking_session_id = blocking.session_id
CROSS APPLY sys.dm_exec_sql_text(blocked.sql_handle) sqltext
WHERE blocked.blocking_session_id > 0;

2. Giải pháp:
   • Bật RCSI để readers không block writers
   • Tối ưu index để giảm thời gian lock
   • Rút ngắn transaction
   • Đúng isolation level cho use case
   • SET LOCK_TIMEOUT để fail fast thay vì chờ mãi

Q26: Chiến lược ngăn chặn Deadlock là gì?

A:

1. Access objects theo cùng thứ tự: Nếu T1 và T2 đều lock Table A rồi Table B theo cùng thứ tự, deadlock không xảy ra.
2. Giữ transaction ngắn: Giảm thời gian giữ locks.
3. Thêm đúng indexes: Giảm số rows phải lock, tránh table scans.
4. Dùng UPDLOCK hint: Lấy U lock từ đầu thay vì S -> X conversion.
5. Dùng RCSI/SNAPSHOT: Readers không lấy S locks, loại bỏ Read-Write deadlocks.
6. Retry logic: Viết application code bắt error 1205 và retry.

Q27: Giải thích Version Store trong tempdb và vấn đề tiềm ẩn.

A: Khi RCSI hoặc SNAPSHOT ISOLATION được bật, mỗi khi row được UPDATE, SQL Server ghi phiên bản cũ của row vào Version Store trong tempdb. Long-running transactions giữ versions này cho đến khi kết thúc, khiến tempdb phình to.

Monitor Version Store:

SELECT 
    SUM(version_store_reserved_page_count) * 8 / 1024 AS version_store_MB
FROM sys.dm_db_file_space_usage;

-- Xem oldest active transaction
SELECT 
    transaction_id,
    transaction_begin_time,
    DATEDIFF(MINUTE, transaction_begin_time, GETDATE()) AS minutes_open
FROM sys.dm_tran_active_snapshot_database_transactions
ORDER BY transaction_begin_time;

Giải pháp: Kết thúc long-running transactions, monitor tempdb growth, ensure tempdb autogrowth được cấu hình đúng.

Q28: Tại sao nên dùng sp_executesql thay vì EXEC với dynamic SQL trong context bảo mật transaction?

A:

-- BAD: Dễ bị SQL Injection
DECLARE @sql NVARCHAR(500) = 'SELECT * FROM Users WHERE Name = ''' + @input + '''';
EXEC(@sql);

-- GOOD: Parameterized, safe against SQL Injection
DECLARE @sql NVARCHAR(500) = 'SELECT * FROM Users WHERE Name = @name';
EXEC sp_executesql @sql, N'@name NVARCHAR(100)', @name = @input;

sp_executesql cũng giúp plan caching tốt hơn và an toàn trong nested transactions vì không tạo scope mới cho @@TRANCOUNT.

Q29: Giải thích cơ chế chọn Deadlock Victim.

A: SQL Server dùng thuật toán để chọn transaction nào sẽ bị kill (deadlock victim) dựa trên:

1. DEADLOCK_PRIORITY: Transaction có priority thấp hơn bị chọn trước.

SET DEADLOCK_PRIORITY LOW; -- Tự nguyện làm victim
SET DEADLOCK_PRIORITY HIGH; -- Ít có khả năng làm victim
SET DEADLOCK_PRIORITY NORMAL; -- Default

2. Transaction cost: Nếu priority bằng nhau, transaction nào tốn ít cost hơn để rollback (log records ít hơn) sẽ bị chọn.

3. DEADLOCK_PRIORITY nhận giá trị từ -10 (LOWEST) đến 10 (HIGHEST).

Q30: Thiết kế retry mechanism cho Deadlock ở application level như thế nào?

A:

// C# example với Polly hoặc custom retry
public async Task ExecuteWithDeadlockRetry(Func<Task> action, int maxRetries = 3)
{
    int attempt = 0;
    while (true)
    {
        try
        {
            await action();
            return;
        }
        catch (SqlException ex) when (ex.Number == 1205) // Deadlock victim
        {
            attempt++;
            if (attempt >= maxRetries) throw;
            
            // Exponential backoff với jitter
            int delay = (int)(Math.Pow(2, attempt) * 100 + Random.Shared.Next(0, 100));
            await Task.Delay(delay);
        }
    }
}

Nguyên tắc: Retry deadlock là hợp lệ vì deadlock là transient error. Nhưng không retry lỗi business logic hay constraint violation.

Giao dịch (Transactions)

Transaction (Giao dịch) là đơn vị công việc logic gồm một hoặc nhiều thao tác được thực thi như một khối hoàn chỉnh — hoặc tất cả thành công, hoặc không có gì được thực hiện. Đây là nền tảng của tính toàn vẹn dữ liệu trong SQL Server.

1. ACID Properties

ACID là bốn thuộc tính cơ bản mà mọi transaction phải đảm bảo:

Atomicity (Tính nguyên tử)

“All or nothing” — Tất cả thao tác trong transaction thực hiện thành công toàn bộ, hoặc nếu bất kỳ thao tác nào thất bại, toàn bộ transaction bị ROLLBACK về trạng thái ban đầu.

Ví dụ thực tế: Chuyển tiền ngân hàng — trừ tiền tài khoản A và cộng tiền tài khoản B phải là một đơn vị. Không thể trừ mà không cộng.

BEGIN TRANSACTION;
    UPDATE BankAccounts SET Balance = Balance - 1000000 WHERE AccountId = 1;
    UPDATE BankAccounts SET Balance = Balance + 1000000 WHERE AccountId = 2;
    -- Nếu dòng trên fail, toàn bộ rollback
COMMIT TRANSACTION;

Consistency (Tính nhất quán)

Transaction phải đưa database từ trạng thái hợp lệ (valid state) này sang trạng thái hợp lệ khác. Tất cả constraints (PRIMARY KEY, FOREIGN KEY, CHECK, UNIQUE), triggers, và business rules phải được thỏa mãn sau khi transaction hoàn thành.

Ví dụ: Tổng số dư của tất cả tài khoản ngân hàng trước và sau khi chuyển tiền phải bằng nhau.

Isolation (Tính cô lập)

Các transaction đang thực thi đồng thời phải độc lập với nhau — transaction này không được nhìn thấy kết quả trung gian (chưa commit) của transaction khác. Mức độ cô lập được điều chỉnh qua Isolation Levels.

Durability (Tính bền vững)

Sau khi transaction được COMMIT, dữ liệu phải được lưu trữ vĩnh viễn kể cả khi hệ thống crash, mất điện. SQL Server đảm bảo điều này thông qua Write-Ahead Logging (WAL).

2. Transaction Syntax

BEGIN TRANSACTION

-- Tường minh
BEGIN TRANSACTION;
-- Hoặc viết tắt
BEGIN TRAN;

-- Đặt tên transaction (hỗ trợ nested transaction với savepoints)
BEGIN TRANSACTION TransferMoney;

COMMIT TRANSACTION

COMMIT TRANSACTION;
-- Hoặc
COMMIT TRAN;
-- Hoặc chỉ
COMMIT;

ROLLBACK TRANSACTION

ROLLBACK TRANSACTION;
-- Hoặc
ROLLBACK TRAN;
-- Hoặc
ROLLBACK;

Ví dụ hoàn chỉnh

BEGIN TRANSACTION;
BEGIN TRY
    INSERT INTO Orders (CustomerId, OrderDate, TotalAmount)
    VALUES (101, GETDATE(), 500000);

    DECLARE @OrderId INT = SCOPE_IDENTITY();

    INSERT INTO OrderDetails (OrderId, ProductId, Quantity, UnitPrice)
    VALUES (@OrderId, 5, 2, 250000);

    COMMIT TRANSACTION;
    PRINT 'Order created successfully';
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;
    PRINT 'Error: ' + ERROR_MESSAGE();
    THROW; -- Re-throw để caller biết
END CATCH;

3. @@TRANCOUNT — Đếm Transaction lồng nhau

@@TRANCOUNT trả về số lượng transaction đang mở trong session hiện tại:

• BEGIN TRANSACTION → @@TRANCOUNT + 1
• COMMIT → @@TRANCOUNT - 1 (chỉ commit khi về 0)
• ROLLBACK → @@TRANCOUNT = 0 (rollback toàn bộ, bất kể nested level)

PRINT @@TRANCOUNT; -- 0

BEGIN TRANSACTION; -- @@TRANCOUNT = 1
    BEGIN TRANSACTION; -- @@TRANCOUNT = 2
        UPDATE Products SET Price = 100 WHERE ProductId = 1;
    COMMIT; -- @@TRANCOUNT = 1 (chưa thực sự commit!)
COMMIT; -- @@TRANCOUNT = 0, NOW actually committed

-- Nguy hiểm: ROLLBACK ở bất kỳ level nào cũng rollback toàn bộ
BEGIN TRANSACTION; -- @@TRANCOUNT = 1
    BEGIN TRANSACTION; -- @@TRANCOUNT = 2
        BEGIN TRANSACTION; -- @@TRANCOUNT = 3
        ROLLBACK; -- @@TRANCOUNT = 0, TOÀN BỘ bị rollback!

Lưu ý quan trọng: Trong stored procedures, nên kiểm tra @@TRANCOUNT để tránh rollback nhầm outer transaction:

CREATE PROCEDURE dbo.SafeInsert
AS
BEGIN
    DECLARE @TranCount INT = @@TRANCOUNT;
    
    IF @TranCount = 0
        BEGIN TRANSACTION; -- Chỉ mở nếu chưa có transaction
    ELSE
        SAVE TRANSACTION SavePoint1; -- Dùng savepoint nếu đã trong transaction
    
    BEGIN TRY
        -- Business logic
        INSERT INTO ...
        
        IF @TranCount = 0
            COMMIT TRANSACTION;
    END TRY
    BEGIN CATCH
        IF @TranCount = 0
            ROLLBACK TRANSACTION;
        ELSE
            ROLLBACK TRANSACTION SavePoint1;
        THROW;
    END CATCH;
END;

4. Savepoints

Savepoints cho phép đặt “điểm lưu” bên trong transaction để có thể rollback về điểm đó mà không rollback toàn bộ transaction.

BEGIN TRANSACTION;
    INSERT INTO AuditLog VALUES ('Process started', GETDATE());
    
    SAVE TRANSACTION BeforeOrder; -- Đặt savepoint
    
    BEGIN TRY
        INSERT INTO Orders (CustomerId) VALUES (999); -- 999 có thể không tồn tại
        SAVE TRANSACTION AfterOrder;
        
        INSERT INTO OrderDetails (OrderId, ProductId) VALUES (SCOPE_IDENTITY(), 1);
    END TRY
    BEGIN CATCH
        IF ERROR_NUMBER() = 547 -- Foreign key violation
        BEGIN
            ROLLBACK TRANSACTION BeforeOrder; -- Chỉ rollback đến savepoint
            -- AuditLog INSERT vẫn còn!
            INSERT INTO AuditLog VALUES ('Order failed: FK violation', GETDATE());
        END
        ELSE
            THROW;
    END CATCH;
    
    INSERT INTO AuditLog VALUES ('Process completed', GETDATE());
COMMIT TRANSACTION; -- Commit tất cả những gì còn lại

Giới hạn của Savepoints:

• ROLLBACK TO SAVEPOINT không giảm @@TRANCOUNT
• Không thể dùng savepoint để commit một phần — chỉ có thể rollback về điểm đó
• Không hỗ trợ trong Distributed Transactions

5. Implicit vs Explicit Transactions

Explicit Transactions (Mặc định)

Mọi statement là auto-commit trừ khi bạn tường minh BEGIN TRANSACTION.

-- Auto-commit mode (mặc định):
INSERT INTO Table1 VALUES (1); -- Commit ngay lập tức
UPDATE Table2 SET Col = 1 WHERE Id = 1; -- Commit ngay lập tức

-- Explicit:
BEGIN TRANSACTION;
    INSERT INTO Table1 VALUES (1);
    UPDATE Table2 SET Col = 1 WHERE Id = 1;
COMMIT; -- Cả hai commit cùng lúc

Implicit Transactions

Khi SET IMPLICIT_TRANSACTIONS ON, SQL Server tự động mở transaction trước các DML/DDL statements. Bạn phải tường minh COMMIT hoặc ROLLBACK.

SET IMPLICIT_TRANSACTIONS ON;

INSERT INTO Products VALUES ('Widget', 100); -- SQL tự BEGIN TRAN
SELECT * FROM Products; -- Vẫn trong transaction
COMMIT; -- Bạn phải commit tường minh

-- Tiếp tục, SQL tự mở transaction mới
UPDATE Products SET Price = 200 WHERE ProductId = 1;
ROLLBACK; -- Rollback update

Cảnh báo: IMPLICIT_TRANSACTIONS ON thường gây ra vấn đề — DBA hay developer quên COMMIT gây ra long-running transactions. Không nên dùng trong ứng dụng production.

6. Auto-commit Mode

SQL Server mặc định chạy ở auto-commit mode: mỗi statement là một transaction riêng biệt, tự động commit khi thành công hoặc rollback khi thất bại.

-- Không có BEGIN TRAN:
INSERT INTO T1 VALUES (1); -- Tự động commit
UPDATE T2 SET C = 1; -- Tự động commit (riêng biệt)
DELETE FROM T3 WHERE Id = 5; -- Tự động commit (riêng biệt)

-- Nếu UPDATE fail vì constraint, chỉ UPDATE bị rollback, INSERT vẫn commit

7. Transaction Log & Write-Ahead Logging (WAL)

Transaction Log

SQL Server dùng Transaction Log (.ldf file) để ghi lại tất cả thay đổi dữ liệu trước khi áp dụng lên data pages.

Cấu trúc:

• Log file chia thành Virtual Log Files (VLFs)
• Mỗi VLF chứa nhiều Log Records
• Log records được ghi tuần tự (sequential I/O — nhanh hơn random I/O)

Write-Ahead Logging (WAL)

Quy tắc WAL: Log record phải được ghi vào disk trước khi data page tương ứng được ghi xuống disk.

Luồng hoạt động:

1. Transaction bắt đầu → SQL Server tạo log record "BEGIN TRAN"
2. UPDATE row → Ghi log record (Before Image + After Image) vào Log Buffer
3. COMMIT → SQL Server flush Log Buffer xuống disk (log flush)
4. COMMIT hoàn thành → User nhận được kết quả
5. (Nền) Checkpoint → Data pages được ghi xuống disk

Checkpoint

Checkpoint là quá trình ghi tất cả dirty pages (pages đã modify trong memory nhưng chưa ghi xuống disk) xuống disk:

-- Manual checkpoint
CHECKPOINT;

-- Xem thời gian recovery estimate
SELECT recovery_model_desc, log_reuse_wait_desc
FROM sys.databases WHERE name = DB_NAME();

Recovery sau crash:

1. REDO (Roll forward): Áp lại tất cả log records của committed transactions sau checkpoint
2. UNDO (Roll back): Hủy tất cả log records của uncommitted transactions

8. Long-running Transactions — Tác hại và Xử lý

Tác hại

1. Transaction Log không thể truncate (reuse)
   → Log file phình to, hết disk space
   
2. Giữ locks trong thời gian dài
   → Blocking nhiều session khác
   
3. Version Store bloat (nếu dùng RCSI/Snapshot)
   → tempdb phình to
   
4. Rollback time = Run time
   → Transaction chạy 2h có thể rollback 2h

Phát hiện Long-running Transactions

-- Tìm transactions đang chạy lâu
SELECT 
    ses.session_id,
    ses.login_name,
    ses.host_name,
    ses.status,
    req.command,
    req.wait_type,
    req.wait_time / 1000 AS wait_seconds,
    DATEDIFF(MINUTE, req.start_time, GETDATE()) AS running_minutes,
    tran.open_transaction_count,
    SUBSTRING(sql.text, (req.statement_start_offset/2)+1, 200) AS current_statement
FROM sys.dm_exec_sessions ses
INNER JOIN sys.dm_exec_requests req ON ses.session_id = req.session_id
INNER JOIN sys.dm_exec_session_wait_stats tran ON ses.session_id = tran.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) sql
WHERE req.open_transaction_count > 0
ORDER BY running_minutes DESC;

-- Kiểm tra oldest active transaction
SELECT 
    transaction_id,
    transaction_begin_time,
    DATEDIFF(MINUTE, transaction_begin_time, GETDATE()) AS minutes_open,
    name AS transaction_name
FROM sys.dm_tran_active_transactions
WHERE transaction_type = 1 -- User transaction
ORDER BY transaction_begin_time;

Best Practices xử lý long-running transactions

-- Thay vì một transaction lớn xóa 1 triệu rows:
-- BAD:
BEGIN TRANSACTION;
DELETE FROM OldLogs WHERE LogDate < '2020-01-01'; -- 1 triệu rows
COMMIT;

-- GOOD: Chia thành batches
DECLARE @BatchSize INT = 10000;
DECLARE @Deleted INT = 1;

WHILE @Deleted > 0
BEGIN
    DELETE TOP (@BatchSize) FROM OldLogs WHERE LogDate < '2020-01-01';
    SET @Deleted = @@ROWCOUNT;
    PRINT 'Deleted ' + CAST(@Deleted AS VARCHAR) + ' rows';
    -- Nhường CPU/IO cho session khác
    WAITFOR DELAY '00:00:01';
END;

9. Distributed Transactions & MSDTC

Distributed Transaction span qua nhiều SQL Server instances hoặc resource managers khác nhau.

Microsoft Distributed Transaction Coordinator (MSDTC)

MSDTC điều phối 2-Phase Commit Protocol:

1. Prepare Phase: MSDTC hỏi tất cả participants “bạn sẵn sàng commit chưa?”
2. Commit/Rollback Phase: Nếu tất cả OK → Commit. Một người fail → tất cả Rollback.

-- Explicit distributed transaction
BEGIN DISTRIBUTED TRANSACTION;
    -- Update trên server local
    UPDATE LocalDB.dbo.Inventory 
    SET Quantity = Quantity - 10 
    WHERE ProductId = 1;

    -- Update trên linked server (remote)
    UPDATE [RemoteWarehouse].WMS.dbo.Stock 
    SET OnHand = OnHand - 10 
    WHERE ProductId = 1;

COMMIT;

Khi nào tự động trở thành Distributed Transaction

-- SQL Server tự động promote thành distributed transaction khi:
-- 1. Query qua Linked Server trong transaction hiện tại
BEGIN TRANSACTION;
    UPDATE LocalTable SET ...; -- Local transaction
    SELECT * FROM [LinkedServer].RemoteDB.dbo.Table; -- Tự động promote!
COMMIT;

Vấn đề với MSDTC:

• Latency cao (network round trips cho handshake)
• MSDTC là single point of failure
• Khó debug khi có sự cố
• Modern architecture (microservices) thường dùng Saga Pattern với compensating transactions thay thế.

10. Error Handling với Transactions

Pattern chuẩn: TRY-CATCH-ROLLBACK

SET XACT_ABORT ON; -- Best practice: tự động rollback khi có lỗi
BEGIN TRANSACTION;
BEGIN TRY
    -- Step 1: Validate
    IF NOT EXISTS (SELECT 1 FROM Customers WHERE CustomerId = @CustomerId)
        THROW 50001, 'Customer not found', 1;

    -- Step 2: Create Order
    INSERT INTO Orders (CustomerId, CreatedAt)
    VALUES (@CustomerId, GETDATE());
    
    DECLARE @OrderId INT = SCOPE_IDENTITY();

    -- Step 3: Add Order Lines
    INSERT INTO OrderLines (OrderId, ProductId, Qty)
    SELECT @OrderId, ProductId, Qty
    FROM @OrderItems;

    -- Step 4: Update Inventory
    UPDATE Products 
    SET Stock = Stock - ol.Qty
    FROM Products p
    INNER JOIN OrderLines ol ON p.ProductId = ol.ProductId
    WHERE ol.OrderId = @OrderId;

    -- Commit nếu tất cả OK
    COMMIT TRANSACTION;
    SELECT @OrderId AS NewOrderId;
END TRY
BEGIN CATCH
    -- Rollback nếu có lỗi bất kỳ
    IF @@TRANCOUNT > 0
        ROLLBACK TRANSACTION;
    
    -- Log error
    INSERT INTO ErrorLog (ErrorNumber, ErrorMessage, ErrorLine, ErrorTime)
    VALUES (ERROR_NUMBER(), ERROR_MESSAGE(), ERROR_LINE(), GETDATE());
    
    -- Re-throw để caller xử lý
    THROW;
END CATCH;

XACT_ABORT và ảnh hưởng

-- Không có XACT_ABORT:
BEGIN TRANSACTION;
    INSERT INTO T1 VALUES (1); -- OK
    INSERT INTO T1 VALUES (1); -- Duplicate KEY error → chỉ statement này fail
    INSERT INTO T1 VALUES (2); -- Statement này vẫn chạy!
COMMIT; -- @@TRANCOUNT = 1, commit T1=1 và T1=2 (không có duplicate)

-- Với XACT_ABORT ON:
SET XACT_ABORT ON;
BEGIN TRANSACTION;
    INSERT INTO T1 VALUES (1); -- OK
    INSERT INTO T1 VALUES (1); -- Error → TOÀN BỘ transaction bị rollback, @@TRANCOUNT = 0
    INSERT INTO T1 VALUES (2); -- Không được chạy
-- @@TRANCOUNT đã = 0, không cần ROLLBACK

XACT_STATE() — kiểm tra trạng thái transaction trong CATCH block:

BEGIN CATCH
    DECLARE @XactState INT = XACT_STATE();
    IF @XactState = -1
        ROLLBACK; -- Transaction không thể commit, PHẢI rollback
    ELSE IF @XactState = 1
        COMMIT; -- Transaction có thể commit (uncommittable = false)
    -- @XactState = 0: Không có transaction đang mở
END CATCH;

11. Best Practices

✅ Nên làm

-- 1. Giữ transaction càng ngắn càng tốt
BEGIN TRANSACTION;
    -- Chỉ DML statements cần thiết
    UPDATE Orders SET Status = 'Processed' WHERE OrderId = @Id;
    INSERT INTO Audit VALUES (@Id, GETDATE());
COMMIT;

-- 2. Luôn dùng SET XACT_ABORT ON trong stored procedures
CREATE PROCEDURE dbo.ProcessOrder @OrderId INT
AS
BEGIN
    SET XACT_ABORT ON;
    SET NOCOUNT ON;
    BEGIN TRANSACTION;
    -- ...
    COMMIT;
END;

-- 3. Kiểm tra @@TRANCOUNT trước ROLLBACK
IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;

-- 4. Dùng THROW thay vì RAISERROR để re-throw
BEGIN CATCH
    IF @@TRANCOUNT > 0 ROLLBACK;
    THROW; -- Giữ nguyên error info gốc
END CATCH;

❌ Không nên làm

-- 1. Tương tác người dùng bên trong transaction
BEGIN TRANSACTION;
    UPDATE Products SET Price = @NewPrice WHERE ProductId = @Id;
    -- ĐỪNG: Chờ user confirm trước khi commit
    -- Lock giữ trong khi chờ → blocking!
COMMIT;

-- 2. Transaction quá lớn
BEGIN TRANSACTION;
    DELETE FROM Logs WHERE CreatedAt < '2020-01-01'; -- 10 triệu rows!
COMMIT;
-- → Log file phình to, block other sessions, rollback time lâu

-- 3. Quên ROLLBACK trong error handling
BEGIN TRANSACTION;
    UPDATE ...;
    IF @@ERROR <> 0
        RETURN; -- NGUY HIỂM: Transaction vẫn đang mở!
COMMIT;

-- 4. Dùng SELECT ... NOLOCK trong financial queries
SELECT SUM(Balance) FROM Accounts WITH (NOLOCK); -- Có thể sai vì dirty read!

Tóm tắt nhanh

Isolation Levels

Isolation Levels (Mức độ cô lập) xác định mức độ mà một transaction phải bị cô lập khỏi các thao tác đọc/ghi của các transaction đồng thời khác. Chọn đúng isolation level là sự cân bằng giữa tính nhất quán dữ liệu và hiệu suất đồng thời (concurrency).

1. Các vấn đề Concurrency (Tại sao cần Isolation Levels?)

Dirty Read

Transaction đọc dữ liệu mà transaction khác đang sửa nhưng chưa COMMIT. Nếu transaction kia ROLLBACK, dữ liệu đã đọc là không tồn tại.

-- Session 1: Chưa commit
BEGIN TRANSACTION;
UPDATE Products SET Price = 999 WHERE ProductId = 1; -- Giá thực: 500
-- Chưa COMMIT...

-- Session 2 (READ UNCOMMITTED): Đọc được 999 — Dirty Read!
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT Price FROM Products WHERE ProductId = 1; -- Trả về 999 (SAI!)

-- Session 1: Rollback → giá thực vẫn là 500
ROLLBACK;

Non-repeatable Read

Cùng một row được đọc hai lần trong cùng transaction nhưng cho kết quả khác nhau vì transaction khác đã UPDATE/DELETE row đó giữa hai lần đọc.

-- Session 1 (READ COMMITTED):
BEGIN TRANSACTION;
SELECT Price FROM Products WHERE ProductId = 1; -- Lần 1: 500

-- Session 2: Commit update
UPDATE Products SET Price = 800 WHERE ProductId = 1;
COMMIT;

-- Session 1: Đọc lại (vẫn trong cùng transaction)
SELECT Price FROM Products WHERE ProductId = 1; -- Lần 2: 800 → Non-repeatable Read!
ROLLBACK;

Phantom Read

Cùng một query (với WHERE condition) được chạy hai lần nhưng trả về số rows khác nhau vì transaction khác đã INSERT/DELETE rows phù hợp với điều kiện WHERE giữa hai lần chạy.

-- Session 1 (REPEATABLE READ):
BEGIN TRANSACTION;
SELECT * FROM Orders WHERE Amount > 1000000; -- Lần 1: 5 rows

-- Session 2: Thêm order mới
INSERT INTO Orders (CustomerId, Amount) VALUES (1, 2000000);
COMMIT;

-- Session 1: Đọc lại
SELECT * FROM Orders WHERE Amount > 1000000; -- Lần 2: 6 rows → Phantom Read!
ROLLBACK;

Lost Update

Hai transactions cùng đọc một giá trị, sau đó cùng update dựa trên giá trị đọc được — một trong hai update bị ghi đè (overwrite) mất.

-- Cả hai cùng đọc: Quantity = 100
-- Session 1: UPDATE Products SET Quantity = 100 - 10 = 90 WHERE Id = 1;
-- Session 2: UPDATE Products SET Quantity = 100 - 15 = 85 WHERE Id = 1;
-- Kết quả cuối: 85 (mất đi việc trừ 10 của Session 1!) → Lost Update

2. Ma trận Isolation Levels vs Concurrency Problems

* RCSI đọc snapshot tại thời điểm statement bắt đầu — không phải transaction bắt đầu.
** SNAPSHOT phát hiện write conflicts và fail transaction.

3. READ UNCOMMITTED — Mức thấp nhất

Cơ chế: Không lấy bất kỳ shared lock nào khi đọc. Đọc được mọi dữ liệu kể cả chưa commit.

Cho phép: Dirty Read, Non-repeatable Read, Phantom Read.

-- Cách 1: Set cho toàn session
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT * FROM Orders;

-- Cách 2: NOLOCK hint (tương đương READ UNCOMMITTED cho query đó)
SELECT * FROM Orders WITH (NOLOCK);

-- Cách 3: READUNCOMMITTED hint
SELECT * FROM Orders WITH (READUNCOMMITTED);

Khi nào dùng: Báo cáo approximate (ước tính) cần tốc độ, chấp nhận số liệu không chính xác tuyệt đối. Ví dụ: Dashboard hiển thị “khoảng X đơn hàng đang xử lý”.

⚠️ Cảnh báo nghiêm trọng với NOLOCK:

• Đọc được dữ liệu sẽ bị rollback (Dirty Read)
• Có thể skip rows (bỏ sót rows) khi page split xảy ra
• Có thể đọc trùng rows (duplicate rows)
• KHÔNG BAO GIỜ dùng trong: báo cáo tài chính, tính toán tổng/số lượng cần chính xác, business logic quan trọng.

4. READ COMMITTED — Mặc định của SQL Server

Cơ chế: Lấy shared lock khi đọc, giải phóng ngay khi đọc xong (statement-level). Chỉ đọc dữ liệu đã COMMIT.

Ngăn chặn: Dirty Read.
Cho phép: Non-repeatable Read, Phantom Read.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED; -- Đây là mặc định

BEGIN TRANSACTION;
    SELECT Price FROM Products WHERE ProductId = 1; -- 500, lấy S lock rồi release
    
    -- Trong lúc này, session khác CÓ THỂ update và commit!
    
    SELECT Price FROM Products WHERE ProductId = 1; -- Có thể là 800 → Non-repeatable Read
COMMIT;

Ưu điểm: Cân bằng tốt giữa consistency và concurrency. Phù hợp cho hầu hết OLTP scenarios.
Nhược điểm: Readers block writers (và ngược lại) → giải quyết bằng RCSI.

5. REPEATABLE READ

Cơ chế: Giữ shared lock cho đến khi transaction kết thúc. Đảm bảo cùng một row đọc nhiều lần sẽ cho kết quả giống nhau.

Ngăn chặn: Dirty Read, Non-repeatable Read, Lost Update.
Cho phép: Phantom Read.

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

BEGIN TRANSACTION;
    SELECT Price FROM Products WHERE ProductId = 1; -- 500, giữ S lock
    
    -- Session khác muốn UPDATE ProductId = 1 sẽ bị BLOCK!
    -- S lock giữ cho đến COMMIT
    
    SELECT Price FROM Products WHERE ProductId = 1; -- LUÔN LUÔN là 500
    
    -- Nhưng INSERT rows mới vẫn có thể xảy ra → Phantom Read vẫn được
COMMIT; -- Giải phóng tất cả S locks

Khi nào dùng: Khi cần đọc cùng dữ liệu nhiều lần trong cùng transaction và phải nhất quán (ví dụ: tính toán phức tạp trên cùng tập dữ liệu).
Nhược điểm: Giảm concurrency đáng kể vì giữ locks lâu.

6. SERIALIZABLE — Mức cao nhất

Cơ chế: Thêm key-range locks vào REPEATABLE READ. Ngăn chặn INSERT vào ranges mà transaction đang query.

Ngăn chặn: Tất cả — Dirty Read, Non-repeatable Read, Phantom Read, Lost Update.
Cho phép: Không có concurrency anomaly nào.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

BEGIN TRANSACTION;
    -- Query này lock cả key-range Orders WHERE Amount > 1000000
    SELECT * FROM Orders WHERE Amount > 1000000; -- 5 rows, lock key range
    
    -- Session khác muốn INSERT Orders (Amount = 2000000) sẽ bị BLOCK!
    
    SELECT * FROM Orders WHERE Amount > 1000000; -- LUÔN LUÔN là 5 rows
COMMIT;

Khi nào dùng: Giao dịch tài chính cần độ chính xác tuyệt đối, kiểm kho (inventory check + reserve), phân bổ số thứ tự (allocation).
Nhược điểm: Giảm concurrency nhất, dễ gây deadlock nhất.

7. READ COMMITTED SNAPSHOT ISOLATION (RCSI)

RCSI là phiên bản “optimistic” của READ COMMITTED, dùng row versioning thay vì shared locks.

Cách hoạt động

Khi a row bị UPDATE, SQL Server:

1. Ghi phiên bản cũ của row vào Version Store trong tempdb
2. Row trên data page được update với version mới

Khi một reader muốn đọc, thay vì chờ lock → reader đọc committed version gần nhất từ Version Store (không cần lock!).

-- Bật RCSI cho database (phải không có connection nào đang dùng)
ALTER DATABASE MyDatabase SET READ_COMMITTED_SNAPSHOT ON WITH NO_WAIT;

-- Kiểm tra
SELECT name, is_read_committed_snapshot_on
FROM sys.databases WHERE name = 'MyDatabase';

-- Khi đã bật, không cần thay đổi code:
-- Tất cả READ COMMITTED queries tự động dùng row versioning
SET TRANSACTION ISOLATION LEVEL READ COMMITTED; -- Vẫn dùng level này
SELECT * FROM Orders; -- Nhưng không block, không bị block

So sánh READ COMMITTED vs RCSI

-- Scenario: Session 1 UPDATE chưa commit, Session 2 SELECT

-- Với READ COMMITTED (không có RCSI):
-- Session 1: BEGIN TRAN; UPDATE Orders SET Status = 'Processed' WHERE Id = 1;
-- Session 2: SELECT * FROM Orders WHERE Id = 1; → BLOCKED! Phải chờ Session 1

-- Với RCSI bật:
-- Session 1: BEGIN TRAN; UPDATE Orders SET Status = 'Processed' WHERE Id = 1;
-- Session 2: SELECT * FROM Orders WHERE Id = 1; → Đọc ngay phiên bản cũ (committed)!
-- Không bị block!

Đặc điểm của RCSI

• Statement-level snapshot: Mỗi statement thấy committed data tại thời điểm statement bắt đầu
• Writers không block Readers và ngược lại
• Overhead: tempdb phải lưu version store → tempdb lớn hơn
• Mặc định trong Azure SQL Database: Luôn bật

8. SNAPSHOT ISOLATION

SNAPSHOT ISOLATION là transaction-level snapshot — toàn bộ transaction thấy cùng một snapshot từ thời điểm transaction bắt đầu (không phải statement bắt đầu).

-- Step 1: Cho phép Snapshot Isolation ở database level
ALTER DATABASE MyDatabase SET ALLOW_SNAPSHOT_ISOLATION ON;

-- Step 2: Session sử dụng
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;

BEGIN TRANSACTION; -- Snapshot được tạo tại thời điểm này!
    -- Mọi SELECT trong transaction này thấy data tại thời điểm BEGIN TRAN
    SELECT * FROM Orders WHERE CustomerId = 1; -- Snapshot tại T0

    -- Dù session khác commit update, bạn vẫn thấy snapshot T0
    
    SELECT * FROM Orders WHERE CustomerId = 1; -- Vẫn là snapshot T0 → Repeatable!
COMMIT;

Write Conflict Detection — Điểm khác biệt với RCSI

SET TRANSACTION ISOLATION LEVEL SNAPSHOT;

BEGIN TRANSACTION; -- Snapshot tại T0, Orders.Status = 'Pending'

    -- Session khác: UPDATE Orders SET Status = 'Cancelled' WHERE OrderId = 1; COMMIT;
    
    -- Bạn cố UPDATE cùng row:
    UPDATE Orders SET Status = 'Processed' WHERE OrderId = 1;
    -- → LỖI! Error 3960: Snapshot isolation transaction aborted due to update conflict.
    -- SNAPSHOT phát hiện row đã bị modify sau khi transaction bắt đầu
COMMIT;

Đây là Optimistic Concurrency: Assume không có conflict, nhưng check khi commit. Phù hợp khi conflicts hiếm.

9. Row Versioning — Cơ chế nền tảng

Cả RCSI và SNAPSHOT ISOLATION đều dùng Row Versioning Store trong tempdb:

Data Page (data file):
┌─────────────────────────────────────────────┐
│ Row: OrderId=1, Amount=500, [Version Ptr] ───┼──► tempdb Version Store
└─────────────────────────────────────────────┘

tempdb Version Store:
┌─────────────────────────────────────────────┐
│ Version 1: OrderId=1, Amount=500 (original) │ ← Reader thấy cái này
│ Version 2: OrderId=1, Amount=800 (new)      │ ← Writer đang update
└─────────────────────────────────────────────┘

Monitor Version Store:

-- Xem kích thước version store
SELECT 
    DB_NAME(database_id) AS DatabaseName,
    SUM(version_store_reserved_page_count) * 8 AS version_store_KB
FROM sys.dm_db_file_space_usage
GROUP BY database_id
ORDER BY version_store_KB DESC;

-- Xem oldest active snapshot transaction (giữ versions lâu nhất)
SELECT 
    transaction_id,
    transaction_begin_time,
    DATEDIFF(SECOND, transaction_begin_time, GETDATE()) AS seconds_open,
    elapsed_time_seconds
FROM sys.dm_tran_active_snapshot_database_transactions
ORDER BY transaction_begin_time;

10. Đặt Isolation Level

Session Level

-- Cài đặt cho toàn bộ session từ đây trở đi
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;    -- Mặc định
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;           -- Cần ALLOW_SNAPSHOT_ISOLATION ON

Query Level (Table Hints)

-- Read Uncommitted (Dirty Read OK)
SELECT * FROM Orders WITH (NOLOCK);
SELECT * FROM Orders WITH (READUNCOMMITTED);

-- Read Committed (default behavior)
SELECT * FROM Orders WITH (READCOMMITTED);

-- Repeatable Read
SELECT * FROM Orders WITH (REPEATABLEREAD);

-- Serializable
SELECT * FROM Orders WITH (SERIALIZABLE);
SELECT * FROM Orders WITH (HOLDLOCK); -- Tương đương SERIALIZABLE

-- Update Lock (dùng khi chuẩn bị UPDATE)
SELECT * FROM Orders WITH (UPDLOCK) WHERE OrderId = 1;

-- Serializable + Update Lock
SELECT * FROM Orders WITH (UPDLOCK, HOLDLOCK) WHERE OrderId = 1;

11. Performance Implications

Locking Approach (READ COMMITTED, REPEATABLE READ, SERIALIZABLE)

Ưu điểm:
+ Không overhead để ghi version history
+ Đơn giản, ít phức tạp

Nhược điểm:
- Readers block Writers
- Writers block Readers  
- Deadlock risk cao hơn
- Latency cao hơn trong môi trường contention cao

Row Versioning Approach (RCSI, SNAPSHOT)

Ưu điểm:
+ Readers không block Writers (và ngược lại)
+ Latency thấp hơn khi có contention
+ Ít deadlock hơn (read-write deadlocks không xảy ra)

Nhược điểm:
- tempdb overhead (version store phải duy trì)
- Long-running transactions → version store phình to
- Slight overhead để đọc từ version chain
- Write conflicts trong SNAPSHOT có thể cần retry logic

Benchmark guidelines

-- Kiểm tra version cleanup performance
SELECT 
    version_store_reserved_page_count * 8.0 / 1024 AS version_store_MB,
    version_cleanup_rate_kb_per_s
FROM sys.dm_os_performance_counters
WHERE object_name LIKE '%Transactions%'
AND counter_name IN ('Version Store Size (KB)', 'Version Cleanup rate (KB/s)');

12. Chọn Isolation Level đúng

OLTP (Online Transaction Processing)

-- Use Case: Đặt hàng, thanh toán
-- Dùng: READ COMMITTED + RCSI (best practice)
-- Lý do: Readers không block writers, ít deadlock, consistent reads

-- Setup database:
ALTER DATABASE OrderDB SET READ_COMMITTED_SNAPSHOT ON;
-- Không cần thay đổi code, tự động áp dụng

Báo cáo / Analytics trên Production DB

-- Use Case: Report cần chạy trên live DB, chấp nhận dữ liệu hơi cũ
-- Dùng: SNAPSHOT ISOLATION hoặc query on replica
SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRANSACTION;
    -- Report queries - thấy consistent snapshot tại thời điểm bắt đầu
    SELECT SUM(Amount) FROM Orders WHERE OrderDate = CAST(GETDATE() AS DATE);
    SELECT COUNT(*) FROM Customers WHERE CreatedAt > DATEADD(DAY, -30, GETDATE());
COMMIT;

Tài chính / Tồn kho cần chính xác tuyệt đối

-- Use Case: Kiểm tra và giữ tồn kho trước khi bán
-- Dùng: SERIALIZABLE hoặc REPEATABLE READ + UPDLOCK hint
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;
    -- Check tồn kho
    SELECT Stock FROM Products WHERE ProductId = @ProductId;
    
    -- Trong serializable: không có INSERT/UPDATE nào có thể chen vào!
    
    IF (SELECT Stock FROM Products WHERE ProductId = @ProductId) >= @Quantity
    BEGIN
        UPDATE Products SET Stock = Stock - @Quantity WHERE ProductId = @ProductId;
        INSERT INTO Orders ...;
    END
COMMIT;

-- Hoặc dùng UPDLOCK hint để ít restrictive hơn:
BEGIN TRANSACTION;
    SELECT Stock 
    FROM Products WITH (UPDLOCK, ROWLOCK) -- Ngăn concurrent updates
    WHERE ProductId = @ProductId;
    
    UPDATE Products SET Stock = Stock - @Quantity WHERE ProductId = @ProductId;
COMMIT;

Kiểm tra nhanh không cần chính xác 100%

-- Use Case: Dashboard monitoring, approximate counts
-- Dùng: READ UNCOMMITTED / NOLOCK
SELECT 
    COUNT(*) AS ApproxPendingOrders
FROM Orders WITH (NOLOCK)
WHERE Status = 'Pending';

Tóm tắt

Locking, Blocking & Deadlocks

SQL Server dùng locking mechanism để kiểm soát truy cập đồng thời vào dữ liệu, đảm bảo tính toàn vẹn của transactions. Hiểu rõ cơ chế locking là yêu cầu bắt buộc để diagnose và giải quyết các vấn đề hiệu suất trong production.

1. Các loại Lock (Lock Types)

Shared Lock (S) — Đọc

• Lấy khi thực hiện SELECT
• Nhiều Shared lock có thể tồn tại đồng thời trên cùng resource
• Không compatible với Exclusive lock
• Trong READ COMMITTED: giải phóng sau khi đọc xong statement
• Trong REPEATABLE READ/SERIALIZABLE: giữ đến khi transaction kết thúc

Exclusive Lock (X) — Ghi

• Lấy khi thực hiện INSERT, UPDATE, DELETE
• Không compatible với bất kỳ lock nào khác
• Chỉ một X lock tại một thời điểm
• Giữ đến khi transaction kết thúc (COMMIT/ROLLBACK)

Update Lock (U) — Chuẩn bị Update

• Bước trung gian khi SQL Server scan để tìm rows cần UPDATE
• Compatible với S lock (nhiều readers có thể đọc trong khi U scan)
• Không compatible với U lock khác (ngăn chặn deadlock U→X)
• Sẽ convert sang X lock khi thực sự modify row

Intent Locks — Cấp thấp hơn thông báo ý định

Intent locks được đặt ở cấp Page/Table để thông báo lock intention ở cấp thấp hơn (Row), giúp SQL Server kiểm tra nhanh compatibility mà không cần scan từng row:

Schema Locks

Bulk Update Lock (BU)

Dùng trong BULK INSERT với TABLOCK hint — cho phép nhiều bulk insert đồng thời trên cùng table.

Key-Range Lock (SERIALIZABLE only)

Khóa khoảng giá trị trong index để ngăn Phantom Read:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN TRANSACTION;
SELECT * FROM Orders WHERE Amount BETWEEN 1000 AND 5000;
-- Locks key range [1000, 5000] — ngăn INSERT vào range này

2. Lock Compatibility Matrix

Bảng tương thích giữa các loại lock (✅ = Compatible, ❌ = Conflict):

3. Lock Granularity & Lock Escalation

Hierarchy của lock granularity (từ nhỏ đến lớn)

Database → File → Filegroup → Table → Extent → Page → Row (RID/KEY)

SQL Server cố gắng lock ở level nhỏ nhất (row-level) để maximize concurrency.

Lock Escalation

Khi số lượng row/page locks trong một statement vượt ngưỡng (~5,000 locks), SQL Server escalate (nâng cấp) lên table lock để tiết kiệm memory lock manager.

5,000 row locks × (64 bytes/lock) = 320KB bộ nhớ → Escalate!

Vấn đề: Table lock block toàn bộ table → giảm concurrency.

-- Xem lock escalation đang xảy ra
SELECT 
    object_name(object_id) AS TableName,
    index_id,
    last_escalation_time,
    escalation_attempt_count,
    escalation_success_count
FROM sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL)
WHERE escalation_success_count > 0
ORDER BY escalation_success_count DESC;

-- Tắt lock escalation cho table cụ thể
ALTER TABLE dbo.HighTrafficTable SET (LOCK_ESCALATION = DISABLE);

-- Hoặc chỉ cho phép escalate lên partition level (partitioned tables)
ALTER TABLE dbo.PartitionedTable SET (LOCK_ESCALATION = AUTO);

-- Force row-level locks trong query
SELECT * FROM BigTable WITH (ROWLOCK) WHERE Id > 1000;

Monitor Locks hiện tại

-- Xem tất cả locks đang active
SELECT 
    resource_type,
    resource_subtype,
    resource_database_id,
    resource_description,
    resource_associated_entity_id,
    request_mode,
    request_type,
    request_status,
    request_session_id as session_id,
    resource_lock_partition
FROM sys.dm_tran_locks
WHERE resource_database_id = DB_ID()
ORDER BY request_session_id, resource_type;

-- Locks của một session cụ thể
SELECT 
    tl.request_session_id,
    tl.resource_type,
    tl.resource_description,
    tl.request_mode,
    tl.request_status,
    OBJECT_NAME(p.object_id) AS table_name
FROM sys.dm_tran_locks tl
LEFT JOIN sys.partitions p ON tl.resource_associated_entity_id = p.hobt_id
WHERE tl.request_session_id = 55 -- thay session_id
AND tl.resource_database_id = DB_ID();

4. Blocking

Blocking xảy ra như thế nào

Session A (spid 52):
  BEGIN TRAN;
  UPDATE Orders SET Status = 'Processing' WHERE OrderId = 1;
  -- Giữ X lock trên OrderId = 1
  -- Chưa COMMIT...

Session B (spid 67):
  SELECT * FROM Orders WHERE OrderId = 1;
  -- Muốn S lock → CONFLICT với X lock của spid 52
  -- → BLOCKED! Phải chờ spid 52 COMMIT/ROLLBACK

Phát hiện Blocking

-- Cách 1: sp_who2 (đơn giản, nhanh)
EXEC sp_who2;
-- Cột BlkBy: session_id của blocker (0 = không bị block)

-- Cách 2: sys.dm_exec_requests (chi tiết hơn)
SELECT 
    r.session_id,
    r.blocking_session_id,
    r.status,
    r.wait_type,
    r.wait_time / 1000.0 AS wait_seconds,
    r.total_elapsed_time / 1000.0 AS elapsed_seconds,
    DB_NAME(r.database_id) AS database_name,
    SUBSTRING(st.text, (r.statement_start_offset/2)+1,
        ((CASE r.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE r.statement_end_offset 
          END - r.statement_start_offset)/2)+1) AS current_statement,
    qp.query_plan
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) st
CROSS APPLY sys.dm_exec_query_plan(r.plan_handle) qp
WHERE r.blocking_session_id > 0;

-- Cách 3: Cây blocking (blocking chain)
WITH BlockingChain AS (
    SELECT 
        session_id,
        blocking_session_id,
        CAST(session_id AS VARCHAR(100)) AS chain,
        0 AS level
    FROM sys.dm_exec_requests
    WHERE blocking_session_id = 0 AND session_id IN (
        SELECT blocking_session_id FROM sys.dm_exec_requests WHERE blocking_session_id <> 0
    )
    UNION ALL
    SELECT 
        r.session_id,
        r.blocking_session_id,
        bc.chain + ' → ' + CAST(r.session_id AS VARCHAR(10)),
        bc.level + 1
    FROM sys.dm_exec_requests r
    INNER JOIN BlockingChain bc ON r.blocking_session_id = bc.session_id
)
SELECT * FROM BlockingChain ORDER BY chain;

-- Cách 4: sys.dm_os_waiting_tasks
SELECT 
    wt.session_id,
    wt.blocking_session_id,
    wt.wait_type,
    wt.wait_duration_ms / 1000.0 AS wait_seconds,
    wt.resource_description
FROM sys.dm_os_waiting_tasks wt
WHERE wt.blocking_session_id IS NOT NULL;

LOCK_TIMEOUT — Hết kiên nhẫn chờ

-- Set timeout (milliseconds): fail sau 5 giây chờ
SET LOCK_TIMEOUT 5000;

BEGIN TRY
    SELECT * FROM Orders WHERE OrderId = 1; -- Blocked...
    -- Nếu chờ > 5000ms → Error 1222: Lock request time out period exceeded
END TRY
BEGIN CATCH
    IF ERROR_NUMBER() = 1222
        PRINT 'Lock timeout - resource is blocked';
END CATCH;

-- Reset về vô hạn
SET LOCK_TIMEOUT -1;

-- Kiểm tra setting hiện tại
SELECT lock_timeout FROM sys.dm_exec_sessions WHERE session_id = @@SPID;

5. Deadlocks

Deadlock xảy ra như thế nào

Deadlock là tình trạng circular dependency — không ai chịu nhường ai:

Session A (spid 52):              Session B (spid 67):
BEGIN TRAN;                        BEGIN TRAN;
UPDATE TableA SET ...              UPDATE TableB SET ...
  → Giữ X lock trên TableA          → Giữ X lock trên TableB

UPDATE TableB SET ...              UPDATE TableA SET ...
  → Muốn X lock trên TableB          → Muốn X lock trên TableA
  → BLOCKED bởi spid 67             → BLOCKED bởi spid 52

                  ↕ DEADLOCK! ↕
SQL Server chọn một trong hai làm "deadlock victim" và ROLLBACK nó.

Minh hoạ vòng tròn:

spid 52 → chờ spid 67 (lock TableB)
spid 67 → chờ spid 52 (lock TableA)
→ Circular dependency → DEADLOCK

Deadlock Victim Selection

SQL Server chọn victim để ROLLBACK dựa trên:

1. DEADLOCK_PRIORITY: Session có priority thấp hơn bị chọn
2. Transaction cost: Session có ít log records hơn (rẻ hơn để rollback) bị chọn

-- Tự nguyện làm victim
SET DEADLOCK_PRIORITY LOW;    -- Range: -10 (LOWEST) đến 10 (HIGHEST), default NORMAL=0

-- Victim nhận lỗi:
-- Msg 1205, Level 13, State 51
-- Transaction (Process ID XX) was deadlocked on lock resources with another process
-- and has been chosen as the deadlock victim. Rerun the transaction.

Phát hiện Deadlock

Cách 1: Trace Flags (Legacy)

-- Bật globally (ảnh hưởng tất cả sessions)
DBCC TRACEON(1222, -1); -- Detailed deadlock info vào Error Log
DBCC TRACEON(1204, -1); -- Basic deadlock info

-- Xem Error Log để thấy deadlock
EXEC sp_readerrorlog 0, 1, 'deadlock';

-- Tắt
DBCC TRACEOFF(1222, -1);

Cách 2: Extended Events (Recommended)

-- Tạo XEvent session để capture deadlock graphs
CREATE EVENT SESSION [DeadlockMonitor] ON SERVER
ADD EVENT sqlserver.xml_deadlock_report(
    ACTION(sqlserver.client_app_name, sqlserver.client_hostname,
           sqlserver.database_name, sqlserver.username)
)
ADD TARGET package0.ring_buffer(SET max_memory = 51200)
WITH (MAX_DISPATCH_LATENCY = 5 SECONDS);

-- Bật session
ALTER EVENT SESSION [DeadlockMonitor] ON SERVER STATE = START;

-- Xem deadlock graphs (XML)
SELECT 
    xdr.value('@timestamp', 'datetime2') AS DeadlockTime,
    xdr.query('.') AS DeadlockGraph
FROM (
    SELECT CAST(target_data AS XML) AS target_data
    FROM sys.dm_xe_session_targets t
    INNER JOIN sys.dm_xe_sessions s ON t.event_session_address = s.address
    WHERE s.name = 'DeadlockMonitor'
    AND t.target_name = 'ring_buffer'
) AS data
CROSS APPLY target_data.nodes('//RingBufferTarget/event') AS XEventData(xdr)
ORDER BY DeadlockTime DESC;

-- Tắt và xóa session khi không cần
ALTER EVENT SESSION [DeadlockMonitor] ON SERVER STATE = STOP;
DROP EVENT SESSION [DeadlockMonitor] ON SERVER;

Cách 3: System Health Session (luôn bật sẵn)

-- SQL Server tự có session 'system_health' luôn capture deadlocks
SELECT 
    xdr.value('@timestamp', 'datetime2') AS DeadlockTime,
    xdr.query('.') AS DeadlockGraph
FROM (
    SELECT CAST(target_data AS XML) AS target_data
    FROM sys.dm_xe_session_targets t
    INNER JOIN sys.dm_xe_sessions s ON t.event_session_address = s.address
    WHERE s.name = 'system_health'
    AND t.target_name = 'ring_buffer'
) AS data
CROSS APPLY target_data.nodes('//RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData(xdr)
ORDER BY DeadlockTime DESC;

6. Chiến lược Ngăn chặn Deadlock

Chiến lược 1: Access objects theo cùng thứ tự

-- BAD: T1 lock A rồi B, T2 lock B rồi A → Deadlock tiềm năng
-- Transaction 1:
BEGIN TRAN; UPDATE Accounts ...; UPDATE Inventory ...;

-- Transaction 2:
BEGIN TRAN; UPDATE Inventory ...; UPDATE Accounts ...; -- ← Đảo ngược!

-- GOOD: Cả hai đều lock theo thứ tự A → B
-- Transaction 1:
BEGIN TRAN; UPDATE Accounts ...; UPDATE Inventory ...; COMMIT;

-- Transaction 2:
BEGIN TRAN; UPDATE Accounts ...; UPDATE Inventory ...; COMMIT;

Chiến lược 2: Giữ transaction ngắn

-- BAD: Xử lý nặng trong transaction
BEGIN TRANSACTION;
    SELECT @Data = -- complex calculation
    EXECUTE dbo.SlowProcedure @Data; -- 30 giây
    UPDATE Table1 SET ...;
COMMIT; -- Lock giữ 30+ giây

-- GOOD: Tính toán ngoài transaction
EXECUTE dbo.SlowProcedure @Data; -- Tính ngoài (30 giây, không lock)
BEGIN TRANSACTION;
    UPDATE Table1 SET ...;
COMMIT; -- Lock chỉ giữ mili giây

Chiến lược 3: Dùng UPDLOCK thay vì S → X conversion

-- BAD: Deadlock pattern phổ biến (Select then Update)
BEGIN TRAN;
    SELECT @Stock = Stock FROM Products WHERE ProductId = 1; -- S lock
    -- Thời điểm này: Session khác cũng lấy S lock!
    UPDATE Products SET Stock = @Stock - 1 WHERE ProductId = 1;
    -- Cả hai cùng muốn upgrade S → X → DEADLOCK!

-- GOOD: Lấy U lock từ đầu
BEGIN TRAN;
    SELECT @Stock = Stock 
    FROM Products WITH (UPDLOCK) -- U lock ngay từ đầu
    WHERE ProductId = 1;
    -- Session khác muốn UPDLOCK sẽ bị block (không deadlock!)
    UPDATE Products SET Stock = @Stock - 1 WHERE ProductId = 1;
COMMIT;

Chiến lược 4: Thêm index phù hợp

-- Thiếu index → Table/Index scan → Lock nhiều rows hơn cần thiết → Tăng deadlock risk
-- Với index tốt → Seek → Chỉ lock rows cần thiết

-- Kiểm tra missing indexes
SELECT 
    mid.statement AS missing_index_table,
    mid.equality_columns,
    mid.inequality_columns,
    mid.included_columns,
    migs.avg_user_impact AS estimated_improvement_pct,
    migs.user_seeks * migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) AS score
FROM sys.dm_db_missing_index_details mid
INNER JOIN sys.dm_db_missing_index_groups mig ON mid.index_handle = mig.index_handle
INNER JOIN sys.dm_db_missing_index_group_stats migs ON mig.index_group_handle = migs.group_handle
ORDER BY score DESC;

Chiến lược 5: Dùng RCSI/Snapshot để loại bỏ Read-Write Deadlocks

-- Bật RCSI: Readers không lấy S locks → Read-Write deadlock không thể xảy ra
ALTER DATABASE MyDatabase SET READ_COMMITTED_SNAPSHOT ON;
-- 70-80% deadlocks là Read-Write → RCSI loại bỏ phần lớn deadlocks

Chiến lược 6: Retry Logic trong Application

// C# với Polly
var policy = Policy
    .Handle<SqlException>(ex => ex.Number == 1205) // Deadlock victim
    .WaitAndRetry(
        retryCount: 3,
        sleepDurationProvider: attempt => 
            TimeSpan.FromMilliseconds(100 * Math.Pow(2, attempt)) // Exponential backoff
            + TimeSpan.FromMilliseconds(Random.Shared.Next(0, 100)) // Jitter
    );

await policy.ExecuteAsync(async () => {
    await ExecuteTransactionAsync();
});

7. Optimistic vs Pessimistic Concurrency

Pessimistic Concurrency (Locking-based)

Giả định: Conflicts xảy ra thường xuyên → Phải lock trước
Cơ chế: Lock tài nguyên trước khi đọc/ghi, giữ lock cho đến khi xong
Trade-off: Consistency cao, Concurrency thấp
Phù hợp: Môi trường high-contention, tài chính

-- Pessimistic: Lock ngay khi đọc
BEGIN TRAN;
    SELECT * FROM Products WITH (UPDLOCK, ROWLOCK) WHERE ProductId = 1;
    -- Bây giờ không ai có thể update ProductId = 1
    UPDATE Products SET Stock = Stock - 1 WHERE ProductId = 1;
COMMIT;

Optimistic Concurrency (Versioning-based)

Giả định: Conflicts hiếm khi xảy ra → Không cần lock
Cơ chế: Đọc không lock, khi ghi thì kiểm tra xem data có thay đổi không
Trade-off: Concurrency cao, phải retry khi có conflict
Phù hợp: Môi trường low-contention, web APIs

-- Optimistic với rowversion/timestamp column:
-- 1. Đọc với rowversion
SELECT ProductId, Stock, rowver FROM Products WHERE ProductId = 1;
-- → Nhận được: ProductId=1, Stock=100, rowver=0x0000000000000123

-- 2. Ghi với điều kiện rowver không đổi
UPDATE Products 
SET Stock = Stock - 1
WHERE ProductId = 1 AND rowver = 0x0000000000000123; -- Optimistic check!

IF @@ROWCOUNT = 0
    THROW 50001, 'Concurrent update detected - please retry', 1;
    -- Conflict! Row đã bị modify bởi người khác

8. Hints: NOLOCK, UPDLOCK, HOLDLOCK, ROWLOCK

NOLOCK (READUNCOMMITTED)

-- ⚠️ NGUY HIỂM: Dirty Read, skip rows, duplicate rows
SELECT COUNT(*) FROM Orders WITH (NOLOCK); -- Approximate count

-- KHÔNG BAO GIỜ dùng NOLOCK khi:
-- ✗ Tính toán tài chính (SUM, COUNT cho báo cáo chính xác)
-- ✗ Business logic dựa trên kết quả
-- ✗ Foreign key lookups
-- ✗ Kiểm tra tồn kho trước khi bán

UPDLOCK

-- Lấy U lock thay vì S lock — ngăn deadlock khi scan rồi update
SELECT ProductId, Stock 
FROM Products WITH (UPDLOCK)
WHERE Category = 'Electronics' AND Stock < 10;
-- Các rows này không thể bị concurrent update vì U lock

HOLDLOCK (= SERIALIZABLE)

-- Giữ S lock cho đến khi transaction kết thúc (như SERIALIZABLE)
SELECT * FROM Orders WITH (HOLDLOCK) WHERE CustomerId = 1;
-- Không ai có thể INSERT rows mới thỏa WHERE condition trong khi transaction đang chạy

-- Kết hợp
SELECT * FROM Orders WITH (UPDLOCK, HOLDLOCK) WHERE CustomerId = 1;
-- Vừa U lock, vừa giữ range lock

ROWLOCK

-- Force SQL Server dùng row-level lock (chống lock escalation)
UPDATE Orders WITH (ROWLOCK) 
SET Status = 'Processed' 
WHERE OrderDate < DATEADD(DAY, -1, GETDATE());

PAGLOCK, TABLOCK, TABLOCKX

-- PAGLOCK: Dùng page-level lock
-- TABLOCK: Lock toàn bộ table với S lock
-- TABLOCKX: Lock toàn bộ table với X lock (exclusive)

-- TABLOCK thường dùng với bulk operations
BULK INSERT dbo.StagingTable 
FROM 'C:\data\import.csv'
WITH (TABLOCK); -- Cho phép parallel bulk insert, minimal logging

9. sys.dm_tran_locks — Xem Locks hiện tại

-- Tất cả locks trong database hiện tại
SELECT
    tl.request_session_id AS SPID,
    tl.resource_type,
    tl.resource_subtype,
    CASE tl.resource_type
        WHEN 'OBJECT' THEN OBJECT_NAME(tl.resource_associated_entity_id)
        WHEN 'DATABASE' THEN DB_NAME(tl.resource_database_id)
        ELSE tl.resource_description
    END AS resource_name,
    tl.request_mode AS lock_mode,
    tl.request_status AS lock_status,
    tl.request_type,
    es.login_name,
    es.host_name,
    es.program_name
FROM sys.dm_tran_locks tl
JOIN sys.dm_exec_sessions es ON tl.request_session_id = es.session_id
WHERE tl.resource_database_id = DB_ID()
AND tl.resource_type <> 'DATABASE'
ORDER BY tl.request_session_id, tl.resource_type;

-- Tìm locks đang conflict (WAIT status)
SELECT
    blocked.request_session_id AS blocked_spid,
    blocker.request_session_id AS blocking_spid,
    blocked.resource_type,
    OBJECT_NAME(blocked.resource_associated_entity_id) AS object_name,
    blocked.request_mode AS blocked_lock_mode,
    blocker.request_mode AS blocking_lock_mode
FROM sys.dm_tran_locks blocked
JOIN sys.dm_tran_locks blocker 
    ON blocked.resource_associated_entity_id = blocker.resource_associated_entity_id
    AND blocked.resource_type = blocker.resource_type
WHERE blocked.request_status = 'WAIT'
AND blocker.request_status = 'GRANT';

10. Script tổng hợp: Blocking & Deadlock Diagnostic

-- =====================================================
-- Complete Blocking & Deadlock Diagnostic Script
-- =====================================================

-- 1. Tổng quan blocking ngay lập tức
PRINT '=== BLOCKING OVERVIEW ===';
SELECT
    r.session_id AS blocked_spid,
    r.blocking_session_id AS blocker_spid,
    r.wait_type,
    r.wait_time / 1000.0 AS wait_seconds,
    s.login_name AS blocked_login,
    s.host_name AS blocked_host,
    SUBSTRING(st.text, (r.statement_start_offset/2)+1, 200) AS blocked_query,
    s2.login_name AS blocker_login,
    s2.host_name AS blocker_host
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id
JOIN sys.dm_exec_sessions s2 ON r.blocking_session_id = s2.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE r.blocking_session_id > 0;

-- 2. Open transactions (tất cả)
PRINT '=== OPEN TRANSACTIONS ===';
SELECT
    s.session_id,
    s.login_name,
    s.host_name,
    s.open_transaction_count,
    DATEDIFF(SECOND, at.transaction_begin_time, GETDATE()) AS tran_seconds_open,
    at.name AS transaction_name,
    SUBSTRING(st.text, 1, 200) AS last_sql
FROM sys.dm_exec_sessions s
JOIN sys.dm_tran_session_transactions tst ON s.session_id = tst.session_id
JOIN sys.dm_tran_active_transactions at ON tst.transaction_id = at.transaction_id
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.open_transaction_count > 0
ORDER BY tran_seconds_open DESC;

-- 3. Lock summary
PRINT '=== LOCK SUMMARY BY TABLE ===';
SELECT
    OBJECT_NAME(p.object_id) AS table_name,
    tl.resource_type,
    tl.request_mode,
    COUNT(*) AS lock_count
FROM sys.dm_tran_locks tl
JOIN sys.partitions p ON tl.resource_associated_entity_id = p.hobt_id
WHERE tl.resource_database_id = DB_ID()
AND tl.resource_type IN ('KEY', 'PAGE', 'RID')
GROUP BY OBJECT_NAME(p.object_id), tl.resource_type, tl.request_mode
ORDER BY lock_count DESC;

Best Practices Tóm tắt

Security & Administration - Tổng quan

Phần này bao gồm các kiến thức về Bảo mật (Security) và Quản trị (Administration) SQL Server — những chủ đề quan trọng không chỉ cho DBA mà còn cho Developer khi thiết kế ứng dụng an toàn.

Các chủ đề con

Q&A Phỏng vấn

🟢 Junior Level

Q1: Hai chế độ Authentication trong SQL Server là gì?

A:

• Windows Authentication (Integrated Security): Xác thực qua Active Directory. SQL Server tin tưởng Windows đã xác thực user. Bảo mật hơn vì không cần password trong connection string. Là chế độ khuyến nghị.
• SQL Server Authentication: User/password được lưu trong SQL Server, không phụ thuộc vào Windows. Cần thiết khi connect từ non-Windows systems (Linux, Mac, containers).
• Mixed Mode: Hỗ trợ cả hai. Nên tắt SQL Server Authentication nếu không cần thiết (nguyên tắc least privilege).

Q2: Sự khác biệt giữa Login và User trong SQL Server là gì?

A:

• Login: Tồn tại ở server level — đây là authentication principal, cho phép kết nối vào SQL Server instance.
• User: Tồn tại ở database level — là authorization principal trong database cụ thể, mapping đến Login.

Login [DOMAIN\HuyNgo]  ←→  User [HuyNgo] trong database SalesDB
(Server level)               (Database level)

Một Login có thể map đến User trong nhiều databases. Nếu không có User mapping, Login không thể truy cập database.

Q3: GRANT, DENY, REVOKE khác nhau như thế nào?

A:

• GRANT: Cấp quyền cho principal.
• REVOKE: Xóa bỏ quyền đã GRANT hoặc DENY (về trạng thái “không có quyền”).
• DENY: Từ chối tường minh quyền — DENY luôn thắng GRANT dù user được GRANT qua role.

GRANT SELECT ON dbo.Products TO UserA;  -- UserA có thể SELECT
DENY SELECT ON dbo.Orders TO UserA;     -- UserA KHÔNG thể SELECT Orders dù qua role nào
REVOKE SELECT ON dbo.Products TO UserA; -- UserA không còn quyền SELECT Products được GRANT trực tiếp

Q4: SQL Injection là gì và cách phòng chống?

A: SQL Injection là tấn công khi attacker chèn SQL code độc hại vào input để thay đổi query logic.

-- VULNERABLE: String concatenation
DECLARE @sql NVARCHAR(500) = 'SELECT * FROM Users WHERE Name = ''' + @input + '''';
-- Input: ' OR '1'='1 → Lấy được tất cả users!

-- SAFE: Parameterized query
DECLARE @sql NVARCHAR(500) = 'SELECT * FROM Users WHERE Name = @name';
EXEC sp_executesql @sql, N'@name NVARCHAR(100)', @name = @input;

-- SAFE: Stored procedure với parameters
CREATE PROCEDURE dbo.GetUser @Name NVARCHAR(100)
AS SELECT * FROM Users WHERE Name = @Name;
-- Parameter không được interpret là SQL code

Q5: Các Fixed Database Roles phổ biến là gì?

A:

Q6: Làm thế nào để tạo Login và User cho một ứng dụng?

A:

-- Server level: Tạo Login
CREATE LOGIN AppLogin WITH PASSWORD = 'Str0ng!P@ssw0rd';

-- Database level: Tạo User và map với Login
USE MyDatabase;
CREATE USER AppUser FOR LOGIN AppLogin;

-- Gán Role
ALTER ROLE db_datareader ADD MEMBER AppUser;
ALTER ROLE db_datawriter ADD MEMBER AppUser;

-- Hoặc GRANT cụ thể
GRANT EXECUTE ON SCHEMA::dbo TO AppUser;

Q7: Transparent Data Encryption (TDE) là gì?

A: TDE mã hóa toàn bộ database files (data file .mdf, log file .ldf, backup files) ở tầng storage — “encryption at rest”. Dữ liệu được decrypt tự động khi đọc vào memory, không cần thay đổi application code.

Bảo vệ chống: Kẻ tấn công lấy file .mdf trực tiếp từ disk sẽ không đọc được.
Không bảo vệ: Ai có quyền query database vẫn đọc được dữ liệu bình thường.

Q8: Backup types trong SQL Server là gì?

A:

Q9: Recovery Models trong SQL Server là gì?

A:

Q10: sp_who2 và Activity Monitor dùng để làm gì?

A:

• sp_who2: Stored procedure hiển thị tất cả active sessions, blocking info, CPU/Disk usage. Dùng để diagnose nhanh.
• Activity Monitor: GUI trong SSMS hiển thị processes, waits, expensive queries, data file I/O.

EXEC sp_who2; -- Xem tất cả sessions
EXEC sp_who2 'active'; -- Chỉ active sessions
EXEC sp_who2 55; -- Session cụ thể

🟡 Mid Level

Q11: Row-Level Security (RLS) là gì và dùng để làm gì?

A: RLS cho phép kiểm soát quyền truy cập ở cấp row dựa trên người dùng đang query. Một table có thể trả về các rows khác nhau cho các user khác nhau — hoàn toàn transparent với application.

-- Ví dụ: Mỗi sales rep chỉ thấy orders của mình
CREATE FUNCTION dbo.fn_SecurityPredicate(@SalesRepId INT)
RETURNS TABLE
WITH SCHEMABINDING
AS RETURN
    SELECT 1 AS result
    WHERE @SalesRepId = CAST(SESSION_CONTEXT(N'SalesRepId') AS INT)
        OR IS_MEMBER('db_owner') = 1; -- Managers thấy tất cả

CREATE SECURITY POLICY SalesRepPolicy
ADD FILTER PREDICATE dbo.fn_SecurityPredicate(SalesRepId) ON dbo.Orders,
ADD BLOCK PREDICATE dbo.fn_SecurityPredicate(SalesRepId) ON dbo.Orders
WITH (STATE = ON);

-- Application set context trước khi query:
EXEC sys.sp_set_session_context @key = N'SalesRepId', @value = 42;
SELECT * FROM Orders; -- Tự động filter chỉ orders của SalesRepId = 42

Q12: Dynamic Data Masking (DDM) là gì?

A: DDM che giấu dữ liệu nhạy cảm cho các user không có quyền xem — không thay đổi dữ liệu thực, chỉ thay đổi cách hiển thị.

CREATE TABLE Customers (
    CustomerId INT PRIMARY KEY,
    FullName NVARCHAR(100) MASKED WITH (FUNCTION = 'partial(2,"...",2)'),      -- "Hu...go"
    Email NVARCHAR(200) MASKED WITH (FUNCTION = 'email()'),                    -- "hXX@XXXX.com"
    Phone NVARCHAR(20) MASKED WITH (FUNCTION = 'partial(0,"XXX-XXX-",4)'),   -- "XXX-XXX-1234"
    CreditCard NVARCHAR(20) MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)'), -- "XXXX-XXXX-XXXX-5678"
    Salary DECIMAL(10,2) MASKED WITH (FUNCTION = 'random(1, 100)')            -- Random số
);

-- User thường thấy:
-- FullName: "Hu...go", Email: "hXX@XXXX.com"

-- User có quyền UNMASK thấy dữ liệu thật:
GRANT UNMASK ON dbo.Customers TO PowerUser;
-- Hoặc UNMASK toàn database:
GRANT UNMASK TO PowerUser;

Q13: EXECUTE AS là gì và khi nào dùng?

A: EXECUTE AS cho phép thay đổi security context khi thực thi code — impersonate một user/login khác.

-- Stored procedure chạy dưới context của owner (không phải caller)
CREATE PROCEDURE dbo.GetSensitiveData
WITH EXECUTE AS OWNER -- hoặc EXECUTE AS 'SpecificUser'
AS
BEGIN
    -- Thực thi với quyền của OWNER dù caller không có quyền
    SELECT * FROM dbo.SensitiveTable;
END;

-- Gọi procedure:
-- User A không có SELECT trên SensitiveTable
-- Nhưng User A có EXECUTE quyền trên procedure
-- → Cho phép! (Ownership chaining)

-- Impersonation tạm thời:
EXECUTE AS USER = 'LimitedUser';
SELECT * FROM dbo.Orders; -- Thực thi dưới quyền LimitedUser
REVERT; -- Quay lại context gốc

Q14: Always Encrypted là gì? Khác TDE như thế nào?

A:

-- Always Encrypted: Dữ liệu được mã hóa TRƯỚC khi tới SQL Server
-- SQL Server chỉ thấy ciphertext, không thể đọc plaintext

-- Cột được tạo với encryption:
CREATE TABLE Patients (
    PatientId INT PRIMARY KEY,
    Name NVARCHAR(100),
    SSN NVARCHAR(11) ENCRYPTED WITH (
        COLUMN_ENCRYPTION_KEY = SSN_CEK,
        ENCRYPTION_TYPE = Randomized, -- hoặc Deterministic
        ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
    )
);
-- DBA query SELECT SSN FROM Patients → thấy ciphertext, không đọc được
-- Application (có CMK) → thấy plaintext

Q15: SQL Server Audit là gì? Thiết lập như thế nào?

A: SQL Server Audit cho phép track và log các hành động security/database vào file, Windows Event Log, hoặc Application Log.

-- Tạo Server Audit
CREATE SERVER AUDIT SecurityAudit
TO FILE (FILEPATH = 'C:\SQLAudit\', MAXSIZE = 100 MB, MAX_FILES = 10)
WITH (ON_FAILURE = CONTINUE);

ALTER SERVER AUDIT SecurityAudit WITH (STATE = ON);

-- Audit đăng nhập thất bại
CREATE SERVER AUDIT SPECIFICATION LoginAuditSpec
FOR SERVER AUDIT SecurityAudit
ADD (FAILED_LOGIN_GROUP),
ADD (SUCCESSFUL_LOGIN_GROUP);
ALTER SERVER AUDIT SPECIFICATION LoginAuditSpec WITH (STATE = ON);

-- Database audit: Track DML trên table nhạy cảm
CREATE DATABASE AUDIT SPECIFICATION SensitiveDataAudit
FOR SERVER AUDIT SecurityAudit
ADD (SELECT, INSERT, UPDATE, DELETE ON dbo.Customers BY public)
WITH (STATE = ON);

-- Xem audit log
SELECT 
    event_time,
    action_id,
    succeeded,
    session_server_principal_name AS login_name,
    statement,
    server_instance_name
FROM sys.fn_get_audit_file('C:\SQLAudit\*.sqlaudit', DEFAULT, DEFAULT)
ORDER BY event_time DESC;

Q16: Schema-based permissions là gì? Lợi ích?

A: Thay vì GRANT quyền trên từng object, có thể GRANT trên toàn bộ schema — tất cả objects trong schema tự động inherit permission.

-- Tạo schema riêng cho app
CREATE SCHEMA app AUTHORIZATION dbo;

-- Tạo objects trong schema
CREATE TABLE app.Orders (...);
CREATE TABLE app.Products (...);
CREATE PROCEDURE app.GetOrders AS ...;

-- GRANT một lần cho toàn schema (thay vì từng object)
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::app TO AppUser;
GRANT EXECUTE ON SCHEMA::app TO AppUser;
-- AppUser tự động có quyền trên mọi object trong schema app

-- Optional: Tạo schema riêng cho reporting (read-only)
CREATE SCHEMA rpt AUTHORIZATION dbo;
GRANT SELECT ON SCHEMA::rpt TO ReportUser;

Q17: Backup Strategy tốt nhất là gì?

A: 3-2-1 Rule cho database backup:

• 3 copies của data
• 2 different storage types
• 1 offsite/cloud copy

Lịch backup thực tế:

-- Daily Full Backup (11 PM)
BACKUP DATABASE SalesDB 
TO DISK = 'D:\Backups\SalesDB_Full_' + CONVERT(VARCHAR,GETDATE(),112) + '.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;

-- Every 6 hours: Differential Backup
BACKUP DATABASE SalesDB 
TO DISK = 'D:\Backups\SalesDB_Diff_' + CONVERT(VARCHAR,GETDATE(),112) + '_' + ...
WITH DIFFERENTIAL, COMPRESSION;

-- Every 15-30 minutes: Transaction Log Backup (Recovery Model = FULL)
BACKUP LOG SalesDB 
TO DISK = 'D:\Backups\SalesDB_Log_' + ... + '.trn'
WITH COMPRESSION;

-- Test restore regularly!
RESTORE DATABASE SalesDB_Test 
FROM DISK = '...' 
WITH NORECOVERY, MOVE ..., MOVE ...;
RESTORE LOG SalesDB_Test FROM DISK = '...' WITH RECOVERY;
DBCC CHECKDB(SalesDB_Test); -- Verify integrity

Q18: Làm thế nào để giám sát SQL Server Agent Jobs?

A:

-- Xem tất cả jobs và trạng thái
SELECT 
    j.name AS job_name,
    j.enabled,
    h.run_date,
    h.run_time,
    CASE h.run_status
        WHEN 0 THEN 'Failed'
        WHEN 1 THEN 'Succeeded'
        WHEN 2 THEN 'Retry'
        WHEN 3 THEN 'Cancelled'
    END AS last_run_status,
    h.run_duration,
    h.message
FROM msdb.dbo.sysjobs j
LEFT JOIN msdb.dbo.sysjobhistory h ON j.job_id = h.job_id
    AND h.instance_id = (
        SELECT MAX(instance_id) FROM msdb.dbo.sysjobhistory
        WHERE job_id = j.job_id AND step_id = 0
    )
ORDER BY j.name;

-- Xem jobs đang chạy hiện tại
EXEC msdb.dbo.sp_help_job @execution_status = 1; -- 1 = Running

Q19: Wait Statistics là gì? Dùng để làm gì?

A: Wait Statistics cho biết SQL Server đang “chờ” gì nhiều nhất — là điểm khởi đầu để tìm performance bottleneck.

-- Top wait types (kể từ khi SQL Server restart)
SELECT TOP 20
    wait_type,
    waiting_tasks_count,
    wait_time_ms / 1000.0 AS wait_time_seconds,
    max_wait_time_ms / 1000.0 AS max_wait_seconds,
    (wait_time_ms - signal_wait_time_ms) / 1000.0 AS resource_wait_seconds
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN (
    -- Lọc bỏ background waits không liên quan
    'SLEEP_TEMPDBSTARTUP', 'SLEEP_DBSTARTUP', 'LAZYWRITER_SLEEP',
    'LOGMGR_QUEUE', 'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH',
    'RESOURCE_QUEUE', 'SERVER_IDLE_CHECK', 'SLEEP_TASK',
    'SLEEP_SYSTEMTASK', 'SLEEP_TEMPDBSTARTUP', 'SNI_HTTP_ACCEPT',
    'SP_SERVER_DIAGNOSTICS_SLEEP', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR',
    'BROKER_TO_FLUSH', 'BROKER_TASK_STOP', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE',
    'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_TIMER_EVENT'
)
ORDER BY wait_time_ms DESC;

Giải thích common wait types:

Q20: Query Store là gì?

A: Query Store là tính năng built-in (SQL Server 2016+) tự động capture query plans và runtime stats. Giúp:

• Phát hiện plan regression (query đột ngột chậm vì plan thay đổi)
• Force execution plan cũ nếu plan mới tệ hơn
• Analyze top expensive queries

-- Bật Query Store
ALTER DATABASE MyDB SET QUERY_STORE = ON;
ALTER DATABASE MyDB SET QUERY_STORE (
    OPERATION_MODE = READ_WRITE,
    CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 30),
    DATA_FLUSH_INTERVAL_SECONDS = 900,
    MAX_STORAGE_SIZE_MB = 1024
);

-- Top queries theo CPU
SELECT TOP 10
    qsq.query_id,
    qsq.query_hash,
    SUM(qsrs.avg_cpu_time) AS total_avg_cpu,
    SUM(qsrs.avg_duration) AS total_avg_duration,
    SUM(qsrs.count_executions) AS total_executions,
    SUBSTRING(qsqt.query_sql_text, 1, 200) AS query_text
FROM sys.query_store_query qsq
JOIN sys.query_store_query_text qsqt ON qsq.query_text_id = qsqt.query_text_id
JOIN sys.query_store_plan qsp ON qsq.query_id = qsp.query_id
JOIN sys.query_store_runtime_stats qsrs ON qsp.plan_id = qsrs.plan_id
GROUP BY qsq.query_id, qsq.query_hash, qsqt.query_sql_text
ORDER BY total_avg_cpu DESC;

-- Force một plan cụ thể
EXEC sys.sp_query_store_force_plan @query_id = 42, @plan_id = 5;

🔴 Senior Level

Q21: Thiết kế Permission Model cho một ứng dụng multi-tenant như thế nào?

A: Có nhiều cách tiếp cận:

Approach 1: Schema-based separation

-- Mỗi tenant có schema riêng
CREATE SCHEMA Tenant1 AUTHORIZATION dbo;
CREATE SCHEMA Tenant2 AUTHORIZATION dbo;

-- App login per tenant
CREATE LOGIN Tenant1Login WITH PASSWORD = '...';
CREATE USER Tenant1User FOR LOGIN Tenant1Login;
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::Tenant1 TO Tenant1User;
DENY SELECT ON SCHEMA::Tenant2 TO Tenant1User; -- Tường minh deny cross-tenant

-- RLS thêm cho Defense in depth

Approach 2: RLS với TenantId column

-- Tất cả dữ liệu trong cùng schema, RLS filter theo tenant
ALTER TABLE Orders ADD TenantId INT NOT NULL;

CREATE FUNCTION dbo.fn_TenantFilter(@TenantId INT)
RETURNS TABLE WITH SCHEMABINDING AS RETURN
    SELECT 1 AS OK
    WHERE @TenantId = CONVERT(INT, SESSION_CONTEXT(N'TenantId'));

CREATE SECURITY POLICY TenantPolicy
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantId) ON dbo.Orders,
ADD BLOCK PREDICATE dbo.fn_TenantFilter(TenantId) ON dbo.Orders
WITH (STATE = ON);

Q22: Giải thích Cross-database Ownership Chaining.

A: Khi một stored procedure trong DB_A query sang DB_B, thông thường SQL Server kiểm tra permissions user trên DB_B objects. Với ownership chaining, nếu cùng owner (thường là dbo), SQL Server bỏ qua permission check trên DB_B.

-- DB_A.dbo.GetData procedure:
CREATE PROCEDURE DB_A.dbo.GetCrossDBData
AS
    SELECT * FROM DB_B.dbo.SensitiveTable; -- Cross-DB reference

-- Nếu DB_A.dbo và DB_B.dbo cùng owner:
-- User chỉ cần EXECUTE quyền trên procedure, không cần SELECT trên DB_B.dbo.SensitiveTable

-- Bật/tắt Cross-database ownership chaining:
ALTER DATABASE DB_B SET DB_CHAINING ON;  -- Cho phép
ALTER DATABASE DB_B SET DB_CHAINING OFF; -- Tắt (secure)

-- Server level:
sp_configure 'cross db ownership chaining', 1; -- Bật cho tất cả DB
RECONFIGURE;

Rủi ro: Có thể vô tình mở quyền truy cập cross-database không mong muốn. Best practice: Tắt và dùng explicit permissions hoặc EXECUTE AS.

Q23: Làm thế nào để điều tra và ngăn chặn SQL Injection trong stored procedures?

A:

Phát hiện:

-- Tìm dynamic SQL không dùng sp_executesql (risky patterns)
SELECT 
    OBJECT_NAME(object_id) AS object_name,
    OBJECT_SCHEMA_NAME(object_id) AS schema_name,
    definition
FROM sys.sql_modules
WHERE definition LIKE '%EXEC(%+%'  -- EXEC với string concatenation
   OR definition LIKE '%EXECUTE(%+%'
   OR (definition LIKE '%@%+%' AND definition LIKE '%EXEC%')
ORDER BY object_name;

Phòng chống:

-- BAD: 
DECLARE @sql VARCHAR(500) = 'SELECT * FROM ' + @TableName;
EXEC(@sql); -- Table name injection!

-- GOOD: Whitelist validation
IF @TableName NOT IN ('Orders', 'Products', 'Customers')
    THROW 50001, 'Invalid table name', 1;
DECLARE @sql NVARCHAR(500) = N'SELECT * FROM ' + QUOTENAME(@TableName);
EXEC sp_executesql @sql;

-- QUOTENAME: Wrap identifier in quotes, escape special chars
SELECT QUOTENAME('Orders; DROP TABLE Users--');
-- Trả về: [Orders; DROP TABLE Users--] → An toàn!

-- BEST: Tránh dynamic SQL hoàn toàn nếu có thể

Q24: Thiết kế Backup & Recovery Strategy cho production database 99.99% uptime?

A:

Recovery Point Objective (RPO): Mất tối đa bao nhiêu data? (e.g., 5 phút)
Recovery Time Objective (RTO): Restore trong bao lâu? (e.g., 1 giờ)

Strategy cho RPO=5min, RTO=1h:

-- 1. Cấu hình
ALTER DATABASE CriticalDB SET RECOVERY FULL;

-- 2. Lịch backup
-- Weekly: Full backup (Sunday 2AM)
-- Daily: Differential backup (Mon-Sat 2AM)  
-- Every 5 minutes: Transaction Log backup

-- 3. Always On Availability Groups (HADR)
-- Primary: Xử lý writes
-- Secondary (synchronous): Auto-failover trong vài giây (RTO << 1h)
-- Secondary (async, different DC): DR copy (địa lý khác nhau)

-- 4. Monitor backup
SELECT 
    bs.database_name,
    bs.type AS backup_type, -- D=Full, I=Differential, L=Log
    bs.backup_finish_date,
    DATEDIFF(MINUTE, bs.backup_start_date, bs.backup_finish_date) AS duration_minutes,
    bs.backup_size / 1024 / 1024 AS size_MB
FROM msdb.dbo.backupset bs
WHERE bs.database_name = 'CriticalDB'
ORDER BY bs.backup_finish_date DESC;

-- 5. Test restore quarterly (drills!)
-- Point-in-Time Recovery test:
RESTORE DATABASE CriticalDB_Test FROM DISK = '...' 
WITH NORECOVERY, REPLACE, MOVE ... ;
RESTORE LOG CriticalDB_Test FROM DISK = '...' 
WITH RECOVERY, STOPAT = '2026-04-01 15:30:00'; -- Restore đến thời điểm cụ thể

Q25: Giải thích Always On Availability Groups và cách nó cải thiện bảo mật/availability.

A:

Always On AG Architecture:
┌─────────────────────────────────────────────────────────┐
│  Primary Replica (DC1)          Secondary Replicas       │
│  ┌──────────────────┐    Sync   ┌──────────────────┐   │
│  │ SQL Server A     │ ─────────► │ SQL Server B     │   │
│  │ (Read-Write)     │           │ (Auto-Failover)   │   │
│  └──────────────────┘    Async  └──────────────────┘   │
│                          ──────► SQL Server C (DR site)  │
└─────────────────────────────────────────────────────────┘
                │
         Listener VIP (Virtual IP)
                │
     Application connect to Listener
     → Automatically routes to Primary

Bảo mật với AG:

-- Secondary readable replicas cho reporting (không load primary)
-- Configure readable secondary:
ALTER AVAILABILITY GROUP MyAG
MODIFY REPLICA ON 'SQL-B' 
WITH (SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY));

-- Backup từ secondary (giảm tải primary)
ALTER AVAILABILITY GROUP MyAG
MODIFY REPLICA ON 'SQL-B'
WITH (BACKUP_PRIORITY = 90); -- Ưu tiên backup từ secondary

Bảo mật SQL Server

Bảo mật SQL Server là lớp phòng thủ quan trọng trong kiến trúc ứng dụng. Một database không được bảo mật đúng cách có thể gây rò rỉ dữ liệu, vi phạm compliance, và thiệt hại nghiêm trọng cho doanh nghiệp. Chủ đề này bao gồm từ authentication cơ bản đến encryption nâng cao.

1. Authentication Modes

Windows Authentication (Integrated Security)

Xác thực qua Active Directory/Windows Security. SQL Server tin tưởng Windows đã xác thực user — không cần lưu password trong SQL Server.

Connection String: 
Server=MyServer;Database=MyDB;Integrated Security=True;
                                                     ↑
                              Dùng Windows credentials của process đang chạy

Ưu điểm:

• Không lưu password trong application config
• Hỗ trợ Kerberos/NTLM, MFA qua Azure AD
• Tự động expired/rotate theo Group Policy
• Single Sign-On với Windows ecosystem

SQL Server Authentication

Username/Password được lưu trong SQL Server master database.

Connection String:
Server=MyServer;Database=MyDB;User Id=AppLogin;Password=Str0ng!Pass;

Khi nào cần: Non-Windows clients (Linux, Mac, containers), cross-domain scenarios, legacy applications.

Rủi ro: Password có thể bị lộ trong config files, logs, memory dumps.

Mixed Mode (cả hai)

Hỗ trợ cả Windows và SQL Server Authentication. Bật khi:

• Có legacy apps dùng SQL Auth
• Cần sa account (đặc biệt khi setup ban đầu)

-- Kiểm tra authentication mode
SELECT
    CASE SERVERPROPERTY('IsIntegratedSecurityOnly')
        WHEN 1 THEN 'Windows Authentication Only'
        ELSE 'Mixed Mode (Windows + SQL)'
    END AS AuthenticationMode;

-- Đổi sang Mixed Mode (cần restart SQL Server)
-- GUI: SSMS → Server Properties → Security → Server Authentication
-- Registry: HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQLServer
-- LoginMode: 1 = Windows, 2 = Mixed

Tài khoản sa (System Administrator)

-- sa là built-in SQL Server login với sysadmin role
-- Best practices:
-- 1. Đổi tên sa (security through obscurity)
ALTER LOGIN sa WITH NAME = [SqlAdminAccount];

-- 2. Disable sa nếu không dùng
ALTER LOGIN sa DISABLE;

-- 3. Nếu cần enable, đặt strong password
ALTER LOGIN sa ENABLE;
ALTER LOGIN sa WITH PASSWORD = 'V3ry$tr0ng!RandomP@ss2024#';

2. Principals — Logins, Users, Roles

Hierarchy của Principals

SQL Server Instance Level:
├── Windows Login (DOMAIN\User, DOMAIN\Group)
├── SQL Server Login (username/password)
└── Server Roles (sysadmin, securityadmin, ...)

Database Level (per database):
├── Database User (mapped to Login)
├── Database Roles (db_owner, db_datareader, ...)
└── Application Roles (activate with password)

Tạo và Quản lý Logins

-- Tạo Windows Login
CREATE LOGIN [DOMAIN\HuyNgo] FROM WINDOWS WITH DEFAULT_DATABASE = MyDB;
CREATE LOGIN [DOMAIN\AppServiceGroup] FROM WINDOWS; -- AD Group

-- Tạo SQL Server Login
CREATE LOGIN AppLogin 
WITH PASSWORD = 'Str0ng!P@ssw0rd#2024',
     DEFAULT_DATABASE = AppDB,
     CHECK_EXPIRATION = ON,  -- Enforce password expiration  
     CHECK_POLICY = ON;      -- Enforce Windows password policy

-- Kiểm tra logins
SELECT 
    name, 
    type_desc, 
    is_disabled,
    create_date,
    password_hash IS NOT NULL AS has_password
FROM sys.server_principals
WHERE type IN ('S', 'U', 'G') -- S=SQL Login, U=Windows User, G=Windows Group
ORDER BY type, name;

Tạo và Quản lý Database Users

USE AppDB;

-- Tạo User từ Login
CREATE USER HuyNgo FOR LOGIN [DOMAIN\HuyNgo];
CREATE USER AppUser FOR LOGIN AppLogin;

-- Tạo User không có Login (contained database)
CREATE USER ContainedUser WITH PASSWORD = 'Pass!word';

-- Tạo User cho certificate/asymmetric key
CREATE USER CertUser FOR CERTIFICATE MyCert;

-- Kiểm tra users trong database
SELECT 
    u.name AS UserName,
    u.type_desc,
    l.name AS MappedLogin,
    u.default_schema_name
FROM sys.database_principals u
LEFT JOIN sys.server_principals l ON u.sid = l.sid
WHERE u.type NOT IN ('R') -- Loại bỏ roles
ORDER BY u.name;

-- Orphaned users (user không có Login tương ứng)
EXEC sp_change_users_login 'Report';
-- Fix orphaned users:
EXEC sp_change_users_login 'UPDATE_ONE', 'OrphanedUser', 'MatchingLogin';

3. Server Roles

Fixed Server Roles không thể sửa đổi (ngoại trừ user-defined server roles từ SQL 2012+):

-- Thêm Login vào Server Role
ALTER SERVER ROLE sysadmin ADD MEMBER [DOMAIN\DBAdmin];
ALTER SERVER ROLE dbcreator ADD MEMBER DevLogin;

-- Xem Server Role members
SELECT 
    r.name AS role_name,
    m.name AS member_name,
    m.type_desc
FROM sys.server_role_members srm
JOIN sys.server_principals r ON srm.role_principal_id = r.principal_id
JOIN sys.server_principals m ON srm.member_principal_id = m.principal_id
ORDER BY r.name, m.name;

-- User-defined Server Role (SQL 2012+)
CREATE SERVER ROLE ReadonlyDBA;
GRANT VIEW SERVER STATE TO ReadonlyDBA;
GRANT VIEW ANY DATABASE TO ReadonlyDBA;
ALTER SERVER ROLE ReadonlyDBA ADD MEMBER MonitorLogin;

4. Database Roles

Fixed Database Roles

-- Thêm User vào Database Role
ALTER ROLE db_datareader ADD MEMBER AppUser;
ALTER ROLE db_datawriter ADD MEMBER AppUser;

-- Tạo Custom Database Role (Principle of Least Privilege)
CREATE ROLE OrderManagers;
GRANT SELECT, INSERT, UPDATE ON dbo.Orders TO OrderManagers;
GRANT SELECT, INSERT ON dbo.OrderDetails TO OrderManagers;
GRANT EXECUTE ON dbo.CreateOrder TO OrderManagers;
GRANT EXECUTE ON dbo.UpdateOrderStatus TO OrderManagers;

ALTER ROLE OrderManagers ADD MEMBER UserA;
ALTER ROLE OrderManagers ADD MEMBER UserB;

-- Xem Role members
SELECT 
    r.name AS role_name,
    m.name AS member_name
FROM sys.database_role_members drm
JOIN sys.database_principals r ON drm.role_principal_id = r.principal_id
JOIN sys.database_principals m ON drm.member_principal_id = m.principal_id
ORDER BY r.name, m.name;

5. Object Permissions — GRANT, DENY, REVOKE

Cú pháp cơ bản

-- GRANT permissions
GRANT SELECT ON dbo.Products TO AppUser;
GRANT SELECT, INSERT, UPDATE, DELETE ON dbo.Orders TO AppUser;
GRANT EXECUTE ON dbo.GetOrderDetails TO AppUser;
GRANT ALTER ON SCHEMA::dbo TO PowerUser;

-- GRANT WITH GRANT OPTION (cho phép user gán quyền cho người khác)
GRANT SELECT ON dbo.Reports TO ManagerUser WITH GRANT OPTION;

-- DENY (override mọi GRANT)
DENY DELETE ON dbo.Orders TO AppUser;         -- Không thể DELETE
DENY SELECT ON dbo.SalaryTable TO AllStaff;   -- Không ai đọc được

-- REVOKE (xóa GRANT hoặc DENY)
REVOKE SELECT ON dbo.Products FROM AppUser;
REVOKE DELETE ON dbo.Orders FROM AppUser; -- Xóa DENY, nhưng vẫn không có GRANT

Kiểm tra Permissions

-- Permissions của một user
SELECT 
    dp.permission_name,
    dp.state_desc,     -- GRANT, DENY, REVOKE
    dp.class_desc,
    OBJECT_NAME(dp.major_id) AS object_name,
    sp.name AS principal_name
FROM sys.database_permissions dp
JOIN sys.database_principals sp ON dp.grantee_principal_id = sp.principal_id
WHERE sp.name = 'AppUser'
ORDER BY dp.class_desc, dp.permission_name;

-- Effective permissions của current user
SELECT * FROM fn_my_permissions(NULL, 'DATABASE');
SELECT * FROM fn_my_permissions('dbo.Orders', 'OBJECT');

-- HAS_PERMS_BY_NAME để kiểm tra trong code
IF HAS_PERMS_BY_NAME('dbo.Orders', 'OBJECT', 'SELECT') = 1
    PRINT 'Can SELECT from Orders';

6. Schema-based Permissions

Schema là namespace chứa objects. GRANT quyền trên schema = tự động có quyền trên tất cả objects hiện tại và tương lai trong schema đó.

-- Tạo schemas theo nhóm chức năng
CREATE SCHEMA Sales AUTHORIZATION dbo;
CREATE SCHEMA HR AUTHORIZATION dbo;
CREATE SCHEMA Finance AUTHORIZATION dbo;
CREATE SCHEMA Reporting AUTHORIZATION dbo;

-- Objects trong schemas
CREATE TABLE Sales.Orders (...);
CREATE TABLE Sales.Customers (...);
CREATE TABLE HR.Employees (...);
CREATE TABLE Finance.Payroll (...);

-- Permission model đơn giản, dễ quản lý:
-- App login chỉ cần Sales schema
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::Sales TO SalesAppUser;
GRANT EXECUTE ON SCHEMA::Sales TO SalesAppUser;

-- Report login chỉ đọc Reporting schema
GRANT SELECT ON SCHEMA::Reporting TO ReportUser;

-- HR admin
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::HR TO HRAppUser;
DENY SELECT ON HR.Employees TO FinanceUser; -- Tường minh deny

-- Xem tất cả schemas và owners
SELECT name, principal_id, SCHEMA_NAME(schema_id) 
FROM sys.schemas
ORDER BY name;

7. Row-Level Security (RLS)

RLS cho phép kiểm soát access ở cấp row dựa trên security predicate function.

Filter Predicate (Chỉ thấy rows được phép)

-- Ví dụ: Sales rep chỉ thấy orders được assign cho họ
CREATE TABLE Sales.Orders (
    OrderId INT PRIMARY KEY,
    CustomerId INT,
    SalesRepLogin NVARCHAR(100),
    Amount DECIMAL(10,2),
    OrderDate DATE
);

-- Security predicate function
CREATE FUNCTION Security.fn_OrderAccess(@SalesRepLogin NVARCHAR(100))
RETURNS TABLE
WITH SCHEMABINDING
AS RETURN
    SELECT 1 AS allowed
    WHERE 
        @SalesRepLogin = USER_NAME()      -- Chính user đó
        OR IS_ROLEMEMBER('db_owner') = 1  -- Hoặc admin
        OR IS_ROLEMEMBER('SalesManager') = 1; -- Hoặc manager

-- Tạo Security Policy
CREATE SECURITY POLICY OrderFilterPolicy
ADD FILTER PREDICATE Security.fn_OrderAccess(SalesRepLogin) 
    ON Sales.Orders
WITH (STATE = ON, SCHEMABINDING = ON);

-- Test:
EXECUTE AS USER = 'rep_nguyen';
SELECT * FROM Sales.Orders; -- Chỉ thấy orders của rep_nguyen
REVERT;

Block Predicate (Ngăn INSERT/UPDATE vi phạm policy)

-- Block predicate: Ngăn insert row với SalesRepLogin khác với current user
CREATE SECURITY POLICY OrderFilterPolicy
ADD FILTER PREDICATE Security.fn_OrderAccess(SalesRepLogin) ON Sales.Orders,
ADD BLOCK PREDICATE Security.fn_OrderAccess(SalesRepLogin) ON Sales.Orders 
    AFTER INSERT, -- Ngăn insert rows không thuộc về họ
    AFTER UPDATE  -- Ngăn update để chuyển ownership
WITH (STATE = ON);

-- Không cần modify queries trong application!
-- Tất cả SELECT/INSERT/UPDATE tự động được filter

RLS với Session Context

-- Dùng Session Context cho multi-tenant (tốt hơn USER_NAME() khi app dùng connection pool)
CREATE FUNCTION dbo.fn_TenantFilter(@TenantId INT)
RETURNS TABLE WITH SCHEMABINDING AS RETURN
    SELECT 1 AS OK
    WHERE @TenantId = CONVERT(INT, SESSION_CONTEXT(N'TenantId'))
        OR IS_MEMBER('db_owner') = 1;

CREATE SECURITY POLICY TenantIsolationPolicy
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantId) ON dbo.Orders,
ADD BLOCK PREDICATE dbo.fn_TenantFilter(TenantId) ON dbo.Orders
WITH (STATE = ON);

-- Application set context trước khi query (sau login):
EXEC sys.sp_set_session_context 
    @key = N'TenantId', 
    @value = 42,
    @read_only = 1; -- Ngăn application tự thay đổi TenantId!

8. Dynamic Data Masking (DDM)

DDM che giấu dữ liệu nhạy cảm khi query — không thay đổi dữ liệu thực trong storage.

Masking Functions

CREATE TABLE dbo.CustomerPII (
    CustomerId    INT PRIMARY KEY,
    FullName      NVARCHAR(100), -- Không mask
    
    -- Email: hiXX@XXXX.com
    Email         NVARCHAR(200) MASKED WITH (FUNCTION = 'email()'),
    
    -- Che giấu hoàn toàn: xxxx
    Password      NVARCHAR(100) MASKED WITH (FUNCTION = 'default()'),
    
    -- Chỉ hiện 2 ký tự đầu và 2 cuối: "Hu...go"
    NickName      NVARCHAR(50)  MASKED WITH (FUNCTION = 'partial(2,"...",2)'),
    
    -- Số điện thoại: XXX-XXX-1234
    Phone         NVARCHAR(20)  MASKED WITH (FUNCTION = 'partial(0,"XXX-XXX-",4)'),
    
    -- Credit card: XXXX-XXXX-XXXX-5678
    CreditCard    NVARCHAR(20)  MASKED WITH (FUNCTION = 'partial(0,"XXXX-XXXX-XXXX-",4)'),
    
    -- Random number trong khoảng
    FakeIncome    DECIMAL(10,2) MASKED WITH (FUNCTION = 'random(1000, 9999)'),
    
    -- Date: 01.01.1900
    BirthDate     DATE          MASKED WITH (FUNCTION = 'default()')
);

-- Thêm mask vào cột đã có:
ALTER TABLE dbo.CustomerPII
ALTER COLUMN SSN NVARCHAR(11) MASKED WITH (FUNCTION = 'partial(0,"XXX-XX-",4)');

-- Bỏ mask:
ALTER TABLE dbo.CustomerPII ALTER COLUMN Email DROP MASKED;

-- UNMASK permission:
GRANT UNMASK TO PowerUserRole;           -- Toàn bộ database
GRANT UNMASK ON dbo.CustomerPII TO AdminUser; -- Chỉ table đó

-- Test:
EXECUTE AS USER = 'NormalUser';
SELECT CustomerId, FullName, Email, Phone, CreditCard FROM dbo.CustomerPII;
-- Email: aXX@XXXX.com, Phone: XXX-XXX-5678, CreditCard: XXXX-XXXX-XXXX-9012
REVERT;

EXECUTE AS USER = 'AdminUser';
SELECT CustomerId, FullName, Email, Phone, CreditCard FROM dbo.CustomerPII;
-- Thấy dữ liệu thật
REVERT;

9. Always Encrypted

Always Encrypted đảm bảo chỉ client application mới có thể đọc dữ liệu nhạy cảm — SQL Server, DBA, Cloud admin đều không đọc được. Encryption/Decryption xảy ra hoàn toàn ở phía client.

Kiến trúc

Client Application
  ├── Column Master Key (CMK): Lưu trong Key Vault / Windows Cert Store
  └── Column Encryption Key (CEK): Được encrypt bởi CMK, lưu trong SQL Server

SQL Server
  └── Chỉ thấy ciphertext (bytes) — không có CMK, không decrypt được

Setup Always Encrypted

-- Step 1: Tạo Column Master Key metadata (key thực lưu ở Key Vault/cert store)
CREATE COLUMN MASTER KEY MyCMK
WITH (
    KEY_STORE_PROVIDER_NAME = 'AZURE_KEY_VAULT',
    KEY_PATH = 'https://mykeyvault.vault.azure.net/keys/MyCMK/abc123'
);
-- Hoặc Windows Certificate Store:
CREATE COLUMN MASTER KEY MyCMK
WITH (
    KEY_STORE_PROVIDER_NAME = 'MSSQL_CERTIFICATE_STORE',
    KEY_PATH = 'LocalMachine/My/ABC123DEF456...'
);

-- Step 2: Tạo Column Encryption Key (encrypted bằng CMK)
CREATE COLUMN ENCRYPTION KEY MyCEK
WITH VALUES (
    COLUMN_MASTER_KEY = MyCMK,
    ALGORITHM = 'RSA_OAEP',
    ENCRYPTED_VALUE = 0x01234567... -- Giá trị encrypted
);

-- Step 3: Tạo table với encrypted columns
CREATE TABLE dbo.Patients (
    PatientId    INT PRIMARY KEY,
    Name         NVARCHAR(100), -- Không encrypt
    SSN          CHAR(11) ENCRYPTED WITH (
        COLUMN_ENCRYPTION_KEY = MyCEK,
        ENCRYPTION_TYPE = Deterministic, -- Cho phép equality search
        ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
    ),
    Diagnosis    NVARCHAR(500) ENCRYPTED WITH (
        COLUMN_ENCRYPTION_KEY = MyCEK,
        ENCRYPTION_TYPE = Randomized, -- Bảo mật hơn, không search được
        ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256'
    )
);

Deterministic vs Randomized Encryption

10. Transparent Data Encryption (TDE)

TDE mã hóa toàn bộ database files (data, log, backup) ở tầng storage. Hoàn toàn transparent với application.

Setup TDE

-- Step 1: Tạo Database Master Key trong master database
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Str0ng#MasterKey!Pass';

-- Step 2: Tạo Certificate để bảo vệ TDE key
CREATE CERTIFICATE TDECert 
WITH SUBJECT = 'TDE Certificate for AppDB',
     EXPIRY_DATE = '2099-12-31';

-- ⚠️ QUAN TRỌNG: Backup certificate ngay! Nếu mất certificate, mất dữ liệu!
BACKUP CERTIFICATE TDECert 
TO FILE = 'C:\Backups\TDECert.cer'
WITH PRIVATE KEY (
    FILE = 'C:\Backups\TDECert_Key.pvk',
    ENCRYPTION BY PASSWORD = 'BackupKeyPassword!2024'
);

-- Step 3: Tạo Database Encryption Key trong database cần encrypt
USE AppDB;
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TDECert;

-- Step 4: Bật TDE
ALTER DATABASE AppDB SET ENCRYPTION ON;

-- Monitor tiến độ encryption
SELECT 
    DB_NAME(database_id) AS db_name,
    encryption_state,
    CASE encryption_state
        WHEN 0 THEN 'No encryption'
        WHEN 1 THEN 'Unencrypted'
        WHEN 2 THEN 'Encryption in progress'
        WHEN 3 THEN 'Encrypted'
        WHEN 4 THEN 'Key change in progress'
        WHEN 5 THEN 'Decryption in progress'
        WHEN 6 THEN 'Protection change in progress'
    END AS encryption_state_desc,
    percent_complete,
    encryptor_thumbprint
FROM sys.dm_database_encryption_keys;

Khôi phục TDE Database sang server khác

-- Trên server đích: Phải restore certificate TRƯỚC khi restore database
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'NewServerMasterKeyPass';

CREATE CERTIFICATE TDECert
FROM FILE = 'C:\Backups\TDECert.cer'
WITH PRIVATE KEY (
    FILE = 'C:\Backups\TDECert_Key.pvk',
    DECRYPTION BY PASSWORD = 'BackupKeyPassword!2024'
);

-- Bây giờ mới có thể restore database
RESTORE DATABASE AppDB FROM DISK = '...';

11. SQL Server Audit

Audit tracks các hành động trong SQL Server và ghi vào file, Windows Event Log, hoặc Application Log.

Server Audit và Audit Specification

-- Bước 1: Tạo Server Audit (cấu hình destination)
CREATE SERVER AUDIT ProductionAudit
TO FILE (
    FILEPATH = 'D:\SQLAudit\',
    MAXSIZE = 100 MB,
    MAX_FILES = 50,             -- Giữ 50 files
    RESERVE_DISK_SPACE = OFF
)
WITH (
    QUEUE_DELAY = 1000,         -- ms, 0 = synchronous
    ON_FAILURE = CONTINUE,      -- CONTINUE hoặc SHUTDOWN hoặc FAIL_OPERATION
    AUDIT_GUID = NEWID()
);

ALTER SERVER AUDIT ProductionAudit WITH (STATE = ON);

-- Bước 2a: Server Audit Specification (server-level events)
CREATE SERVER AUDIT SPECIFICATION ServerSecurityAudit
FOR SERVER AUDIT ProductionAudit
    ADD (FAILED_LOGIN_GROUP),               -- Đăng nhập thất bại
    ADD (SUCCESSFUL_LOGIN_GROUP),           -- Đăng nhập thành công
    ADD (LOGOUT_GROUP),                     -- Đăng xuất
    ADD (LOGIN_CHANGE_PASSWORD_GROUP),      -- Đổi password
    ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP),  -- Thay đổi server role
    ADD (CREATE_LOGIN_GROUP),               -- Tạo login
    ADD (ALTER_LOGIN_GROUP),                -- Sửa login
    ADD (DROP_LOGIN_GROUP)                  -- Xóa login
WITH (STATE = ON);

-- Bước 2b: Database Audit Specification (database-level events)
USE SensitiveDatabase;
CREATE DATABASE AUDIT SPECIFICATION DataChangeAudit
FOR SERVER AUDIT ProductionAudit
    ADD (SELECT ON dbo.Payroll BY public),         -- Ai đọc Payroll
    ADD (INSERT, UPDATE, DELETE ON dbo.Orders BY public), -- Thay đổi Orders
    ADD (EXECUTE ON SCHEMA::dbo BY public),        -- Gọi stored procedures
    ADD (DATABASE_OBJECT_CHANGE_GROUP),            -- DDL changes
    ADD (SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP)    -- Permission changes
WITH (STATE = ON);

Xem Audit Logs

-- Đọc từ file
SELECT TOP 100
    event_time AT TIME ZONE 'SE Asia Standard Time' AS event_time_local,
    action_id,
    succeeded,
    session_server_principal_name AS login_name,
    server_instance_name,
    database_name,
    schema_name,
    object_name,
    statement,
    additional_information
FROM sys.fn_get_audit_file(
    'D:\SQLAudit\ProductionAudit_*.sqlaudit',
    DEFAULT,
    DEFAULT
)
WHERE action_id IN ('SL', 'IN', 'UP', 'DL') -- SELECT, INSERT, UPDATE, DELETE
ORDER BY event_time DESC;

-- Filter theo user
SELECT *
FROM sys.fn_get_audit_file('D:\SQLAudit\*.sqlaudit', DEFAULT, DEFAULT)
WHERE session_server_principal_name = 'SuspiciousUser'
ORDER BY event_time;

12. EXECUTE AS — Impersonation

-- Impersonation tạm thời trong session
EXECUTE AS USER = 'LimitedUser';
    SELECT * FROM dbo.Orders; -- Thực thi với quyền LimitedUser
    -- Nếu LimitedUser không có quyền → Error
REVERT; -- Quay lại context gốc (bắt buộc!)

-- EXECUTE AS trong Stored Procedure
CREATE PROCEDURE dbo.GetRestrictedData
WITH EXECUTE AS OWNER  -- Chạy dưới ngữ cảnh của owner (thường là dbo)
AS
BEGIN
    -- Caller không cần quyền SELECT trực tiếp trên bảng này
    SELECT SensitiveColumn FROM dbo.ProtectedTable;
END;
-- Cấp cho user quyền EXECUTE, không cần SELECT:
GRANT EXECUTE ON dbo.GetRestrictedData TO ReportUser;

-- EXECUTE AS SELF: chạy dưới context của người tạo procedure
-- EXECUTE AS USER = 'specific_user': context cố định
-- EXECUTE AS CALLER: context của người gọi (default)

-- Kiểm tra context hiện tại:
SELECT ORIGINAL_LOGIN() AS original_login,
       USER_NAME() AS current_context,
       SYSTEM_USER AS system_login;

13. SQL Injection Prevention

Các hình thức SQL Injection

-- 1. Classic string injection
-- Input: ' OR '1'='1
-- Query: WHERE Password = '' OR '1'='1' -- Luôn đúng!

-- 2. UNION-based injection
-- Input: ' UNION SELECT username, password FROM sys.sql_logins --
-- Lấy thông tin hệ thống!

-- 3. Stacked queries
-- Input: '; DROP TABLE Users; --
-- Xóa toàn bộ table!

-- 4. Time-based blind injection
-- Input: ' IF (1=1) WAITFOR DELAY '0:0:5' --
-- Detect database structure qua timing

Phòng chống

-- ✅ CÁCH 1: Parameterized queries (bắt buộc!)
-- Application code dùng SqlParameters (C#):
-- cmd.Parameters.AddWithValue("@Name", userInput);

-- ✅ CÁCH 2: sp_executesql với parameters
DECLARE @sql NVARCHAR(500); 
DECLARE @userName NVARCHAR(100) = ''; -- Từ user input

SET @sql = N'SELECT * FROM Users WHERE UserName = @name';
EXEC sp_executesql @sql, N'@name NVARCHAR(100)', @name = @userName;
-- @userName không được interpret là SQL, dù chứa SQL code

-- ✅ CÁCH 3: Stored Procedures
CREATE PROCEDURE dbo.GetUser @UserName NVARCHAR(100)
AS
    SELECT UserId, UserName, Email -- Chỉ expose cần thiết
    FROM dbo.Users
    WHERE UserName = @UserName; -- Safe

-- ✅ CÁCH 4: QUOTENAME cho dynamic object names
DECLARE @TableName NVARCHAR(100) = 'Orders'; -- Từ whitelist
IF @TableName NOT IN ('Orders', 'Products', 'Customers')
    THROW 50001, 'Invalid table', 1;
    
DECLARE @sql NVARCHAR(500) = N'SELECT * FROM ' + QUOTENAME(@TableName);
EXEC sp_executesql @sql;

-- ✅ CÁCH 5: Principle of Least Privilege
-- Application login chỉ có SELECT, INSERT, UPDATE — không DROP, không TRUNCATE
-- Không dùng sa hoặc sysadmin cho application

-- ❌ NEVER: String concatenation với user input
DECLARE @badSql NVARCHAR(500) = 
    'SELECT * FROM Users WHERE Name = ''' + @userInput + ''''; -- VULNERABLE!
EXEC(@badSql);

14. Best Practices Bảo mật Tổng hợp

Checklist Bảo mật Production

-- 1. Vô hiệu hóa tài khoản không dùng
ALTER LOGIN sa DISABLE;
ALTER LOGIN GuestLogin DISABLE;

-- 2. Kiểm tra guest user trong databases
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1; -- Phải là ít
-- Tắt TRUSTWORTHY nếu không cần:
ALTER DATABASE MyDB SET TRUSTWORTHY OFF;

-- 3. Kiểm tra ai có sysadmin
SELECT p.name, p.type_desc
FROM sys.server_principals p
JOIN sys.server_role_members rm ON p.principal_id = rm.member_principal_id
JOIN sys.server_principals r ON rm.role_principal_id = r.principal_id
WHERE r.name = 'sysadmin';

-- 4. Kiểm tra SQL Logins (nên minimize)
SELECT name, is_disabled FROM sys.sql_logins ORDER BY name;

-- 5. Permissions report
SELECT
    dp.state_desc AS PermissionState,
    dp.permission_name,
    dp.class_desc,
    COALESCE(OBJECT_NAME(dp.major_id), 
             SCHEMA_NAME(dp.major_id), 
             DB_NAME(dp.major_id)) AS SecurableName,
    pr.name AS GranteeName,
    pr.type_desc AS GranteeType
FROM sys.database_permissions dp
JOIN sys.database_principals pr ON dp.grantee_principal_id = pr.principal_id
WHERE dp.state_desc IN ('GRANT', 'DENY')
ORDER BY pr.name, dp.permission_name;

Summary Best Practices