Câu trả lời:
Nói chung, có một sự đánh đổi giữa "chính xác" và "thu hồi". Độ chính xác cao có nghĩa là ít kết quả không liên quan được trình bày (không có kết quả dương tính giả), trong khi thu hồi cao có nghĩa là thiếu kết quả liên quan ít hơn (không có phủ định sai). Sử dụng toán tử THÍCH cung cấp cho bạn độ chính xác 100% mà không cần nhượng bộ. Một công cụ tìm kiếm toàn văn cho phép bạn linh hoạt để điều chỉnh độ chính xác để thu hồi tốt hơn.
Hầu hết các triển khai tìm kiếm toàn văn đều sử dụng "chỉ mục đảo ngược". Đây là một chỉ mục trong đó các khóa là các thuật ngữ riêng lẻ và các giá trị được liên kết là các bộ bản ghi có chứa thuật ngữ. Tìm kiếm toàn văn bản được tối ưu hóa để tính toán giao điểm, liên kết, v.v. của các bộ bản ghi này và thường cung cấp thuật toán xếp hạng để định lượng mức độ mạnh mẽ của một bản ghi đã cho khớp với từ khóa tìm kiếm.
Toán tử SQL THÍCH có thể cực kỳ kém hiệu quả. Nếu bạn áp dụng nó cho một cột không được lập chỉ mục, quét toàn bộ sẽ được sử dụng để tìm kết quả khớp (giống như bất kỳ truy vấn nào trên trường không được lập chỉ mục). Nếu cột được lập chỉ mục, việc khớp có thể được thực hiện đối với các khóa chỉ mục, nhưng với hiệu quả thấp hơn nhiều so với hầu hết các tra cứu chỉ mục. Trong trường hợp xấu nhất, mẫu THÍCH sẽ có các ký tự đại diện hàng đầu yêu cầu mọi khóa chỉ mục được kiểm tra. Ngược lại, nhiều hệ thống truy xuất thông tin có thể cho phép hỗ trợ các ký tự đại diện hàng đầu bằng cách biên dịch trước các cây hậu tố trong các trường được chọn.
Các tính năng khác điển hình của tìm kiếm toàn văn bản là
FTS liên quan đến việc lập chỉ mục các từ riêng lẻ trong một trường văn bản để giúp tìm kiếm nhanh qua nhiều bản ghi. Sử dụng THÍCH vẫn yêu cầu bạn thực hiện tìm kiếm chuỗi (tuyến tính hoặc tương tự) trong trường.
MySQL tạo một chỉ mục từ các từ của cột tìm kiếm toàn văn bản được kích hoạt và thực hiện tìm kiếm trên chỉ mục này. MySQL sử dụng một thuật toán tinh vi để xác định các hàng khớp với truy vấn tìm kiếm.
Ngoài ra, từ câu trả lời SO này :
Có một vài lợi thế để tìm kiếm toàn văn.
Lập chỉ mục:
Cái gì đó như:
WHERE Foo LIKE '%Bar';Không thể tận dụng một chỉ số. Nó phải xem xét từng hàng một và xem nó có khớp không. Một chỉ mục fulltext, tuy nhiên, có thể. Trên thực tế, các chỉ mục fulltext có thể mang lại sự linh hoạt hơn rất nhiều về thứ tự các từ khớp, mức độ gần nhau của các từ đó, v.v.
Xuất phát:
Một tìm kiếm fulltext có thể bắt nguồn từ. Nếu bạn tìm kiếm để chạy, bạn có thể nhận được kết quả cho "đã chạy" hoặc "đang chạy". Hầu hết các công cụ fulltext có từ điển gốc trong nhiều ngôn ngữ.
Kết quả có trọng số:
Một chỉ mục fulltext có thể bao gồm nhiều cột. Ví dụ: bạn có thể tìm kiếm "bánh đào" và chỉ mục có thể bao gồm tiêu đề, từ khóa và nội dung. Kết quả phù hợp với tiêu đề có thể có trọng số cao hơn, vì phù hợp hơn và có thể được sắp xếp để hiển thị gần đầu trang.
Nhược điểm:
Một chỉ mục toàn văn bản có thể có khả năng rất lớn, lớn hơn nhiều lần so với chỉ số B-TREE tiêu chuẩn. Vì lý do này, nhiều nhà cung cấp lưu trữ cung cấp phiên bản cơ sở dữ liệu sẽ vô hiệu hóa tính năng này hoặc ít nhất tính phí thêm cho tính năng này. Ví dụ: lần trước tôi đã kiểm tra, Windows Azure không hỗ trợ truy vấn fulltext.
Chỉ mục Fulltext cũng có thể chậm hơn để cập nhật. Nếu dữ liệu thay đổi nhiều, có thể có một số chỉ số cập nhật độ trễ so với chỉ mục tiêu chuẩn.
Giống như chỉ sử dụng ký tự đại diện và không mạnh mẽ như vậy.
Toàn văn cho phép tìm kiếm phức tạp hơn nhiều, bao gồm And, Hoặc, Không, thậm chí kết quả âm thanh tương tự (SOUNDEX) và nhiều mục khác.
Tôi sẽ bắt đầu xem xét SQL CONTAIN () FREETEXT () và các mục tìm kiếm Toàn văn có liên quan để giúp hiểu rõ hơn về những gì có sẵn.
Sự khác biệt thực sự là phương pháp quét. Đối với tìm kiếm toàn văn bản, các từ (thuật ngữ) được sử dụng làm khóa băm - mỗi từ được liên kết với một mảng tài liệu mà các khóa (thuật ngữ) xuất hiện. Giống như thế này:
Document sets = {d1, d2, d3, d4, ... dn}
Term sets = {t1, t2, t3, .. tn}Bây giờ ma trận tài liệu thuật ngữ (thành viên hạn của tài liệu nào) có thể được biểu diễn dưới dạng:
t1 -> {d1, d5, d9,.. dn}
t2 -> {d11, d50, d2,.. dn}
t3 -> {d23, d67, d34,.. dn}
:
tn -> {d90, d87, d57,.. dn}Khi yêu cầu đến yêu cầu "Nhận cho tôi tất cả các tài liệu có chứa từ / thuật ngữ t1" - thì bộ tài liệu {d1, d5, d9,.. dn} được trả về.
Bạn có thể hack lược đồ bảng không chuẩn hóa để lưu trữ tài liệu - mỗi hàng trong bảng MySQL sẽ được coi là "tài liệu" và một cột văn bản có thể chứa một đoạn, v.v. Chỉ mục đảo ngược sẽ chứa các thuật ngữ dưới dạng khóa băm và id hàng như id tài liệu.
Hãy nhớ rằng truy vấn SQL này sẽ có hiệu suất O (1) nhiều hơn hoặc ít hơn. Truy vấn sẽ độc lập với
Chẳng hạn, SQL này có thể được kích hoạt để trích xuất tất cả các hàng khớp với từ đã cho XYZ:
SELECT *
FROM my_table
WHERE MATCH (my_text_column) against ('XYZ' IN boolean mode) ;Hãy cẩn thận: Nếu bạn thêm ORDER BY vào truy vấn này, thời gian chạy của bạn sẽ thay đổi dựa trên một số tham số, một trong số đó là số lượng hàng / tài liệu phù hợp. Cẩn thận.
Tuy nhiên, THÍCH không có gì về điều này. Nó buộc phải quét tuyến tính câu / chuỗi và tìm tất cả các thuật ngữ phù hợp. Thêm thẻ hoang dã thêm vào sự lộn xộn. Nó hoạt động tuyệt vời cho các chuỗi có độ dài nhỏ, như bạn có thể tưởng tượng, nhưng sẽ thất bại thảm hại cho các câu dài hơn. Và chắc chắn không thể so sánh khi có một đoạn văn hoặc toàn bộ trang văn bản, v.v.
FTS hiệu quả hơn, mạnh mẽ hơn (đặc biệt là đối với Word Breakers và các chức năng phát sinh) ... nhưng hãy kiểm tra các yêu cầu của bạn vì đôi khi DB không hỗ trợ tất cả các ngôn ngữ, ví dụ MSSQL không hỗ trợ tiếng Hy Lạp (kiểm tra trên trang này http: // msdn. microsoft.com/en-us/l Library / ms176076 (v = sql.110 ) .aspx )