Давайте рассмотрим три основных случая отдельно. Это обсуждение относится к MySQL, но может также применяться к другим СУБД, поскольку индексы обычно реализуются аналогичным образом.
LIKE 'foo%' выполняется быстро, если выполняется на индексированном столбце. Индексы MySQL являются разновидностью B-деревьев, поэтому при выполнении этого запроса он может просто спуститься по дереву до узла, соответствующего foo или первый узел с этим префиксом, и пройти через дерево вперед. Все это очень эффективно.
LIKE '%foo' не может быть ускорено индексами и приведет к полному сканированию таблицы. Если у вас есть другие критерии, которые могут быть выполнены с использованием индексов, он будет сканировать только те строки, которые остались после начальная фильтрация.
Хотя есть хитрость : если вам нужно сопоставить суффиксы - например, поиск имен файлов с расширением .foo - вы можете добиться той же производительности, добавив столбец с тем же содержимым, что и исходный, но с символами в обратном порядке.
ALTER TABLE my_table ADD COLUMN col_reverse VARCHAR (256) NOT NULL;
ALTER TABLE my_table ADD INDEX idx_col_reverse (col_reverse);
UPDATE my_table SET col_reverse = REVERSE(col);
Поиск строк с col, заканчивающимся .foo, затем становится:
SELECT * FROM my_table WHERE col_reverse LIKE 'oof.%'
Наконец, есть LIKE '%foo%', для которого нет ярлыков. Если нет других ограничивающих критериев, которые уменьшают количество строк до допустимого числа, это приведет к серьезному снижению производительности. Возможно, вы захотите рассмотреть решение для полнотекстового поиска или другое специализированное решение.