Если вы не хотите использовать полнотекстовый индекс, и я бы посоветовал вам провести сравнительный анализ, чтобы определить, не влияет ли индекс на производительность вставки, вы можете реструктурировать свои данные, чтобы исключить необходимость в такого рода поисках.
Мы не знаем, что в ticket_id
, но ясно, что у него какая-то структура. Вместо анализа и поиска этого объединения лучше разбить его на отдельные части и объединить.
Чтобы использовать аналогичный пример, давайте рассмотрим адреса электронной почты. Что делать, если вы хотите искать пользователей, чьи адреса электронной почты для gmail.com
? Наивный способ сделать это будет ...
create table users (
id serial primary key,
email varchar(255) not null unique
);
select * from users
where email like '%@gmail.com'
Есть проблема с производительностью. Также существует проблема соответствия user@subdomain.gmail.com
. like '%gmail.com'
приносит свои проблемы, он будет соответствовать person@thingmail.com
.
Вместо этого, используя сгенерированные столбцы , мы можем отделить домен от адреса электронной почты и проиндексировать его.
create table users (
id serial primary key,
email varchar(255) not null unique,
domain varchar(255) as (
substring_index(substring_index(email, '@', -1), '.', -2)
),
index(domain)
);
Теперь сопоставление домена - это простая индексированная проверка на равенство.
select * from users
where domain = 'gmail.com'
Я полагаю, вы можете сделать что-то подобное для своего ticket_id
. Стоит ли это усилий, требует некоторого тестирования, а также учета сложности: полнотекстовый индекс проще и гибче.
dbfiddle