Почему если по запросу в бд что-то найдено, то запрос выполняется быстрее?

Question

[viktorross]

Здравствуйте, подскажите, почему по моему запросу в mysql если что-то находится, то обработка занимает пол секунды максимум, а если ничего не найдено то 3 секунды, как это исправить можно?

select class_q.*, class_q.id as adid, date_format(class_q`date_added`,'%d.%m в %H:%i') as date_nice, date_format(class_q.`date_expires`,'%d.%m в %H:%i') as date_expires_nice, UNIX_TIMESTAMP(class_q.`date_added`) as `time_added`, (class_q.date_expires < '2022-01-12 04:32:50' and class_q.date_expires!='0000-00-00 00:00:00' and class_q.active=0) as expired
		, class_slugs.slug 
		
		from class_q
		  
		inner join class_slugs on class_q.id=class_slugs.object_id
		  where class_q.active=1  and ( lower(q.title) REGEXP '[[:<:]]test[[:>:]]'  ) and class_slugs.`type`='q'  order by  `p` desc,  date_added  desc  limit 0, 26;

Comments

[Sergey]

Где EXPLAIN запроса?

[FanatPHP]

Sergey, серьёзно? и что вы там собираетесь обнаружить такого, что не лежит прямо кишками наружу в запросе?

[Akina]

FanatPHP, а я согласен с предыдущим оратором.

В зависимости от статистики при разных критериях выборки планировщик может выбирать разный порядок сканирования таблиц, и неудивительно, что один из них оказывается более производительным, чем другой. Может, нужен вульгарный STRAIGHT_JOIN...

Вот и хотелось бы увидеть EXPLAIN двух запросов, с разными критериями и сильным различием во времени выполнения. Для подтверждения (или нет) гипотезы.

Ну и вообще, плакаться на производительность, и при этом не дать ни CREATE TABLE, ни EXPLAIN (я уж молчу о статистике данных) - это как-то непрофессионально.

[FanatPHP]

Akina, верно. но при этом в итоге всё сведётся к выборке первых 500 строк (или сколько там выдает муадмин по умолчанию) )))

[Akina]

FanatPHP, дык у него всё равно там LIMIT 0, 26, пофиг на ограничения пыхадмина. И опять же MySQL при наличии ORDER BY сперва выбирает всё, а потом сортирит и лимитит.

[FanatPHP]

Akina, да дело не в том что у него, а в том что лимит в его тестах всегда есть, даже когда он его не видит
а вот про сортировку я не подумал. тогда действительно непонятно

Answer 1

[galaxy]

Скорее всего, потому, что в первом случае читается меньшая часть таблиц, а во втором - все целиком.
Уберите LIMIT - будет примерно одинаково (если результатов много - то и значительно медленнее)

Comments

[viktorross]

galaxy спасибо, но не вышло, тоже самое почему-то

[galaxy]

viktorross, phpmyadmin? У него неявный limit

Answer 2

[FanatPHP]

патамушта пхпмуадмин

чтобы исправить, надо избавиться от адского говнокода с REGEXP '[[:<:]]test[[:>:]]'
и идиотского lower()

Comments

[viktorross]

FanatPHP да вот пробовал заменить regexp на like, и на = тоже, lower удалял, время увеличилось почему-то на 1,5 секунды, я скажу так, перепробовал все, убирал inner join, т.е делал запрос только в одну таблицу, все равно, не понятно в чем тут дело, самое главное что смысл этого запроса по сути получить совпадения вот тут

and ( lower(q.title) REGEXP '[[:<:]]test[[:>:]]'  )

и это работает очень быстро если ничего не добавлять, но даты тоже нужны, причем даты я убирал из этого запроса, бесполезно, работает в общем если только оставить только это, explain смотрел, там ничего полезного, 102 тысячи строк под сортировку попадет

[FanatPHP]

"пробовать всё" не надо
надо не "пробовать" а делать, и не "всё", а только один вариант - по-человечески
без лайков, без регекспов и без идиотского lower

[viktorross]

FanatPHP, так а чем заменить like или regexp, ведь тут идет поиск по тексту

[FanatPHP]

Скорее всего поиск идет не по тексту, а по каким-то терминам, то есть надо переделать кривую структуру БД
в случае же если действительно нужен полнотекстовый поиск, то либо добавить полнотекстовый индекс, либо использовать внешний поисковый сервис.