Thử nghiệm quét full chậm hơn index

Dưới đây là phiên bản viết lại bài viết từ link bạn cung cấp, theo hướng phân tích sâu sắc hơn về kiến trúc index trong Oracle, lý giải vì sao truy vấn dùng Index có thể chạy chậm hơn Full Table Scan, kèm mô hình truy xuất dữ liệu, các khái niệm như selectivity, random I/O, và cost-based optimizer.

Sửa bài viết

Tăng tốc database Index phần 13 Merge

Đã lâu không quay lại chủ đề này, vì trước mấy ku em bảo mình viết hàn lâm khó hiểu quá nên mình chuyển qua dạng vấn đáp xem có dễ hiểu hơn chút nào không? Các bạn có góp ý vui lòng comment nhé!

Sửa bài viết

Tăng tốc database Index phần 12 với LIKE

Nếu các bạn chưa đọc bài trước có thể đọc tại link Tăng tốc database phần 11 Tìm kiếm theo Khoảng, Lớn Hơn, Nhỏ Hơn, và BETWEEN

Truy vấn với Like nhiều lúc rất hiệu quả, nhiều lúc lại rất chậm. Có thể một số từ khóa được đánh index tốt, một số thì không. Nhiều lúc vị trí của wild card có thể cho kết quả rất khác nhau. VÍ dụ dùng % wild card ở giữa từ khóa

Sửa bài viết

Tăng tốc database index phần 11 Tìm kiếm theo Khoảng, Lớn Hơn, Nhỏ Hơn, và BETWEEN

Nếu các bạn chưa đọc bài trước có thể đọc tại đây (10 - Query với tham số)

Các phép toán lớn hơn (>) nhỏ hơn (<) và BETWEEN cũng có thể sử dụng index giống toán tử bằng (=), thậm chí kể cả toán tử LIKE cũng có thể dùng được trong một số trường hợp. Việc dùng index kiểu này có giới hạn nếu đánh index trong một index chứa nhiều cột và chọn cột nào trước, cột nào sau. Nhiều khi không thể chọn được thứ tự đúng.

Sửa bài viết

Tăng tốc database index phần 10 - Query với tham số

Nếu các bạn chưa đọc bài trước có thể đọc tại link Tăng tốc database index phần 9 - Function- User-Defined Function

Có hai cách để truyền dữ liệu vào database, một là truyền trực tiếp qua câu lệnh, hai là truyền qua tham số, thường là sử dụng ?, :name or @name và truyền giá trị tương ứng qua lời gọi.

Sửa bài viết

Tăng tốc database index phần 9 - Function - User-Defined Function

Nếu các bạn chưa đọc bài trước có thể đọc tại link Tăng tốc database index phần 8 - Function- Tìm kiếm không phân biệt chữ Hoa chữ Thường- UPPER và LOWER

Dùng Function-based có vẻ ngon rồi nhưng có phải mọi hàm đều sử dụng được nó không? Có thể dùng hàm mặc định như UPPER cũng có thể dùng biểu thức kiểu A+B có thể dùng cả hàm tự định nghĩa nữa. Tuy nhiên có một ngoại lệ quan trọng có là hàm có phụ thuộc vào thời gian hiện tại ( dù là gián tiếp hay trực tiếp) ví dụ

Sửa bài viết

Tăng tốc database index phần 8 - Function - Tìm kiếm không phân biệt chữ Hoa chữ Thường - UPPER và LOWER

Nếu các bạn chưa đọc bài trước có thể đọc tại link này Tăng tốc database index phần 7 -Index chậm 2

Phần này trong thực tế mình không gặp, do mình luôn để collation trong DB là Case-Insensitive, tuy nhiên vì mình dịch từ bài gốc của tác giả nên mình sẽ dịch luôn và không cắt gọt. Biết đâu có lúc nào đó lại thiết kế db Case-Sensitive thì sao. Lúc đó có thể dùng được chỗ này. Trong trường hợp database thiết kế có phân biệt hoa thường, mà cần truy vấn không phân biệt hoa thường, cách thông thường sẽ truy vấn như thế này.

Sửa bài viết

Tăng tốc database index phần 7 - Index chậm 2

Nếu các bạn chưa đọc bài trước có thể đọc tại link này Tăng tốc database index phần 6 -Index kết hợp

Trong phần trước mình đã trình bày về lợi ích đạt được khi đổi vị trí index, tuy nhiên ví dụ chỉ xem xét với 2 câu lệnh SQL. Tuy nhiên việc thay đổi index có thể ảnh hưởng tới tất cả các câu truy vấn trên bảng. Phần này sẽ trình bày về cách database chọn một index và các ảnh hưởng có thể xảy ra khi thay đổi index đã có.

Sửa bài viết

Tăng tốc database index phần 6 - Index kết hợp

Nếu các bạn chưa đọc bài trước có thể đọc tại link này Tăng tốc database index phần 5 -WHERE trên khóa chính

