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

Khái niệm N+1 Query Problem

N+1 Query Problem xảy ra khi ứng dụng thực hiện 1 câu lệnh SQL để lấy danh sách bảng cha (1 query), sau đó thực hiện thêm N câu lệnh SQL riêng lẻ để lấy dữ liệu bảng con cho từng bản ghi trong danh sách đó (N queries). Điều này làm suy giảm nghiêm trọng hiệu năng hệ thống khi số lượng bản ghi lớn.

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

• Primary Key (Khóa chính):
  • Đảm bảo tính duy nhất (Uniqueness) cho mỗi bản ghi trong bảng.
  • Tuyệt đối không được chứa giá trị NULL (Not Null).
  • Thường được tự động tạo một clustered index để tối ưu hóa tốc độ tìm kiếm.
• Foreign Key (Khóa ngoại):
  • Thiết lập mối quan hệ giữa hai bảng (Parent - Child).
  • Đảm bảo tính toàn vẹn tham chiếu (Referential Integrity), ngăn chặn việc chèn dữ liệu con khi dữ liệu cha không tồn tại.

Các thiết lập quan trọng khi cấu hình Foreign Key

• ON DELETE CASCADE: Khi bản ghi cha bị xóa, các bản ghi con liên quan cũng bị xóa tự động.
• ON DELETE RESTRICT / NO ACTION: Ngăn cản việc xóa bản ghi cha nếu vẫn còn bản ghi con tham chiếu.
• ON DELETE SET NULL: Đặt giá trị khóa ngoại ở bảng con thành NULL khi bản ghi cha bị xóa.

Ví dụ minh họa

CREATE TABLE Customers (
    CustomerID INT PRIMARY KEY,
    CustomerName VARCHAR(100)
);

CREATE TABLE Orders (
    OrderID INT PRIMARY KEY,
    OrderDate DATE,
    CustomerID INT,
    CONSTRAINT FK_CustomerOrder FOREIGN KEY (CustomerID)
    REFERENCES Customers(CustomerID)
    ON DELETE CASCADE
);

Kinh nghiệm thực chiến: Không nên bỏ qua việc khai báo Foreign Key trong database chỉ vì lý do muốn tăng tốc độ chèn dữ liệu. Việc kiểm soát logic ở tầng ứng dụng không an toàn bằng việc ép buộc ràng buộc trực tiếp tại tầng database.

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

• CHAR (Character):
  • Là kiểu dữ liệu chuỗi có độ dài cố định (fixed-length).
  • Nếu chuỗi ngắn hơn độ dài khai báo, hệ thống sẽ tự động độn thêm khoảng trắng (spaces) vào cuối cho đủ kích thước.
  • Tốc độ truy xuất nhanh hơn một chút đối với các trường có độ dài đồng nhất do kích thước bản ghi cố định.
• VARCHAR (Variable Character):
  • Là kiểu dữ liệu chuỗi có độ dài thay đổi (variable-length).
  • Chỉ lưu trữ đúng số lượng ký tự thực tế cộng thêm một vài byte metadata để quản lý chiều dài.
  • Tiết kiệm dung lượng lưu trữ đáng kể khi dữ liệu có chiều dài biến động.

Ảnh hưởng đến hiệu năng

1. Dung lượng lưu trữ: Sử dụng CHAR cho các cột có chiều dài thay đổi lớn (như ghi chú, địa chỉ) sẽ làm lãng phí nghiêm trọng dung lượng ổ cứng và bộ nhớ đệm (Buffer Pool).
2. Index Performance: Kích thước bản ghi lớn hơn làm giảm số lượng bản ghi trên mỗi trang dữ liệu (Page), dẫn đến việc tăng số lần đọc đĩa (Disk I/O) khi thực hiện Index Scan.

Ví dụ minh họa

-- Sử dụng CHAR cho mã định danh có độ dài cố định chính xác 10 ký tự
EmployeeCode CHAR(10),

-- Sử dụng VARCHAR cho họ tên có độ dài thay đổi
FullName VARCHAR(100)

Kinh nghiệm thực chiến: Luôn ưu tiên sử dụng VARCHAR cho các cột văn bản có độ dài không cố định, và chỉ dùng CHAR khi chắc chắn rằng mọi dữ liệu nhập vào đều có độ dài hoàn toàn bằng nhau (ví dụ: mã quốc gia, mã hash cố định).

Quy trình tối ưu hóa một Slow Query

1. Xác định câu lệnh chậm: Sử dụng công cụ giám sát như SQL Server Profiler, Slow Query Log trong MySQL, hoặc APM tools để khoanh vùng câu lệnh gây nghẽn.
2. Phân tích Execution Plan: Sử dụng lệnh EXPLAIN hoặc xem Graphical Execution Plan để hiểu cách cơ sở dữ liệu thực thi truy vấn.
3. Kiểm tra Index: Phát hiện các hiện tượng Table Scan / Clustered Index Scan không cần thiết và đề xuất tạo Non-Clustered Index phù hợp.
4. Tối ưu cấu trúc truy vấn: Tránh dùng SELECT *, hạn chế sử dụng hàm trên cột điều kiện (sẽ làm mất tác dụng của Index), và tối ưu hóa các phép nối JOIN.

