Продолжая тему оптимизации SQL запросов. Есть таблица пользователей и есть запрос, который ищет по этой таблице:
SELECT поля FROM Members WHERE LastName LIKE @lastname and PostalCode = @postalcode
Индекс на поле LastName существует и работает. Если в качестве параметра передать 'Doe%', то запрос возвращает строки мгновенно и без проблем. Но стоит передать в качестве параметра 'rodriguez%' как запрос умирает напрочь. Умирает только на этой фамилии. Я тестировал сотни других, но они работают отлично.
Несколько программистов уже билось над этим запросом и никто не может определить магию фамилии rodriguez для этой таблицы. В базе данных всего две записи и обе принадлежат одному человеку, но запрос умирает.
Самое интересное, что если убрать из фамилии хотя бы одну букву и передать в качестве параметра 'rodrigue%' (без буквы z на конце), то запрос работает мгновенно. У меня объяснения этой магии нет.
Кто-нибудь встречался с такими приколами SQL Server?
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
А после rodriguez в значении есть что-нибудь?
Есть символ %. Запрос, который умирает:
а может он так реагирует на последовательность z%' ?
Не, я про само значение поля в таблице, а не про запрос.
В базе данных именно 'rodriguez'. Изменили LIKE на равенство и убрали %, и запрос свистит, но пользователи иногда хотят иметь возможность искать по не полной фамилии. Вот теперь из-за одного мексикано-американо страдаю.
Ну, если ему не нарвится только последняя z, то как тупой вариант, если пришел запрос c последней z, то в sql вставлять без последней буквы :) хы-хы :) вот он как индусский код-то получается :)
Буква z точно не причем, потому что следующий запрос работает меньше секунды:
Решил использовать следующий запрос:
может дело в кодировках?
попробовал у себя SELECT *
FROM `my_users`
WHERE `username` LIKE 'rodriguez%'
запрос занял 0.0028 сек.
юзаю utf8
CREATE SCRIPT для индекса и для всей таблицы в студию
2Lebnik
В другой таблице запрос по этой же фамилии выполняется в любых вариантах быстро.
2iVitar
Можешь поверить мне, что индекс существует. Если запрос '%rodriguez%' выполняется 1 секунду на таблице с миллионами записей, то индекс есть. Вопрос - почему 'rodriguez%' выполняется пол часа?
Верю. А скрипт все-таки хотелось бы увидеть.
Иначе обсуждение беспредметно.
Если верить плану выполнения запроса, то используется этот индекс
Есть идея что у разработчиков SQL был такой враг и они решили сделать проклятие =D.
Конечно могу предложить наиглупейший вариант, но когда выхода совсем нет, может вручную вытащить Родригесов? Выполнить запрос подождать часик узнать id и потом если пользователю нужно выполнение "LIKE '%rodriguez%'" То дать заранее извесные результаты. Это конечно совсем не выход для программиста и наиболее бестолковое решение, но мне нужно что то написать... =))
rebuild Index случаем не пробовали?
И индексы перестроил, и статистику пересчитывал, ничего не помогает.
Можно сделать дубликат таблицы и проверить как будет на нем.
У нас уже есть несколько копий базы данных, и на всех, кроме одной тот же самый эффект. На одной копии для тестеров этот запрос почему-то работает быстро. Хотя индексы и все абсолютно такое же как на рабочем сервере.
Речь именно о дубликате таблицы (одинаковая структура и данные), а не базы целиком. Если проблема с таблицей, то новая не должна тормазить.
А почему все бакапы тормозят, а один нет. Кстати, тот который НЕ тормозит на родригесе находится на самом слабом из серверов. Таблица тут явно не причем. Проблема могла быть в фрагментации или плохой статистике, но и это уже проверено.
На postgresql сей баг не наблюдается...
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
