|
Задавайте вопросы, мы ответим
Вы не зашли.
Вопрос решен 
можно закрыть тему )
Отредактированно shipunoff (16.07.2024 23:17:02)
Неактивен
1. Навскидку индекс (owner,dressed,tab,stack,prototype) тоже должен работать. Сравнивайте explain, смотрите какая часть индекса используется; обновите статистику индексов; разбивайте запрос на простые части и тестируйте.
2. В первом подзапросе с группировкой i.id и i.action_time будут выбраны произвольными внутри группы. Кроме того в режиме ONLY_FULL_GROUP_BY сервер выдаст ошибку на этот запрос.
Неактивен
shipunoff написал:
было 60 предметов в инвентаре нормально было, сейчас купил предметы, 980 у меня предметов, дык он выбирает всё из shop 1022 строки ALL
Если условию соответствует существенная часть таблицы, то быстрей прочитать последовательно всю таблицу, а не прыгать по индексу. Это вполне нормальное поведение.
Неактивен
shipunoff написал:
А этот вот запрос с индексом (owner,dressed,tab,prototype), без stack.
Записей выбирает меньше 908 из 980.
rows показывает оценочное значение. Т.е. кол-во строк, которые будут прочитаны по предположению сервера.
Вы можете посмотреть сколько строк реально соответствуют этому условию, выполнив запрос без группировки, сортировки и т.д. Если реальное значение сильно отличается, то попробовать обновить статистику индексов, или, если не поможет, использовать подсказки оптимизатору, указав необходимый индекс (с последним нужно быть осторожней).
Неактивен
shipunoff написал:
Еще вопрос такой по explain, куда всё же смотреть для оптимизации запроса, в ROWS (чем меньше тем лучше) или в filtered ?
В идеале ROWS (чем меньше, тем лучше), FILTERED (чем больше, тем лучше).
ROWS это кол-во строк, которые будут прочитаны.
FILTERED показывает % от ROWS, который будет выбран.
Кроме того FILTERED помогает в сложных запросах, например, в explain из первого сообщения, где в первой строке для таблицы i: ROWS 61, FILTERED 10 означает, что со следующей таблицей s будет соединяться ~ 6 строк.
Важно смотреть и на другие поля и на порядок соединения таблиц.
shipunoff написал:
Да и еще по поводу Extra, бывает оно пустое даже при rows = 1, если оно пустое, что это значит, плохой запрос или хороший ?
Только то, для данного запроса нет дополнительной информации, которую бы оптимизатор мог сообщить.
shipunoff написал:
Гуглю каждый день, почти, все пишут по разному и от чего отталкиваться даже и не знаю
Лучше от документации. Хорошее объяснение explain на русском есть в книге Шварц Б., Зайцев П., Ткаченко В. и др. "MySQL. Оптимизация производительности" (2-е издание). Есть в сети.
Неактивен
Не получится ответить на этот вопрос, мало данных (я даже не понимаю сколько записей в таблице inventory 750 440 или 980).
Добиваться макс производительности нужно для тех запросов, которые создают нагрузки или проблемы.
И почему MyISAM? В 5.7 уже целенаправленно развивали InnoDB.
Неактивен
