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 lập trình iOS với Swift, Delegate Pattern và Closure là hai phương pháp phổ biến để truyền dữ liệu hoặc thông báo sự kiện ngược lại giữa các thành phần (ví dụ từ Child View Controller về Parent View Controller).

Access Control giúp ẩn chi tiết triển khai của mã nguồn, tăng tính đóng gói và bảo mật trong ứng dụng Swift.

Câu lệnh defer trong Swift dùng để lên lịch thực thi một đoạn mã ngay trước khi phạm vi (scope) hiện tại kết thúc, bất kể phạm vi đó kết thúc như thế nào (thông qua return, break, hay ném ra lỗi throw).

Type Casting trong Swift là cách kiểm tra kiểu của một thể hiện hoặc xử lý thể hiện đó như thể nó là một kiểu siêu lớp hoặc lớp con khác trong cùng hệ thống phân cấp.

Lazy Stored Property là thuộc tính mà giá trị ban đầu của nó không được tính toán hoặc khởi tạo cho đến lần truy cập đầu tiên.

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.

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.

Bản chất của Dead Letter Queue (DLQ)

DLQ là một hàng đợi đặc biệt được sử dụng để lưu trữ các thông điệp (messages) không thể xử lý thành công sau một số lần thử lại (retries) nhất định.

Cơ chế Push-based (Consumer-driven)

• Cách hoạt động: Message Broker chủ động đẩy dữ liệu tới Consumer ngay khi có message mới.
• Ưu điểm: Độ trễ (latency) thấp, phản hồi gần như tức thì.
• Nhược điểm: Dễ gây quá tải (overload) cho Consumer nếu lưu lượng message tăng đột biến (spike).

Cơ chế Pull-based (Polling)

• Cách hoạt động: Consumer chủ động gửi yêu cầu để lấy dữ liệu từ Queue.
• Ưu điểm: Consumer có quyền kiểm soát tốc độ xử lý (backpressure), tránh bị sập hệ thống do quá tải.
• Nhược điểm: Tốn tài nguyên mạng và CPU do phải liên tục kiểm tra (polling) nếu không có dữ liệu.

Lời khuyên thực chiến

Sử dụng Push-based khi hệ thống cần xử lý thời gian thực (real-time). Sử dụng Pull-based khi bạn cần kiểm soát tải trọng (load balancing) và đảm bảo tính ổn định cho các dịch vụ xử lý nặng.