Я вижу, что в SQL GROUP BY должен предшествовать выражению ORDER BY. Означает ли это, что упорядочение выполняется после группировки, отбрасывающей идентичные строки / столбцы?

Поскольку мне, кажется, нужно сначала упорядочить строки по столбцу A временной метки, ТО, отбрасывая строки с одинаковым значением в столбце A. Не уверен, как это сделать ...

Я использую MySQL 5.1.41

create table
(
    A int,
    B timestamp
)

Данные могут быть:

+-----+-----------------------+
|  A  |  B                    |
+-----+-----------------------+
|  1  |  today                |
|  1  |  yesterday            |
|  2  |  yesterday            |
|  2  |  tomorrow             |
+-----+-----------------------+

Результаты, к которым я стремлюсь, будут:

+-----+-----------------------+
|  A  |  B                    |
+-----+-----------------------+
|  1  |  today                |
|  2  |  tomorrow             |
+-----+-----------------------+

По сути, мне нужны строки с самой последней отметкой времени в столбце B (например, ORDER BY) и только одной строкой для каждого значения в столбце A (например, DISTINCT или GROUP BY).

Мои реальные детали проекта, если вам нужны эти:

В реальной жизни у меня есть две таблицы -users а такжеpayment_receipts.

create table users
(
    phone_nr int(10) unsigned not null,
    primary key (phone_nr)
)

create table payment_receipts
(
    phone_nr int(10) unsigned not null,
    payed_ts timestamp default current_timestamp not null,
    payed_until_ts timestamp not null,
    primary key (phone_nr, payed_ts, payed_until_ts)
)

Таблицы могут включать в себя другие столбцы, я опустил все, что IMO здесь не имеет значения. Как часть схемы мобильных платежей, я должен отправлять SMS-сообщения пользователям через мобильную сотовую сеть через определенные промежутки времени, в зависимости, конечно же, от того, должен ли платеж быть или нет. Платеж актуализируется при отправке SMS, которое облагается налогом. Я веду учет всех платежей, совершенных сpayment_receipts таблица, для бухгалтерии, которая имитирует реальный магазин, где и покупатель, и продавец получают копию квитанции о покупке, для справки. В этой таблице хранятся мои (продавцы) копии каждой квитанции. Квитанция клиента - это само полученное SMS. Каждый раз, когда отправляется SMS (и, таким образом, выполняется платеж), в таблицу вставляется запись квитанции с указанием, кто заплатил, когда и «до когда». Чтобы объяснить последнее, представьте себе услугу подписки, которая действует неограниченно долго, пока пользователь явно не откажется, после чего запись пользователя будет удалена. Оплата производится за месяц, поэтому, как правило, разница междуpayed_ts а такжеpayed_until_ts 30 дней стоит времени.

Естественно, у меня есть пакетное задание, которое выполняется каждый день, и мне нужно выбрать список пользователей, которые должны платить ежемесячно в рамках автоматического продления подписки. Чтобы связать это с фиктивным примером ранее, столбец номера телефонаphone_nr являетсяa а такжеpayed_until_ts являетсяb, но в реальном коде есть две таблицы, которые приводят меня к следующему поведению и его последствиям: когда пользовательская запись удаляется, квитанция остается для учета. Таким образом, мне нужно не только сгруппировать платежи по дате и отменить все, кроме самой последней даты поступления платежа, мне также нужно следить за тем, чтобы не выбирать квитанции, для которых больше нет соответствующей пользовательской записи.

Я решаю проблему выбора записей, которые подлежат оплате, находя квитанции с последнейpayed_until_ts значение (так как в большинстве случаев будет несколько квитанций для каждого номера телефона) для каждогоphone_nr и из этих строк мне нужно оставить только те номера телефона, гдеpayed_until_ts раньше, чем время выполнения пакетного задания. Я перебираю список этих номеров и отправляю платежи, сохраняя новую квитанцию ​​для каждого отправленного SMS, гдеpayed_ts являетсяnow() а такжеpayed_until_ts являетсяnow() + interval 30 days.