Ví dụ phân tích bằng EXPLAIN

EXPLAIN SELECT * FROM Orders WHERE CustomerID = 5 AND OrderDate >= '2023-01-01';

• Nếu cột CustomerID hoặc OrderDate không có Index, hệ thống sẽ quét toàn bộ bảng (Table Scan).
• Giải pháp là tạo Composite Index:

  CREATE INDEX IX_Orders_Customer_Date ON Orders(CustomerID, OrderDate);

Lưu ý quan trọng

• Không phải lúc nào có Index cũng tốt. Index làm tăng tốc độ đọc nhưng làm chậm tốc độ ghi (INSERT, UPDATE, DELETE).
• Tránh lạm dụng các toán tử phủ định như NOT IN, !=, <> vì chúng thường khó tận dụng được Index.

Kinh nghiệm thực chiến: Khi làm việc với dữ liệu lớn, hãy luôn kiểm tra xem các cột tham gia vào mệnh đề WHERE, JOIN, ORDER BY đã được đánh chỉ mục đúng cách hay chưa trước khi nghĩ đến việc tối ưu phần cứng.

Trong phát triển dự án với SQL, việc tối ưu hóa và quản lý tốt Group By & Aggregations 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 Union vs Union All 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 Indexing và Covering Index

1. Database Indexing (Thông thường): Khi thực hiện truy vấn, Database Engine sử dụng Index để tìm kiếm vị trí của các dòng dữ liệu (Row ID hoặc Primary Key). Sau đó, nó phải thực hiện một thao tác gọi là Key Lookup hoặc RID Lookup để truy xuất các cột dữ liệu còn lại từ bảng gốc (Heap hoặc Clustered Index).

Thách thức trong Microservices

Trong kiến trúc Microservices, mỗi dịch vụ thường sở hữu một Database riêng (Database per Service). Do đó, không thể sử dụng cơ chế ACID truyền thống của một Database đơn lẻ để đảm bảo tính nhất quán trên toàn hệ thống.

Các cấp độ cô lập (Isolation Levels) và tác động

1. Read Committed (Mặc định của nhiều hệ thống):

Bản chất của Cardinality

Cardinality là số lượng giá trị duy nhất trong một cột. Cột có độ chọn lọc thấp (ví dụ: Gender, Status, IsActive) có rất ít giá trị khác biệt.

Cơ chế MVCC

MVCC cho phép nhiều người dùng truy cập cơ sở dữ liệu cùng lúc mà không cần phải khóa (lock) các dòng dữ liệu khi đọc. Thay vì ghi đè trực tiếp lên dữ liệu cũ, hệ thống sẽ tạo ra các phiên bản (version) mới của dòng dữ liệu đó.

Database Partitioning là kỹ thuật chia nhỏ một bảng lớn thành các phần nhỏ hơn (partitions) dựa trên một tiêu chí cụ thể (Range, List, Hash, hoặc Key).

Đây là hai chiến lược quản lý đồng thời (Concurrency Control) trong môi trường đa người dùng.

Index hoạt động dựa trên cấu trúc dữ liệu B-Tree (hoặc Hash). Nó tạo ra một bản sao thu nhỏ của các cột được đánh chỉ mục, giúp SQL Engine tìm kiếm dữ liệu mà không cần quét toàn bộ bảng.

Clustered Index

• Định nghĩa: Xác định thứ tự vật lý của dữ liệu trong bảng. Mỗi bảng chỉ có duy nhất một Clustered Index.
• Tốc độ: Truy vấn dữ liệu theo dải (Range scan) cực nhanh vì dữ liệu được sắp xếp vật lý trên đĩa.
• Lưu ý: Thường gắn với Primary Key.

Non-Clustered Index

• Định nghĩa: Là một cấu trúc tách biệt với dữ liệu thực tế, chứa giá trị cột được đánh index và con trỏ (pointer) trỏ về hàng dữ liệu tương ứng.
• Tốc độ: Tốt cho việc tìm kiếm các giá trị đơn lẻ.
• Lưu ý: Nếu truy vấn cần lấy thêm các cột không nằm trong Index, hệ thống phải thực hiện thao tác 'Key Lookup' (đọc từ bảng chính), điều này làm giảm hiệu năng đáng kể.

Chiến lược thực chiến:

Sử dụng Covering Index (đưa các cột cần lấy vào phần INCLUDE của Index) để tránh Key Lookup và tăng tốc độ truy vấn đáng kể.