Добрый день!

Есть 2 таблицы: A и B
Таблица А имеет следующие колонки: id, parent, child
Таблица B: id, a_id, update_date

Нужно выбрать 3 последних (по id) записи для нужного нам parent , при этом еще и maх(update_date) для них из таблицы B.

Вот что получилось:

SELECT
(SELECT id FROM a WHERE id = b.a_id) AS id,
(SELECT child FROM a WHERE id = b.a_id) AS child,
max(update_date) AS update_date
FROM b
WHERE a_id IN (
SELECT max(id)
FROM a
WHERE parent = 'test'
GROUP BY child
)
GROUP BY id_a
ORDER BY update_date DESC
LIMIT 3;

Но, запрос получился очень нагруженным - порядка 0.2-0.5с (думаю из-за IN ). Есть смутные сомнения, что можно сделать проще (может через UNION), но не сображу как. Может будут какие-то идеи, как упростить этот изврат)
Спасибо!

Добрый Э - Эхagrobee,

З.Ы.
в общем, основной посыл ты, надеюсь,понял? для начала прочитай все топовые топики в факами. если не найдешь ответы на свои вопросы - возвращайся в форум и спрашивай....

Я так понимаю, вы предлагаете реализовать запрос с использованием переменных? Ранее использовал переменные только в хранимых процедурах, опыта использования в запросах нет. Прочитал топики, нашел даже на хабрахабре тему "Оптимизация запросов MySQL с использованием пользовательских переменных", изучил ее, но с реализацией применительно к моему вопросу по-прежнему сложности.

Вот что получилось у меня




У меня таблицы с колонками немного другие, поэтому мог ошибиться при написании варианта, что выше.
Правда так и не уверен в правильности логики запроса, хотя скорость реально в 5-10 раз и выросла.

Нужно взять 3 последних записи из таблицы А (определяем по id) и последнюю запись для каждой из них из таблицы B (определяем по update_date)

Ругается на то, что в


не определена колонка A.id

Полагаю, там z.id имелось ввиду.
Наверное то, что надо! Спасибо!

javajdbc,

Да, скорость хорошая. Но только результат не тот :) Показывает три строчки с одинаковыми child, а должны быть все разные. Видимо, я неправильно описал задачу.

Эхх, щас как опишу задачу в художественной форме! :)

Вот слушайте.
Поле боя. Каждый боец сам за себя. У каждого бойца есть автомат. Из автомата можно стрелять только очередью. Очередь может состоять минимум из одной пули, максимум теоретически не ограничен. Выпускать очередь можно только в других бойцов на поле, и больше никуда. Одной очередью поразить более одной цели нельзя, но цели можно менять, начиная новую очередь. Перед тем, как давать очередь, нужно обязательно выбрать цель — другого конкретного бойца. И вот на поле боя бойцы стреляют друг в друга очередями. Месиво, короче говоря :)

В базе данных это месиво описывается у нас следующим образом:
1. Таблица q — "Очереди"
1.1. Поле id — идентификатор очереди (автоинкремент)
1.2. Поле shooter — "Стрелок" — боец, выпускающий очередь пуль
1.3. Поле target — "Цель" — боец, в которого стрелок выпускает очередь пуль

2. Таблица b — "Пули"
2.1. Поле id — идентификатор пули (автоинкремент)
2.2. Поле q_id — идентификатор очереди, из которой эта пуля
2.3. Поле time — время вылета пули
2.4. Поле damage — урон, нанесённый цели этой пулей


Задача:
По этим двум таблицам составить запрос, выясняющий:
1) В каких трёх последних бойцов (разных бойцов) стрелял заданный стрелок.
2) При этом для каждого из трёх бойцов узнать:
а) время последней вылетевшей в него пули,
б) урон, который нанесла эта пуля,
в) из какой очереди (id) была эта пуля

То есть, таблица-результат должна состоять из трёх строк и следующих четырёх столбцов:
1) r_target
2) r_time
3) r_damage
4) r_q_id

Строки таблицы должны располагаться в обратном порядке, то есть, начиная с последнего бойца, в которого он стрелял.
Идентификатор пули не участвует в запросе, от него ничего не зависит, его можно отбросить.

Такая вот задачка.
На самом деле у меня тут нет никаких бойцов и никакого месива, просто так понятнее должно быть :)


Решение, в общем-то, уже есть, только скорость запроса не устраивает.
20-40 миллисекунд, а хотелось бы 2-4 :)
Вот оно, это решение, работающее правильно, но его нужно усовершенствовать по скорости:

javajdbc...если (если!) последняя по времени пуля в таргет
однозначно приходит из последней по ИД очереди в таргет, то
обрезку ЛИМИТ 3 последние поули можно упростить
на две независимые задачи:
1. поиск 3-х последний очередей по последним 3-м таргетам
2. поиск последних пуль.

вы имеете 20 мс потому что сначала идет джоин а потом обрезка по 3-м последним

если условие вверху выполняется, то уберите джоин внутри
и найдите 3 последние очереди ТОЛЬКО из таблицы КУ
апотом повторите для последних пуль в уже выбраных очередях
(которых всего 3)

если у вас много очередей и пуль, то такой двойной подход может
(но не обязательно) ускорить запрос.
Забыл, забыл один момент описать. Автомата, автомата-то ТРИ! :) То есть, теоретически, один автомат может стрелять одну очередь от самого начала игры и до самого конца. В общем, не получится так разделить задачу на две.

javajdbcкроме переменых, задачу можно решить и другими способами как во втором ФАК-е.
будет ли ето быстрее -- вопрос для проверки
Угу, почитаю, спасибо.

javajdbcпо любому имеет смысл сделать ЕКСПЛЕЙН и выставить
сюда на обсуждение. у вас и связки и филтры и сортировка..
есть потенциал для оптимизации
Сделаю.

javajdbcесли б вы смогли денормализовать (специально излишне добавить)
колонки ТРАГЕТ и СОУРСЕ в таблицу пуль, то все было в шоколаде...
Воооот! Это то, что я предлагаю руководителю, но он никак не соглашается пока добавлять ещё колонки :) Буду работать над этим :)

javajdbc...а еще бы колонку с флажком ДА/НЕТ "последняя пуля" --
...да правильный составной индекс -- шоколад с орешками!
Так, ну составной индекс это после эксплейна, я так понимаю. А флажок "последняя пуля", получается, надо снимать с предпоследней пули, когда вылетает новая последняя, так?

Вот эксплейн по запросу:




Читаю ФАКи...

Вот вариант с дополнительными полями, о котором я изначально думал.

Если в таблицу "q" добавить два дополнительных поля:
1) галочку "последняя очередь в данную цель" - "last_target_q",
2) ссылку на последнюю пулю в данной очереди - "last_b_id",
то запрос можно сделать такой:




Я думаю, такой запрос будет работать ооочень быстро. Как думаете?
А чтобы галочка last_target_q корректно обновлялась, перед тем, как начинать новую очередь, нужно выполнять следующее:




Тоже довольно быстро будет получаться, мне кажется.
А после вылета новой пули, сразу отмечать её в очереди:



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