MySQL の count()、group by、order by の詳細な説明

最近、IM を実行するときに、これらの 3 つのキーワードを同時に使用したときに問題が発生しました。これは、ある人物のオフライン メッセージの詳細を照会することです。サーバーからクライアントに返される詳細には、3 つの内容が含まれます。1 つ目は、オフライン期間中にどの人物またはグループがメッセージを送信したかを一覧表示することです。2 つ目は、特定の人物またはグループが送信したオフライン メッセージの数です。3 つ目は、最新のメッセージを表示することです。当然、オフライン メッセージを送信した人またはグループをグループ化し、count() でオフライン メッセージの数を取得し、時間順に並べ替えて最新のメッセージを取得します。

select count(1) as cnt, msg_data from t_im_chat_offline_msg where to_company_id = ? and to_user_id = ? order by create_time desc group by from_company_id, from_user_id;

すると、予想通り、group by と order by を一緒に検索するとエラーが発生します。ネストされたサブクエリを使用できます。

select count(1) as cnt, msg_data from (select * from t_im_chat_offline_msg where to_company_id = ? and to_user_id = ? order by create_time desc) as temp_table group by from_company_id, from_user_id;


すでにソートされた結果をグループ化して、その数を計算できます。ここには隠れた落とし穴がありますが、私は偶然それを避けてしまいました。実際、count() は order by ソートを無効にします。例えば:

select count(1) as cnt, msg_data from t_im_chat_offline_msg where to_company_id = ? and to_user_id = ? order by create_time desc;

このステートメントは最終的に、msg_data が実際にはまったくソートされていない、つまりデータベースの元の順序のレコードを取得します。これは最初に挿入されたメッセージ、つまり古いメッセージである必要があります。この問題を回避するには、ネストされたサブクエリを最初にソートし、次に count() を使用してこの問題を回避します。意図せずに回避しましたが、文を修正して何度もテストした後で発見しました。