Thư Viện Câu Hỏi Phỏng Vấn

Phân tích cơ chế

So sánh chi tiết

Nguyên nhân gây Deadlock

Deadlock xảy ra khi hai hoặc nhiều tiến trình cùng giữ khóa (lock) trên các tài nguyên mà tiến trình kia đang cần, dẫn đến trạng thái chờ đợi vô hạn.

Trong phát triển dự án với T-SQL, việc tối ưu hóa và quản lý tốt User Defined Functions là vô cùng quan trọng để đảm bảo tính ổn định và hiệu năng của hệ thống. Dưới đây là các khía cạnh kỹ thuật cốt lõi:

Trong phát triển dự án với T-SQL, việc tối ưu hóa và quản lý tốt Variables declaration là vô cùng quan trọng để đảm bảo tính ổn định và hiệu năng của hệ thống. Dưới đây là các khía cạnh kỹ thuật cốt lõi:

1. Bản chất cơ chế hoạt động

• Index Seek: Query Optimizer sử dụng B-Tree Index để tìm kiếm trực tiếp các trang dữ liệu (data pages) chứa giá trị thỏa mãn điều kiện WHERE. Thao tác này cực kỳ hiệu quả, chỉ đọc một số lượng trang dữ liệu tối thiểu.
• Index Scan (hoặc Table Scan): Query Optimizer phải duyệt qua toàn bộ các trang dữ liệu của bảng hoặc index từ đầu đến cuối để tìm kiếm dữ liệu. Chi phí I/O và CPU tăng tuyến tính theo kích thước bảng.

2. Nguyên nhân dẫn đến Table Scan / Index Scan

• Thiếu Index phù hợp cho mệnh đề WHERE hoặc JOIN.
• Sử dụng hàm hoặc toán tử chuyển đổi kiểu dữ liệu lên cột được đánh Index (ví dụ: WHERE YEAR(OrderDate) = 2023 làm mất tác dụng của Index trên cột OrderDate).
• Cột đầu tiên trong Composite Index không được sử dụng trong điều kiện tìm kiếm (vi phạm quy tắc Left-most prefix).
• Bảng có kích thước quá nhỏ (SQL Server đánh giá Scan nhanh hơn Seek).

3. Phương pháp tối ưu hóa

• Sử dụng SARGable Predicates: Viết điều kiện truy vấn có thể tận dụng Index. Ví dụ thay vì WHERE YEAR(OrderDate) = 2023, hãy dùng WHERE OrderDate >= '2023-01-01' AND OrderDate < '2024-01-01'.
• Tạo Covering Index: Đưa các cột cần SELECT vào mệnh đề INCLUDE của Index để tránh việc Bookmark Lookup.
• Cập nhật Statistics: Chạy UPDATE STATISTICS định kỳ để Query Optimizer đưa ra Execution Plan chính xác.

4. Lưu ý thực chiến Enterprise

Đối với các hệ thống OLTP, việc để xảy ra Table Scan trên các bảng hàng triệu dòng trong các transaction thường xuyên sẽ gây nghẽn cổ chai CPU và Disk I/O, dẫn đến lock tranh chấp diện rộng. Luôn kiểm tra Execution Plan thực tế trên môi trường Staging với dữ liệu tương đương Production.

1. Định nghĩa Deadlock

Deadlock xảy ra khi hai hoặc nhiều Task (Process) giữ độc quyền khóa trên các tài nguyên khác nhau, đồng thời lại yêu cầu khóa trên tài nguyên mà Process kia đang giữ, khiến cả hai bị kẹt vĩnh viễn không thể tiếp tục cho đến khi SQL Server phát hiện và hủy (kill) một Process làm nạn nhân (Deadlock Victim).

1. Phân biệt Stored Procedure và UDF

• Stored Procedure (SP):
  • Có thể thực hiện các thao tác thay đổi dữ liệu (DML: INSERT, UPDATE, DELETE) và quản trị hệ thống (DDL).
  • Hỗ trợ trả về nhiều tập dữ liệu (result sets), tham số đầu ra (OUTPUT parameters) và mã trạng thái trả về (RETURN value).
  • Không thể được gọi trực tiếp bên trong một câu lệnh SELECT.
• User-Defined Function (UDF):
  • Scalar Function và Inline Table-Valued Function chỉ thực hiện đọc dữ liệu (không được chứa các lệnh thay đổi dữ liệu hoặc gọi stored procedure).
  • Có thể được lồng trực tiếp vào trong các câu lệnh SELECT, WHERE, JOIN.

2. Ảnh hưởng kiến trúc khi sử dụng sai

• Lạm dụng Scalar UDF: Scalar UDF thực thi một cách tuần tự cho từng dòng dữ liệu trong tập kết quả (Row-by-row execution), gây suy giảm hiệu năng nghiêm trọng (Performance bottleneck) trên các bảng lớn. Từ SQL Server 2019, tính năng Scalar UDF Inlining đã được giới thiệu để khắc phục phần nào, nhưng bản chất kiến trúc vẫn nên hạn chế.
• Sử dụng sai Multi-Statement Table-Valued Functions (MSTVF): MSTVF khai báo một biến bảng bên trong và trả về nó. SQL Server thường ước lượng số dòng sai lệch nghiêm trọng (thường cố định là 1 hoặc 100 dòng) đối với MSTVF, dẫn đến Execution Plan kém tối ưu.

3. Lựa chọn tối ưu

