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

Trong phát triển dự án với SQL, việc tối ưu hóa và quản lý tốt Joins (Inner, Left, Right) 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 SQL, việc tối ưu hóa và quản lý tốt Normalization forms 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:

Bản chất của Cardinality

Cardinality là số lượng các giá trị duy nhất trong một cột. Cột có độ chọn lọc thấp (Low Cardinality) là cột có ít giá trị duy nhất (ví dụ: cột giới tính, trạng thái đơn hàng).

Các cấp độ cô lập

Việc sử dụng SELECT * gây ra nhiều vấn đề nghiêm trọng trong hệ thống lớn:

Sự khác biệt cốt lõi nằm ở thời điểm thực thi trong vòng đời của một câu truy vấn:

Việc lạm dụng kiểu dữ liệu có độ dài không xác định (Variable-length) gây ra các hệ quả sau:

Sự khác biệt chính nằm ở cách xử lý các bản ghi trùng lặp:

Giá trị NULL trong SQL đại diện cho trạng thái 'không xác định' (Unknown), không phải là số 0 hay chuỗi rỗng. Điều này dẫn đến các cạm bẫy logic:

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

• INNER JOIN: Chỉ trả về các bản ghi có sự khớp nhau (matching rows) ở cả hai bảng dựa trên điều kiện kết nối (ON clause). Nếu không có bản ghi tương ứng ở bảng bên phải hoặc bên trái, dữ liệu đó sẽ bị loại bỏ hoàn toàn khỏi kết quả.
• LEFT JOIN: Trả về tất cả các bản ghi từ bảng bên trái (Left Table) và các bản ghi khớp từ bảng bên phải (Right Table). Nếu không tìm thấy bản ghi khớp ở bảng bên phải, các cột tương ứng từ bảng bên phải sẽ nhận giá trị NULL.

Cạm bẫy phổ biến của lập trình viên Junior

1. Đặt điều kiện của bảng bên phải vào mệnh đề WHERE thay vì ON: Khi sử dụng LEFT JOIN, nếu bạn đặt bộ lọc WHERE right_table.status = 'ACTIVE', vô tình điều kiện này sẽ biến LEFT JOIN thành INNER JOIN vì các giá trị NULL được sinh ra từ LEFT JOIN sẽ bị loại bỏ bởi mệnh đề WHERE.
2. Hiệu năng truy vấn kém do thiếu Index: Khi thực hiện JOIN trên các cột không có Index, Database Engine sẽ phải thực hiện Nested Loops hoặc Hash Match tốn rất nhiều tài nguyên CPU và I/O.

Ví dụ minh họa

-- Sai lầm phổ biến biến LEFT JOIN thành INNER JOIN
SELECT c.customer_name, o.order_id 
FROM customers c 
LEFT JOIN orders o ON c.id = o.customer_id 
WHERE o.status = 'PENDING';

-- Khắc phục đúng bằng cách đưa điều kiện vào mệnh đề ON hoặc xử lý NULL
SELECT c.customer_name, o.order_id 
FROM customers c 
LEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'PENDING';

Lưu ý kinh nghiệm thực chiến

Luôn xác định rõ chiều dữ liệu chính (Main Entity) trước khi viết câu lệnh JOIN. Đảm bảo các cột tham gia điều kiện ON đã được thiết lập Index đầy đủ để tối ưu hóa Execution Plan.

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

Khi bạn thực hiện tìm kiếm với mệnh đề WHERE column_name LIKE 'abc%', Database Engine có thể tận dụng B-Tree Index vì nó biết rõ chuỗi bắt đầu từ đâu và tiến hành Index Seek hiệu quả. Ngược lại, khi sử dụng LIKE '%abc' hoặc LIKE '%abc%', ký tự % ở đầu buộc hệ thống phải quét toàn bộ Index hoặc toàn bộ bảng (Full Table Scan / Index Scan).

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

• DELETE: Là một câu lệnh DML (Data Manipulation Language). Nó xóa dữ liệu từng dòng một và ghi lại từng thao tác vào Transaction Log. Cho phép sử dụng mệnh đề WHERE để xóa có điều kiện, kích hoạt các Trigger liên quan và có thể Rollback nếu nằm trong một Transaction.
• TRUNCATE: Là một câu lệnh DDL (Data Definition Language). Nó hoạt động bằng cách giải phóng các trang dữ liệu (data pages) được cấp phát cho bảng thay vì xóa từng dòng. Không ghi chi tiết từng dòng vào Transaction Log, không kích hoạt Trigger, không thể dùng mệnh đề WHERE và tự động reset lại giá trị Identity (Auto-increment) về ban đầu.

So sánh hiệu năng và an toàn

• Hiệu năng: TRUNCATE nhanh hơn rất nhiều so với DELETE, đặc biệt trên các bảng có hàng triệu bản ghi vì nó ít tốn tài nguyên Log và khóa (locks) hơn.
• An toàn: DELETE an toàn hơn khi cần xóa có chọn lọc và có thể khôi phục dữ liệu nếu có lỗi xảy ra trong Transaction. TRUNCATE cực kỳ nguy hiểm nếu thực hiện nhầm vì dữ liệu bị xóa vĩnh viễn và không thể Rollback trong hầu hết các cấu hình thông thường.

