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

Phân tích kỹ thuật

Vấn đề thực tế

Việc tạo mới một kết nối tới Database là một thao tác cực kỳ tốn kém (chi phí bắt tay TCP, xác thực, cấp phát tài nguyên phía Server). Nếu mỗi request đều tạo một kết nối mới, hệ thống sẽ nhanh chóng bị quá tải (Database Connection Exhaustion).

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.

Để tối ưu hóa kết nối Database trong Laravel khi xử lý lượng request đồng thời lớn, chúng ta cần áp dụng các chiến lược sau:

1. Bản chất của Service Container

Service Container trong Laravel là một công cụ cực kỳ mạnh mẽ để quản lý các lớp phụ thuộc (Class Dependencies) và thực hiện Dependency Injection (DI). Thay vì khởi tạo các đối tượng trực tiếp bằng từ khóa new bên trong Controller hoặc Service, chúng ta định nghĩa các phụ thuộc thông qua Constructor Injection, và Service Container sẽ tự động phân giải (Resolve) các đối tượng đó.

1. Vấn đề Race Condition trong hệ thống Enterprise

Khi nhiều người dùng cùng thực hiện một thao tác tại một thời điểm (ví dụ: săn mã giảm giá có giới hạn số lượng, hoặc chuyển tiền tài khoản), hiện tượng tranh chấp dữ liệu (Race Condition) xảy ra. Nếu chỉ dùng Transaction thông thường theo mức cô lập mặc định (Repeatable Read trong MySQL), dữ liệu có thể bị ghi đè không chính xác.

1. Bản chất của Event và Listener trong Laravel

Event và Listener triển khai mô hình Observer Pattern trong thiết kế phần mềm, giúp tách biệt các nghiệp vụ cốt lõi (Core Business Logic) với các tác vụ phụ (Side Effects) như gửi email xác nhận, ghi log hệ thống, hoặc đẩy thông báo.

1. Nguyên nhân gây Memory Leak trong Laravel

Khi sử dụng Eloquent ORM để truy vấn hàng trăm nghìn bản ghi cùng lúc (ví dụ: User::all() hoặc User::get()), Laravel sẽ tải toàn bộ đối tượng model vào bộ nhớ RAM của PHP. Khi vượt quá giới hạn memory_limit, ứng dụng sẽ văng lỗi Allowed memory size exhausted.

Để triển khai Distributed Caching với Redis trong ASP.NET Web API, chúng ta sử dụng interface IDistributedCache.

JWT (JSON Web Token) là cơ chế xác thực stateless. Khi người dùng đăng nhập thành công, server cấp một Access Token (thời gian sống ngắn) và một Refresh Token (thời gian sống dài).

Việc trả về toàn bộ dữ liệu từ database (ví dụ: ToList()) là nguyên nhân hàng đầu gây sập hệ thống do tràn bộ nhớ (Out of Memory).