• Sử dụng Stored Procedure cho các business logic phức tạp, xử lý dữ liệu hàng loạt (Batch processing), tương tác DML.
• Sử dụng Inline Table-Valued Function (ITVF) thay cho Scalar UDF và MSTVF khi cần tái sử dụng logic truy vấn có trả về bảng, vì ITVF được biên dịch nội tuyến (inlined) vào câu lệnh gọi chính giống như một View có tham số.

4. Lưu ý thực chiến Enterprise

Tránh tuyệt đối việc viết Business Logic phức tạp nằm sâu bên trong các Scalar UDF được gọi từ câu lệnh SELECT của các báo cáo lớn.

1. Clustered Index

• Cơ chế: Sắp xếp và lưu trữ các dòng dữ liệu vật lý trong bảng dựa trên khóa của Clustered Index. Mỗi bảng chỉ có duy nhất một Clustered Index.
• Ảnh hưởng SELECT: Cực kỳ tối ưu khi truy vấn theo khoảng giá trị (Range queries) vì dữ liệu nằm liền kề nhau trên các trang đĩa.
• Ảnh hưởng DML: Khi thực hiện INSERT hoặc UPDATE khóa chính, nếu trang dữ liệu bị đầy (Page Split), SQL Server phải phân tách trang dữ liệu, di chuyển một nửa dữ liệu sang trang mới, gây tiêu tốn tài nguyên I/O và tạo phân mảnh (Fragmentation).

2. Non-Non-Clustered Index

• Cơ chế: Cấu trúc B-Tree riêng biệt, chứa các giá trị khóa của Index và con trỏ (Row Locator) trỏ về trang dữ liệu thực tế (nếu bảng không có Clustered Index) hoặc trỏ về khóa Clustered Index (nếu bảng có Clustered Index).
• Ảnh hưởng SELECT: Giúp tìm kiếm nhanh chóng, nhưng nếu câu lệnh SELECT yêu cầu các cột không có trong Index, hệ thống phải thực hiện thêm bước Key Lookup / RID Lookup để lấy dữ liệu từ bảng gốc.
• Ảnh hưởng DML: Mỗi khi có thao tác INSERT, UPDATE, DELETE trên bảng, mọi Non-Clustered Index liên quan cũng phải được cập nhật đồng thời. Quá trình này làm tăng chi phí ghi dữ liệu (Write Amplification).

3. Chiến lược quản trị trong Enterprise

• Không đánh Index tràn lan. Chỉ đánh Index cho các cột thường xuyên xuất hiện trong mệnh đề WHERE, JOIN, ORDER BY và GROUP BY.
• Thường xuyên theo dõi mức độ phân mảnh (Fragmentation) và thực hiện Rebuild hoặc Reorganize Index định kỳ để duy trì hiệu suất.

4. Lưu ý thực chiến Enterprise

Ưu tiên chọn khóa Clustered Index có tính chất tăng tuần tự (Sequential),ẹp hẹp (như INT hoặc BIGINT IDENTITY) thay vì sử dụng GUID (NEWID()) để tránh tình trạng phân mảnh trang dữ liệu nghiêm trọng do chèn ngẫu nhiên.

1. Cơ chế hoạt động của Table Partitioning

• Partition Function: Định nghĩa cách chia nhỏ dữ liệu thành các khoảng (ranges) dựa trên giá trị của một cột cụ thể (Partition Key, ví dụ: ngày tháng hoặc mã chi nhánh).
• Partition Scheme: Ánh xạ các khoảng dữ liệu được định nghĩa bởi Partition Function vào các Filegroups khác nhau trên hệ thống lưu trữ.
• Về mặt logic, bảng vẫn xuất hiện như một đối tượng duy nhất, nhưng về mặt vật lý, dữ liệu được chia thành nhiều phân vùng độc lập.

2. Lợi ích kiến trúc trong hệ thống VLDB (Very Large DataBase)

• Tối ưu hóa hiệu năng truy vấn (Partition Elimination): Khi câu lệnh truy vấn có chứa điều kiện lọc trên cột Partition Key, Query Optimizer thông minh chỉ quét qua các phân vùng (partitions) liên quan thay vì quét toàn bộ bảng.
• Quản lý dữ liệu lịch sử hiệu quả (Sliding Window Scenario): Cho phép thực hiện thao tác xóa dữ liệu cũ hoặc thêm dữ liệu mới trong thời gian chớp mắt thông qua lệnh SWITCH PARTITION mà không cần chạy lệnh DELETE tốn kém tài nguyên và gây khóa bảng.
• Bảo trì linh hoạt: Có thể thực hiện Rebuild Index trên từng phân vùng riêng biệt thay vì phải chạy trên toàn bộ bảng lớn.

3. Điều kiện tiên quyết và hạn chế

• Bảng phải có kích thước đủ lớn để việc phân vùng mang lại hiệu quả vượt trội hơn chi phí quản lý.
• Khóa Clustered Index của bảng bắt buộc phải chứa cột Partition Key.

4. Lưu ý thực chiến Enterprise

Partitioning là công cụ đắc lực cho các hệ thống Data Warehouse hoặc hệ thống Log giao dịch lớn. Tuy nhiên, việc thiết kế sai Partition Key có thể làm giảm hiệu năng hệ thống nếu các truy vấn thường xuyên quét chéo qua nhiều phân vùng khác nhau.

1. Bản chất của Parameter Sniffing

1. Các vấn đề về đồng thời (Concurrency Problems)

1. Định nghĩa và Cơ chế thực thi

1. Vấn đề của Cursor truyền thống

1. Khái niệm và phương pháp thu thập

Execution Plan (Kế hoạch thực thi) là lộ trình mà SQL Server Query Optimizer chọn để thực thi câu lệnh T-SQL. Để phân tích, lập trình viên có thể sử dụng: