最近做IM的時候遇到一個問題，同時用到了這三個關(guān)鍵字。就是查詢一個人的離線消息詳情，我們服務(wù)端返回給客戶端顯示的這個詳情包括了三個內(nèi)容，第一個要求列出離線這段時間哪些人或者群給你發(fā)了消息，第二個這其中的某個人或者群發(fā)了多少條離線消息，第三個拿出最新的一條顯示出來。很明顯，group by分組哪些人或者群給你發(fā)了離線消息，count()得到離線消息數(shù)量，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 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;


我們可以對已經(jīng)排序的結(jié)果集，再來分組并計算數(shù)量。這里還有一個暗坑，我自己不小心給躲過去了，其實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其實是根本沒有排序的結(jié)果，也就是數(shù)據(jù)庫原順序，應(yīng)該是先插入的一條消息，就是說時間舊的消息。為了避免這個問題，所以嵌套子查詢在這里先排序，再讓它去count()就規(guī)避了。自己無意躲過去了，還好反復(fù)改語句測試了一番才發(fā)現(xiàn)。