powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / странно ведет себя индекс в запросе
18 сообщений из 18, страница 1 из 1
странно ведет себя индекс в запросе
    #38796528
MargaritaM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте!

есть два запроса:

explain SELECT id_p1_espn, id_p2_espn, count(*)
FROM espncricinfo.innings
where IsValidBall = 1
AND runs_count > -1
AND id_p1_espn > -1
AND id_p2_espn > -1
GROUP BY id_p1_espn, id_p2_espn
having count(*)>50

и


explain SELECT *
FROM espncricinfo.innings
where IsValidBall = 1
AND runs_count > -1
AND id_p1_espn > -1
AND id_p2_espn > -1
GROUP BY id_p1_espn, id_p2_espn
having count(*)>50


в о втором случае работает без индекса,долго-долго, в первом с индексом... НО, индекс, который используется в первом, выглядит следующим образом:
1. IdMatch
2.id_p1_espn
3.id_p2_espn
4.runs_count
5.IsValidBall


почем оно использует этот индекс?! на сколько я понимаю, индекс берется, если поля в нем в том же порядке, что и в условии where, т.е. должно было бы быть where idMatch = 1 and id_p1_espn и т.д....


или я чего-то не понимаю?... хорошо, тогда почему со * оно не использует его? или он считает во втором как покрывающий его? но все равно, тут даже нет поля IdMatch которое идет ПЕРВЫМ в индексе...
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796534
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MargaritaMпочем оно использует этот индекс?!В этом индексе есть все поля, которые используются в первом запросе. Поэтому он может быть использован как покрывающий индекс. В этом случае происходит чтение данных из индекса вместо чтения из таблицы. Объем индекса меньше, чем объем таблицы, поэтому чтение происходит быстрее. Кроме того, если движок MyISAM, то индекс может быть закэширован в кэше индексов, тогда как содержимое таблицы MyISAM не кэширует, т.е. придется полагаться на внешние по отношению к MySQL кэши, такие как кэш файловой системы и т.п.
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796588
MargaritaM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft, ну я так и подумала, про покрывающий, но была раньше уверена, что ВСЕ индексы подчиняются одинаковым правилам на счет порядка условий в where, не важно покрывающий или нет... Ну, по крайней мере не покрывающие, подчиняются же ему? а то может я совсем ничего не знаю)
тогда хорошо, что нам мешает просто сделать громадный индекс из наиболее популярных полей и чтобы он для большинства запросов был покрывающим и все?... ну кроме замедления записи..
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796612
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MargaritaMВСЕ индексы подчиняются одинаковым правилам на счет порядка условий в whereВсе индексы, которые оптимизатор просматривает на предмет ускорения доступа к данным в таблице. Т.е. это не сам индекс такой "покрывающий", это оптимизатор может использовать индексы в разных ролях. И один и тот же индекс в разных запросах может использоваться как обычном способом - для ускорения доступа к данным, так и как покрывающий.
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796617
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MargaritaMчто нам мешает просто сделать громадный индекс из наиболее популярных полей и чтобы он для большинства запросов был покрывающим и все?... ну кроме замедления записи..Иногда так и делают, когда индексный доступ к данным невозможен в силу самого запроса (например, LIKE '%подстрока%'), а таблица очень широкая, т.е. в ней много полей, которые не нужны в данном запросе.
Причем иногда делают один индекс из нескольких полей, а иногда несколько индексов по одному полю, а иногда в комбинации - зависит от фактически выполняемых запросов и от требований к их быстродействию.
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796801
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MargaritaMпочем оно использует этот индекс?! на сколько я понимаю, индекс берется, если поля в нем в том же порядке, что и в условии where , т.е. должно было бы быть where idMatch = 1 and id_p1_espn и т.д....


или я чего-то не понимаю?... хорошо, тогда почему со * оно не использует его? или он считает во втором как покрывающий его? но все равно, тут даже нет поля IdMatch которое идет ПЕРВЫМ в индексе...

Вот выделенное и не понимаешь.

Порядок следования термов в WHERE (и HAVING) не имеет никакого значения, что вполне логично, потому что все булевы операции коммутативны .

Для "индекс берётся" нет каких-то фиксированных логических правил -- оптимизатор считает стоимости нескольких возможных планов и берёт тот, у которого стоимость меньшая. Другой логики в общем не существует.
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796818
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivДля "индекс берётся" нет каких-то фиксированных логических правилВообще-то есть. В Оракле это называется rule-based optimizer. В MySQL нет отдельного понятия для этого, но кое-какие правила все равно есть. И стоимость считается только для тех индексов, которые прошли проверку этими правилами, если таковые индексы остались.
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796826
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftMasterZivДля "индекс берётся" нет каких-то фиксированных логических правилВообще-то есть. В Оракле это называется rule-based optimizer. В MySQL нет отдельного понятия для этого, но кое-какие правила все равно есть. И стоимость считается только для тех индексов, которые прошли проверку этими правилами, если таковые индексы остались.

