Сколько букв нужно для поиска в индексе
Что проверяют
Понимаете ли вы, какой индекс какой поиск ускоряет. За детским на вид вопросом стоит проверка: знаете ли вы, что обычный индекс работает только по префиксу, и откуда вообще взялось привычное правило «искать от трёх символов».
Как отвечать
Сначала разделить случаи. B-tree индекс годится для точного совпадения и для префикса: WHERE name LIKE 'ab%' превращается в сканирование диапазона и работает хоть с одной буквой, просто чем короче префикс, тем шире диапазон и тем больше строк придётся прочитать. Для подстроки в середине (LIKE '%ab%') B-tree бесполезен вообще, и никакая длина запроса этого не исправит.
Дальше про три буквы. В PostgreSQL подстрочный поиск обычно делают через pg_trgm и GIN, а триграмма это ровно три символа: на одном-двух символах индекс перестаёт отсекать что-либо полезное и планировщик уходит в полный проход. У полнотекстового индекса InnoDB в MySQL минимальная длина токена по умолчанию тоже три символа, всё короче просто не попадает в индекс. Отсюда и продуктовое соглашение: подсказки включаются от трёх символов.
В сервисе на Go к этому добавляется своя часть ответственности: минимальную длину запроса и дебаунс держат в обработчике, а context пробрасывают в драйвер, чтобы отменённый пользователем поиск не догружал базу впустую.
Где спотыкаются
Отвечают одним числом, «от трёх», как будто это свойство любого индекса. Это настройка полнотекстового поиска и продуктовое правило, а не закон базы данных.
Второе: вешают обычный индекс и ждут, что заработает поиск по подстроке. Туда же относится регистронезависимость: запрос через lower(name) не попадёт в индекс по name, нужен индекс по выражению или подходящая коллация.
Третье: считают задачу решённой на стороне базы. Пользователь печатает быстро, и без дебаунса и отмены запросов на каждую букву уходит отдельный поиск, а база получает нагрузку, которую никакой индекс не спасёт.