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

Question

Khi phân tích Explain Plan, làm thế nào để phân biệt giữa Index Scan và Index Seek, và tại sao việc xuất hiện 'Using filesort' hoặc 'Using temporary' lại là dấu hiệu cảnh báo nguy hiểm?

Senior

Answer 1

Index Seek là quá trình tìm kiếm trực tiếp trong cấu trúc B-Tree, rất nhanh. Index Scan là duyệt toàn bộ cây index, chậm hơn. 'Using filesort' xuất hiện khi MySQL không thể dùng index để sắp xếp kết quả, buộc phải dùng bộ nhớ hoặc đĩa để sort. 'Using temporary' xuất hiện khi MySQL cần bảng tạm để xử lý GROUP BY hoặc DISTINCT. Cả hai đều gây tiêu tốn I/O lớn, cần tối ưu bằng cách thêm index phù hợp hoặc điều chỉnh câu lệnh SQL.

Answer 2

Chiến lược ưu tiên: 1. Sử dụng công cụ như pt-query-digest để nhóm các truy vấn theo mẫu (fingerprint) và xác định truy vấn gây tải lớn nhất (tổng thời gian thực thi). 2. Tập trung vào các truy vấn có số lượng Rows Examined lớn nhưng Rows Sent nhỏ. 3. Kiểm tra Explain Plan cho các truy vấn này để tìm thiếu sót index. 4. Áp dụng index hoặc rewrite query. 5. Theo dõi lại Slow Query Log để xác nhận hiệu quả.

Answer 3

MySQL không thể sử dụng index nếu cột bị bao bọc trong hàm (ví dụ: WHERE YEAR(created_at) = 2023) vì giá trị index được lưu trữ theo giá trị gốc của cột, không phải kết quả của hàm. Khắc phục: Thay đổi câu lệnh thành so sánh khoảng (range scan) như WHERE created_at >= '2023-01-01' AND created_at <= '2023-12-31'. Điều này cho phép MySQL sử dụng index trên cột created_at một cách hiệu quả.

Answer 4

Khi dùng ORDER BY với LIMIT, MySQL thường phải đọc nhiều dòng hơn mức cần thiết nếu không có index phù hợp. Kỹ thuật 'Deferred Join' (hoặc 'Seek Method') thường được dùng: thay vì SELECT FROM table ORDER BY id LIMIT 100000, 10, hãy thực hiện SELECT FROM table JOIN (SELECT id FROM table ORDER BY id LIMIT 100000, 10) AS temp USING (id). Cách này giúp MySQL chỉ truy xuất dữ liệu cần thiết sau khi đã xác định được các ID thông qua index.

Answer 5

Truyền thống: MySQL đọc toàn bộ row từ bảng vào Server layer rồi mới lọc theo điều kiện WHERE. ICP: MySQL đẩy điều kiện lọc xuống Storage Engine. Nếu một phần của điều kiện WHERE có thể được kiểm tra bằng index, Storage Engine sẽ lọc ngay tại đó trước khi trả về row. Điều này giảm thiểu đáng kể số lượng row phải truyền từ Storage Engine lên Server, giúp tăng tốc độ truy vấn đáng kể.

Answer 6

Index dư thừa là khi một index là tiền tố (prefix) của một index khác (ví dụ: index (a) và index (a, b)). Index (a) trở nên dư thừa vì mọi truy vấn dùng (a) đều có thể dùng (a, b). Việc giữ index dư thừa làm chậm quá trình INSERT, UPDATE, DELETE vì MySQL phải cập nhật tất cả các index liên quan, đồng thời tốn thêm dung lượng lưu trữ và bộ nhớ Buffer Pool.

Answer 7

Cột 'Extra' cung cấp thông tin chi tiết về cách MySQL thực hiện truy vấn. Các giá trị cần lưu ý: 1. 'Using index': Tốt nhất (Covering Index). 2. 'Using index condition': Đang sử dụng ICP. 3. 'Using filesort': Cần tối ưu lại ORDER BY. 4. 'Using temporary': Cần tối ưu lại GROUP BY hoặc DISTINCT. 5. 'Full table scan': Cần thêm index ngay lập tức.

Answer 8

Covering Index là khi tất cả các cột cần thiết cho truy vấn (trong SELECT, WHERE, JOIN) đều nằm trong cùng một index. Khi đó, MySQL không cần truy cập vào bảng gốc (Clustered Index) để lấy dữ liệu. Giới hạn: Không nên lạm dụng bằng cách thêm quá nhiều cột vào index vì sẽ làm tăng kích thước index, ảnh hưởng đến hiệu suất ghi và chiếm dụng bộ nhớ Buffer Pool.

Answer 9

Kiểu dữ liệu nhỏ hơn giúp index nhỏ hơn, cho phép nhiều node index nằm vừa trong RAM (Buffer Pool), giảm I/O đĩa. Ví dụ: Dùng INT thay vì BIGINT nếu không cần thiết, hoặc dùng VARCHAR độ dài vừa đủ thay vì TEXT. Ngoài ra, việc so sánh dữ liệu không khớp kiểu (ví dụ: so sánh cột VARCHAR với giá trị INT) sẽ khiến MySQL không thể sử dụng index do phải thực hiện implicit type conversion.

Answer 10

Vue 3.5 đã giới thiệu cơ chế Reactivity System mới với khả năng quản lý bộ nhớ hiệu quả hơn và giảm thiểu overhead cho các object lớn.