Відповіді:
Взагалі існує компроміс між "точністю" та "відкликанням". Висока точність означає, що подано менше неактуальних результатів (відсутні помилкові позитиви), тоді як висока відкликання означає, що менше релевантних результатів відсутня (відсутні помилкові негативи). Використання оператора LIKE забезпечує 100% точність без поступок на відкликання. Функція пошуку повного тексту надає вам велику гнучкість для налаштування точності для кращого нагадування.
Більшість повнотекстових пошукових програм використовують "перевернутий індекс". Це індекс, де ключами є окремі терміни, а пов'язані значення - це набори записів, що містять цей термін. Повнотекстовий пошук оптимізований для обчислення перетину, об'єднання тощо цих наборів записів і, як правило, забезпечує алгоритм ранжування для кількісної оцінки того, наскільки сильно заданий запис відповідає ключовим словам пошуку.
Оператор SQL LIKE може бути надзвичайно неефективним. Якщо застосувати його до неіндексованого стовпця, для пошуку збігів буде використаний повний скан (як і будь-який запит у неіндексованому полі). Якщо стовпець індексується, відповідність може бути виконана проти індексних ключів, але з значно меншою ефективністю, ніж більшість пошукових записів індексу. У гіршому випадку, модель LIKE матиме провідні символи, які вимагають перевірити кожен індексний ключ. На відміну від цього, багато систем пошуку інформації можуть увімкнути підтримку провідних символів, попередньо склавши дерева суфіксів у вибраних полях.
Інші функції, характерні для повнотекстового пошуку, є
FTS включає в себе індексацію окремих слів у текстовому полі, щоб швидкий пошук через багато записів. Використання LIKE все ще вимагає від вас пошуку рядків (лінійних чи подібних) у полі.
MySQL створює індекс із слів увімкненої повнотекстової колонки пошуку та здійснює пошук за цим індексом. MySQL використовує складний алгоритм для визначення рядків, відповідних пошуковому запиту.
Також з цієї відповіді ТА :
Існує кілька переваг для повного пошуку тексту.
Індексація:
Щось на зразок:
WHERE Foo LIKE '%Bar';Неможливо скористатися індексом. Він повинен переглянути кожен ряд і побачити, чи відповідає він. Повний індекс, однак, може. Насправді, повнотекстові індекси можуть запропонувати набагато більшу гнучкість у частині порядку узгодження слів, наскільки тісні ті слова є разом тощо.
Стовбування:
Повний текст пошуку може спричинити слова. Якщо ви шукаєте запуск, ви можете отримати результати для "біг" або "біг". Більшість двигунів повного тексту мають стовбурові словники на різних мовах.
Зважені результати:
Індекс повного тексту може охоплювати декілька стовпців. Наприклад, ви можете шукати "персиковий пиріг", а індекс може містити назву, ключові слова та тіло. Результати, що відповідають заголовку, можуть бути зважені вище, як більш релевантні, і можуть бути відсортовані для показу біля верху.
Недоліки:
Повнотекстовий індекс потенційно може бути величезним, у багато разів більшим, ніж стандартний індекс B-TREE. З цієї причини багато розміщених провайдерів, які пропонують екземпляри бази даних, відключають цю функцію або принаймні стягують її за неї. Наприклад, востаннє я перевірив, що Windows Azure не підтримує повнотекстові запити.
Індекси повного тексту також можуть повільніше оновлюватись. Якщо дані сильно змінюються, можуть бути деякі індекси оновлення відставання порівняно зі стандартними індексами.
Начебто використовує лише підстановку, і не все це потужно.
Повний текст дозволяє набагато складніше шукати, включаючи And, Or, Not, навіть подібні результати звучання (SOUNDEX) та багато інших елементів.
Я б почав переглядати SQL CONTAINS () FREETEXT () та пов'язані з ними елементи повного тексту, щоб допомогти краще зрозуміти, що є в наявності.
Справжня різниця полягає в методології сканування. Для повнотекстового пошуку слова (терміни) використовуються як хеш-ключі - кожен з яких асоціюється з масивом документів, в яких відображаються ключі (терміни).
Document sets = {d1, d2, d3, d4, ... dn}
Term sets = {t1, t2, t3, .. tn}Тепер матриця терміна-документа (який член члена цього документа) може бути представлена як:
t1 -> {d1, d5, d9,.. dn}
t2 -> {d11, d50, d2,.. dn}
t3 -> {d23, d67, d34,.. dn}
:
tn -> {d90, d87, d57,.. dn}Коли запит надходить із запитом "Отримати мені всі документи, що містять слово / термін t1" - тоді {d1, d5, d9,.. dnповертається набір документів }.
Ви можете зламати денормалізовану схему таблиці для зберігання документів - кожен рядок у таблиці MySQL вважатиметься «документом», а стовпець TEXT може містити абзац тощо. як ідентифікатор документа.
Пам'ятайте, що цей SQL-запит матиме більш-менш продуктивність O (1). Запит буде незалежним від
Наприклад, цей SQL може бути запущений для отримання всіх рядків, що відповідають заданому слову XYZ:
SELECT *
FROM my_table
WHERE MATCH (my_text_column) against ('XYZ' IN boolean mode) ;Caveat: Якщо ви додасте ORDER BY до цього запиту, час виконання буде змінюватися залежно від кількох параметрів, один з яких - кількість відповідних рядків / документів. Тож остерігайтеся.
Однак LIKE нічого з цього не має. Він змушений лінійно сканувати речення / рядок і знаходити всі відповідні терміни. Додавання шаблону додає безладдя. Це добре підходить для рядків невеликої довжини, як ви можете собі уявити, але вийде з ладу для довших пропозицій. І, безумовно, не можна порівняти, якщо є абзац або ціла сторінка тексту тощо.
FTS є більш ефективним, потужним (особливо для Word Breakers та стримуючих функціональних можливостей) ... але перевірте свої вимоги, оскільки іноді БД не підтримують усі мови, наприклад MSSQL не підтримує грецьку (перевірте на цій сторінці http: // msdn. microsoft.com/en-us/library/ms176076(v=sql.110).aspx )