Ví dụ minh họa

-- Xóa toàn bộ dữ liệu bảng logs nhưng giữ lại cấu trúc và reset identity
TRUNCATE TABLE system_logs;

-- Xóa dữ liệu có điều kiện trong bảng orders
DELETE FROM orders WHERE status = 'CANCELLED';

Lưu ý kinh nghiệm thực chiến

Trong môi trường Production, không bao giờ chạy TRUNCATE thủ công mà không có sự đồng ý của quản trị viên hệ thống. Hãy sử dụng DELETE kết hợp với Batching (chia nhỏ số lượng bản ghi xóa mỗi lần) để tránh gây ra hiện tượng Lock Escalation làm treo hệ thống.

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

Khi bạn xây dựng một Index trên cột created_date, cấu trúc B-Tree được sắp xếp theo giá trị thời gian thực tế của từng bản ghi. Khi bạn bọc cột đó trong một hàm như YEAR(created_date) hoặc CONVERT(VARCHAR, created_date), Database Engine buộc phải tính toán giá trị của hàm này cho mọi dòng dữ liệu trong bảng trước khi so sánh. Điều này làm cho Index hiện có trở nên vô tác dụng, dẫn đến Full Table Scan.

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

• COALESCE: Là một hàm chuẩn thuộc chuẩn SQL ANSI, nhận vào một danh sách các biểu thức và trả về giá trị khác NULL đầu tiên từ trái sang phải. Nếu tất cả các biểu thức đều là NULL, nó sẽ trả về NULL.
• ISNULL / IFNULL: Thường là các hàm độc quyền (proprietary functions) của từng hệ quản trị cơ sở dữ liệu cụ thể (như ISNULL trong SQL Server hay IFNULL trong MySQL).

Ưu điểm vượt trội của COALESCE

1. Tính tương thích cao (Portability): Vì tuân thủ chuẩn ANSI SQL, hàm COALESCE hoạt động nhất quán trên hầu hết các hệ quản trị cơ sở dữ liệu phổ biến như SQL Server, PostgreSQL, MySQL và Oracle.
2. Hỗ trợ đa tham số: Bạn có thể truyền vào nhiều hơn hai giá trị để kiểm tra tuần tự.
3. Xử lý kiểu dữ liệu chuẩn xác: COALESCE tự động suy diễn kiểu dữ liệu (data type precedence) cho giá trị trả về dựa trên các tham số được truyền vào.

Ví dụ minh họa

-- Sử dụng COALESCE để hiển thị tên thay thế nếu tên chính bị NULL
SELECT employee_id, COALESCE(preferred_name, middle_name, first_name, 'No Name') AS display_name
FROM employees;

Lưu ý kinh nghiệm thực chiến

Khi thiết kế các báo cáo hoặc API trả về dữ liệu cho frontend, việc sử dụng COALESCE giúp giảm thiểu tối đa các lỗi liên quan đến NullPointerException hoặc giá trị undefined ở tầng ứng dụng, đồng thời giúp câu lệnh SQL gọn gàng hơn rất nhiều so với việc lồng nhiều câu lệnh CASE WHEN phức tạp.

Phân tích bản chất

• Ad-hoc Queries: Là các câu lệnh SQL được gửi trực tiếp từ ứng dụng tới Database Management System (DBMS) mỗi khi cần thực thi. Mỗi câu lệnh thường phải trải qua quá trình phân tích cú pháp (parsing), tối ưu hóa (query optimization) và biên dịch (compilation) lại từ đầu.
• Stored Procedures: Là tập hợp các câu lệnh SQL được biên dịch sẵn và lưu trữ trực tiếp bên trong cơ sở dữ liệu. Lần gọi đầu tiên sẽ tạo execution plan, và các lần gọi sau sẽ tái sử dụng plan này.

Lợi ích khi sử dụng Stored Procedures

1. Hiệu năng (Performance): Giảm tải thời gian biên dịch nhờ tái sử dụng execution plan và giảm lưu lượng mạng truyền tải giữa ứng dụng và database.
2. Bảo mật (Security): Giảm thiểu rủi ro tấn công SQL Injection vì các tham số thường được truyền qua SqlParameter một cách an toàn.
3. Bảo trì (Maintainability): Logic nghiệp vụ tập trung tại database, giúp dễ dàng cập nhật mà không cần biên dịch lại mã nguồn ứng dụng.

Khi nào Junior nên sử dụng?

• Khi thực hiện các tác vụ phức tạp liên quan đến nhiều bảng và cần bảo mật cao.
• Khi cần chuẩn hóa dữ liệu đầu vào qua các hệ thống khác nhau gọi chung một thủ tục.

Ví dụ minh họa Stored Procedures

CREATE PROCEDURE sp_GetEmployeeByDepartment
    @DepartmentID INT
AS
BEGIN
    SELECT EmployeeID, FullName, Salary
    FROM Employees
    WHERE DepartmentID = @DepartmentID;
END;

Kinh nghiệm thực chiến: Không nên lạm dụng Stored Procedures cho toàn bộ ứng dụng vì sẽ làm giảm khả năng kiểm soát version control của mã nguồn ứng dụng và gây khó khăn khi scale ứng dụng sang các hệ thống ORM hiện đại.