2012-11-13 65 views
9

Ngày tốt lành mọi người, tôi hiện đang nghiên cứu về tối ưu hóa thuật toán tìm kiếm.Thuật toán tìm kiếm truy vấn trong cơ sở dữ liệu là gì?

Hiện tại, tôi đang nghiên cứu về Cơ sở dữ liệu.

Trong cơ sở dữ liệu với hỗ trợ SQL.

Tôi có thể ghi truy vấn cho một bảng cụ thể.

  1. Chọn Số từ Bảng 1 trong đó Tên = "Thử nghiệm";
  2. Chọn * từ Bảng 1 trong đó Tên = "Kiểm tra";

1 tìm kiếm số từ Bảng 1 từ đó Tên là Kiểm tra và 2 tìm kiếm tất cả cột cho tên Kiểm tra.

Tôi hiểu khái niệm về chức năng, tuy nhiên điều tôi quan tâm đến việc tìm hiểu phương pháp tìm kiếm là gì?

Chỉ là tìm kiếm tuyến tính đơn giản từ chỉ mục đầu tiên cho đến khi chỉ số thứ n, nó sẽ lấy miễn là điều kiện là đúng, do đó có tốc độ O (n) hoặc có thuật toán duy nhất làm tăng tốc độ của nó?

+0

Rất có thể MySQL (InnoDB) tối ưu hóa truy vấn tìm kiếm bằng B-tree. – nullpotent

Trả lời

1

câu hỏi rất tốt, nhưng nó có thể có nhiều câu trả lời tùy thuộc vào cấu trúc của bảng của bạn và làm thế nào là bình thường ...

Thông thường để thực hiện một Seacrh trong một truy vấn SELECT DBMS phân loại bảng (nó sử dụng mergesort bởi vì thuật toán này là tốt cho I/O trong đĩa, không quicksort) sau đó tùy thuộc vào chỉ mục (nếu bảng có) nó chỉ phù hợp với số, nhưng nếu cấu trúc phức tạp hơn DBMS có thể thực hiện tìm kiếm trong một cây, nhưng điều này quá sâu, hãy để tôi nghiên cứu lại trong các ghi chú của tôi.

Tôi khuyên bạn nên kích hoạt kế hoạch thực hiện truy vấn, here is an example trong cách thực hiện trong Sql Server 2008. Và sau đó thực hiện câu lệnh SELECT với mệnh đề WHERE và bạn sẽ có thể bắt đầu hiểu những gì đang xảy ra bên trong DBMS.

7

Nếu không có chỉ mục, thì có, tìm kiếm tuyến tính được thực hiện.

Nhưng, cơ sở dữ liệu thường sử dụng chỉ mục B Tree khi bạn chỉ định (các) cột làm khóa. Đây là những định dạng cấu trúc dữ liệu đặc biệt được điều chỉnh đặc biệt (các yếu tố phân nhánh cây B cao) để hoạt động tốt trên phần cứng đĩa từ, nơi yếu tố tiêu tốn thời gian đáng kể nhất là hoạt động tìm kiếm (đầu từ phải chuyển sang phần khác của tệp).

Bạn có thể xem chỉ mục dưới dạng bản sao được sắp xếp/có cấu trúc của các giá trị trong cột. Nó có thể được xác định nhanh chóng nếu giá trị được tìm kiếm nằm trong chỉ mục. Nếu nó tìm thấy nó, thì nó cũng sẽ tìm thấy một con trỏ trỏ ngược lại vị trí chính xác của hàng tương ứng trong tệp dữ liệu chính (vì vậy nó có thể đi và đọc các cột khác trong hàng). Đôi khi một chỉ mục nhiều cột chứa tất cả dữ liệu được truy vấn yêu cầu, và sau đó nó không cần phải bỏ qua trở lại tệp chính, nó chỉ có thể đọc những gì nó tìm thấy và sau đó nó được thực hiện.

Có các loại chỉ mục khác, nhưng tôi nghĩ bạn có ý tưởng - sao chép dữ liệu và sắp xếp nó theo cách nhanh chóng tìm kiếm.

Trên cơ sở dữ liệu lớn, các chỉ mục tạo sự khác biệt giữa việc đợi một phần giây, so với các ngày có thể để truy vấn phức tạp hoàn thành.

btw- B của cây không phải là một cấu trúc dữ liệu đơn giản và dễ hiểu, và thuật toán traversal cũng phức tạp. Ngoài ra, traversal thậm chí còn xấu hơn hầu hết mã bạn sẽ tìm thấy, bởi vì trong cơ sở dữ liệu chúng liên tục tải/dỡ khối dữ liệu từ đĩa và quản lý nó trong bộ nhớ, và điều này làm xấu đáng kể mã. Nhưng, nếu bạn đã quen thuộc với binary search trees, thì tôi nghĩ bạn hiểu rõ khái niệm này.

5

Vâng, nó phụ thuộc vào cách dữ liệu được lưu trữ và bạn đang cố gắng làm gì.

  • Như đã được chỉ ra, cấu trúc chung để duy trì mục nhập là B+ tree. Cây được tối ưu hóa tốt cho đĩa vì dữ liệu thực tế chỉ được lưu trữ trong lá - và các phím được lưu trữ trong các nút bên trong. Nó thường cho phép một số lượng rất nhỏ các truy cập đĩa kể từ đầu mức k của cây có thể được lưu trữ trong RAM, và chỉ có một vài cấp dưới cùng sẽ được lưu trữ trên đĩa và yêu cầu một đĩa đọc cho mỗi.
  • Cách thay thế khác là hash table. Bạn duy trì trong bộ nhớ (RAM) một mảng của "con trỏ" - những con trỏ này chỉ ra một địa chỉ đĩa, trong đó có một thùng chứa tất cả các mục có giá trị băm tương ứng. Sử dụng phương pháp này, bạn chỉ cần O(1) truy cập đĩa (thường là nút cổ chai khi giao dịch với các cơ sở dữ liệu), vì vậy nó phải tương đối nhanh.
    Tuy nhiên, bảng băm không cho phép truy vấn phạm vi hiệu quả (có thể được thực hiện hiệu quả trong cây B +).

Bất lợi của tất cả những điều trên là yêu cầu một khóa duy nhất - tức là nếu bảng băm hoặc cây B + được tạo theo trường "id" của mối quan hệ, và sau đó bạn tìm kiếm theo "khóa "- nó trở nên vô dụng.
Nếu bạn muốn đảm bảo tìm kiếm nhanh chóng cho tất cả các trường của quan hệ - bạn sẽ cần một số cấu trúc, mỗi cấu trúc theo một khóa khác - không phải là rất hiệu quả về bộ nhớ.

Bây giờ, có nhiều tối ưu hóa được xem xét theo mức sử dụng cụ thể. Ví dụ: nếu số lượng tìm kiếm được mong đợi là rất nhỏ (nói loglogN nhỏ hơn tổng số op), việc duy trì cây B + tổng thể kém hiệu quả hơn, chỉ lưu trữ các phần tử dưới dạng danh sách và vào dịp hiếm hoi tìm kiếm - chỉ cần thực hiện tìm kiếm tuyến tính.

Các vấn đề liên quan