Mặc dù khóa chính được tạo index tự động, và ta biết nếu where theo khóa chính thì chạy rất nhanh rồi, nhưng nếu khóa chính lại bao gồm nhiều trường thì sao trường hợp này được gọi là concatenated index ( multi-column, composite hoặc combined index) thôi mình gọi là Index Kết Hợp cho nó dễ nhé. Nhưng khi tạo theo nhiều trường này có cần quan tâm thứ tự không, hay cần hai trường thì cứ add hai trường, ba trường thì cứ đánh index cho 3 trường không cần thứ tự gì cả? Đáp án là bạn cần rất cẩn thận khi đánh index có nhiều trường, vì thứ tự của nó rất quan trọng. Chi tiết mình sẽ giải thích bên dưới

Sửa bài viết

Tăng tốc database index phần 5 - WHERE trên khóa chính

Nếu các bạn chưa đọc bài trước có thể đọc tại link này Tăng tốc database index phần 4 - Index chậm

Trong những phần trước mình đã mô tả về cách index hoạt động và nguyên nhân làm index chậm, trong các phần sau mình sẽ mô tả cách phát hiện mà tránh những vấn đề này, bắt đầu với WHERE. Lệnh WHERE xác định điều kiện tìm kiếm của một câu lệnh SQL vì vậy việc sử dụng index với where rất quan trọng quyết định tốc độ truy vấn dữ liệu. Mặc dù WHERE là một lệnh ảnh hưởng siêu to khổng lồ tới hiệu năng nhưng nó lại thường không được hiểu đúng, dẫn tới database phải quét qua rất nhiều index. Một lệnh truy vấn chậm thường có nguyên nhân đầu tiên là một lệnh WHERE viết cùi.

Sửa bài viết

Tăng tốc database index phần 4 - Index chậm

Như bài trước đã viết, tốc độ duyệt cây tìm kiếm cân bằng là siêu nhanh, thế mà không hiểu sao mình đã đánh index rồi mà lệnh truy vấn vẫn chậm, mấy thằng cha làm cơ sơ dữ liệu như Larry Ellison nó lừa mình kiếm tiền tỷ phải không? Ngày xửa ngày xưa, từ hồi anh em cây khế còn chơi với nhau, cho tới bây giờ có một giai thoại được truyền tai nhau giữa các dev là index để lâu càng ngày càng chậm, lâu lâu phải rebuild lại index một lần. Thực tế thì không phải như vậy, cây index luôn luôn có một độ sâu cố định và luôn được duy trì ở trạng thái cân bằng. Việc đánh index rồi mà truy vấn vẫn chậm có thể còn hai nguyên nhân nữa. Đầu tiên ta phải hiểu khi truy vấn dữ liệu theo index gồm 3 bước

Sửa bài viết

Tăng tốc database index phần 3 - B-Tree

Index leaf node được lưu trữ theo dạng Linked List về mặt logic, còn về cấu trúc lưu trữ vật lý, mỗi leaf node có thể lưu lung tung, không có thứ tự gì, nó giống một quyền từ điển mà các trang bị xáo trộn, khi ta cần tra từ "Phở" mà đang lật tới trang có từ "Cơm" không có nghĩa là từ Phở chắc chắn ở sau từ Cơm. Để đáp ứng việc tìm kiếm nhanh trong các trang xáo trộn này , database cung cấp một kiểu dữ liệu khác là Cây Tìm Kiếm Cân Bằng (a balanced search tree) gọi ngắn là B-Tree (chú ý các bạn không nên nhầm với Cây nhị phân Binary tree nhé).

Sửa bài viết

Tăng tốc database index phần 2 - Leaf Nodes

Bài trước khái niệm cơ bản

Đầu tiên mình định dịch ra là nút lá, nhưng nghe nó không được hay cho lắm nên quyết định giữ nguyên tên của nó là Leaf Nodes.

Sửa bài viết

Tăng tốc database index phần 1 - khái niệm cơ bản

Phần đầu tiên trong chuỗi bài là các phần liên quan tới database, nhiều bạn thích trình bày các vấn đề khác về database tuy nhiên theo kinh nghiệm cá nhân mình thấy hiểu về index trong db rất quan trọng trong quá trình nâng cao hiệu năng của chương trình, đôi khi chỉ cần đánh index thôi mà tốc độ đang từ rùa bò trở nên tốc độ bàn thờ . Nhưng có phải index luôn giúp truy vấn nhanh hơn không? Đầu tiên là khái niệm index là gì?

Sửa bài viết

Hiểu về index partition, phân biệt local index và global index

Mục đích: 

Index tạo trên bảng partition có thể là partition hoặc nonpartition, với partition index giúp dễ dàng quản lý, tăng tính sẵn sàng, hiệu năng cao hơn và khả năng mở rộng tốt hơn. Bạn có thể tạo partititioin độc lập (global index) hoặc tự động ánh xạ 1-1 với partition của table (local index). Nhưng nhìn chung bạn nên tạo global index cho ứng dụng OLTP (do nhiều khi không quét theo trường partition key của bảng được) và local index cho ứng dụng data warehousing hoặc DSS (decision support system).

Qua bài viết này hy vọng sẽ giúp bạn Hiểu về index partition, phân biệt local index và global index. 

Sửa bài viết