Уже давно его нет даже в оракле, великом и ужасном.
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796830
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MargaritaM,

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
SELECT *
FROM espncricinfo.innings
where IsValidBall = 1
  AND runs_count > -1
  AND id_p1_espn > -1
  AND id_p2_espn > -1
GROUP BY id_p1_espn, id_p2_espn
having count(*)>50




Эх, ЯростногоМеча на вас нет.
Он бы не постеснялся, погразил бы вам
палчиком за неагрегатную звездочку
в агрегатном запросе.
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796877
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivПорядок следования термов в WHERE (и HAVING) не имеет никакого значенияиндекс на (x,y)
1) where x=const1 and y>const2
2) where y=const1 and x>const2
Никакого значения, да... или речь была вообще о чём-то другом?
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796958
MargaritaM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ох, спасибо большое за информацию, пойду сокрушаться собственной безграмотности)

tanglir индекс на (x,y)
1) where x=const1 and y>const2
2) where y=const1 and x>const2
Никакого значения, да... или речь была вообще о чём-то другом?

И об этом в том числе. Я, глупая женщина, была уверена что имеет значение порядок. Иначе, зачем тогда создавать избыточные индексы например, если порядок не важен?... просто один из них для оптимизатора дешевле будет?...

авторЭх, ЯростногоМеча на вас нет.
Он бы не постеснялся, погразил бы вам
палчиком за неагрегатную звездочку
в агрегатном запросе.

а если мне все столбцы надо?))


miksoftТ.е. это не сам индекс такой "покрывающий", это оптимизатор может использовать индексы в разных ролях
ну это да, я понимаю... по крайне мере хотя бы это))

но, допустим, взял он этот индекс как покрывающий, запрос летает, все счастливы, все танцуют) но, получается,для запроса со * он посчитал, что ему дешевле полностью просканировать таблицу, чем воспользоваться этим индексом?

Нет, я все не могу понять, откуда в моей голове взялась уверенность в связи порядка в индексе и в условии... еще и начальнику втирала с умным лицом, позорище!))) а в старых каких-нибудь версиях такого не было никогда? не могла же я приснить...
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796964
Диклевич Александр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tanglirMasterZivПорядок следования термов в WHERE (и HAVING) не имеет никакого значенияиндекс на (x,y)
1) where x=const1 and y>const2
2) where y=const1 and x>const2
Никакого значения, да... или речь была вообще о чём-то другом?

речь была о
1) where x=const1 and y>const2
1) where y>const2 and x=const1
как я понимаю.
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38796970
MargaritaM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Диклевич Александр,
ну да, я просто не обратила внимание, имелось ввиду именно 1) where x=const1 and y>const2
1) where y>const2 and x=const1
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38797138
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MargaritaMно, допустим, взял он этот индекс как покрывающий, запрос летает, все счастливы, все танцуют) но, получается,для запроса со * он посчитал, что ему дешевле полностью просканировать таблицу, чем воспользоваться этим индексом?Да, потому что для запроса со * этот индекс не является покрывающим.
MargaritaMимелось ввиду именно 1) where x=const1 and y>const2
1) where y>const2 and x=const1Ну тут-то, понятное дело, разницы нет. А в моём примере - есть (впрочем, как выяснилось, пример был не в тему).
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38797394
MargaritaM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
tanglir,

вы меня запутали!)
авторMasterZiv
Порядок следования термов в WHERE (и HAVING) не имеет никакого значения
индекс на (x,y)
1) where x=const1 and y>const2
2) where y=const1 and x>const2
Никакого значения, да...

т.е. вы говорите что в примере, который вы дали , нет разницы

и потом

автор
MargaritaM
имелось ввиду именно 1) where x=const1 and y>const2
1) where y>const2 and x=const1
Ну тут-то, понятное дело, разницы нет. А в моём примере - есть

говорите что в этом нет разницы, а вашем есть... так где разница есть-то и есть ли она вообще?!) в общем мало, видимо, теории в моем багаже, поду перечитывать умные книги)
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38797513
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MargaritaM,

1. Порядок отдельных условий в WHERE блоке значения
не имеет, а и b -- равнозначны
а) where x=const1 and y>const2
b) where y>const2 and x=const1

2. если условия изменились, то , возможно нужен
другой индекс, c и d не равнозначны
c) where x=const1 and y>const2
d) where y=const1 and x>const2

3. Запрос на * несовменстим с агрегации.
Уточните задачу и тогда будем думать над решением.
Так как вы это сделали смысла не имеет.
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38798058
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MargaritaMт.е. вы говорите что в примере, который вы дали , нет разницыВообще-то это был сарказм
...
Рейтинг: 0 / 0
странно ведет себя индекс в запросе
    #38798459
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Диклевич Александрtanglirпропущено...
индекс на (x,y)
1) where x=const1 and y>const2
2) where y=const1 and x>const2
Никакого значения, да... или речь была вообще о чём-то другом?

речь была о
1) where x=const1 and y>const2
1) where y>const2 and x=const1
как я понимаю.

Именно так.
...
Рейтинг: 0 / 0
18 сообщений из 18, страница 1 из 1
Форумы / MySQL [игнор отключен] [закрыт для гостей] / странно ведет себя индекс в запросе
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]