MySQL連表查詢(xún)分組去重的實(shí)現(xiàn)示例
業(yè)務(wù)邏輯
通過(guò)多種渠道將小程序的活動(dòng)頁(yè)鏈接發(fā)布出去,比如通過(guò)多多種短信附帶鏈接( channel 就記為 sms1,sms2,sms3 ),或者海報(bào)上面貼微信小程序的二維碼( channel 記為 qrcode1,qrcode2,qrcode3 ),線(xiàn)下會(huì)員通過(guò)掃描二維碼也能進(jìn)入小程序指定的活動(dòng)頁(yè),亦或者是通過(guò)其他會(huì)員分享的小程序鏈接也可以進(jìn)入小程序( channel 記為 share)。這些不同的進(jìn)入方式在我這篇文章統(tǒng)稱(chēng)為不同的渠道,也就是提到的 channel 字段。從不同的渠道進(jìn)入活動(dòng)頁(yè)就會(huì)產(chǎn)生一條頁(yè)面訪(fǎng)問(wèn)記錄。會(huì)被計(jì)入 page_view 這張表里。
會(huì)員進(jìn)入小程序的指定活動(dòng)頁(yè)后,在頁(yè)面上面觸發(fā)一系列操作后,會(huì)得到相應(yīng)的反饋,比如獲得積分,或者獲得優(yōu)惠券等等。這步操作稱(chēng)為參與活動(dòng)。這條數(shù)據(jù)會(huì)被記入 activity_record 這張表里。
現(xiàn)在呢,運(yùn)營(yíng)小姐姐要求得到一份數(shù)據(jù)報(bào)表。每位參與活動(dòng)的會(huì)員是從什么時(shí)間,哪個(gè)渠道里面進(jìn)活動(dòng)的?
數(shù)據(jù)表結(jié)構(gòu)
表名 | member_id | participate_time |
---|---|---|
activity_record | 會(huì)員號(hào) | 活動(dòng)參與時(shí)間 |
表名 | member_id | channel | view_time |
---|---|---|---|
page_view | 會(huì)員號(hào) | 渠道 | 頁(yè)面訪(fǎng)問(wèn)時(shí)間 |
查詢(xún)邏輯
因?yàn)槊课粫?huì)員只能參加一次活動(dòng),也就是活動(dòng)期間只能獲得過(guò)一次積分,或者領(lǐng)取過(guò)一次優(yōu)惠券等等這種意思,也就是每位會(huì)員最多只會(huì)產(chǎn)生一條 activity_record 記錄。
可是 page_view 這張表的記錄方式就不一樣了。會(huì)員可能既收到過(guò)短信鏈接,又掃描過(guò)活動(dòng)二維碼,又被好友分享過(guò)活動(dòng)鏈接,這下,對(duì)于這位會(huì)員來(lái)說(shuō),就會(huì)產(chǎn)生多條頁(yè)面訪(fǎng)問(wèn)記錄,即在 page_view 里產(chǎn)生多條數(shù)據(jù)。
你想想,會(huì)員肯定是先通過(guò)某一個(gè)渠道進(jìn)入到活動(dòng)頁(yè)面,才能去參加活動(dòng)。也就是有多條 page_view 的數(shù)據(jù),按照 view_time 倒序排列,總有一條的 view_time 是小于且最接近于 activity_record 的 participate_time,下一條 page_view 的 view_time 就會(huì)大于 activity_record 的 participate_time。
SQL腳本
select c.member_id,c.view_time,.channel from ( SELECT member_id, SUBSTRING_INDEX( GROUP_CONCAT( view_time ORDER BY view_time DESC ), ',', 1 ) AS view_time, SUBSTRING_INDEX( GROUP_CONCAT( channel ORDER BY channel DESC ), ',', 1 ) AS channel FROM page_view a LEFT JOIN activity_record b on a.member_id = b.member_id where a.view_time < b.participate_time GROUP BY member_id) c;
腳本說(shuō)明
- GROUP_CONCAT:通過(guò)使用distinct可以排除重復(fù)值; group_concat( [distinct] 要連接的字段 [order by 排序字段 asc/desc ] [separator '分隔符'] )
- SUBSTRING_INDEX:字符串截取函數(shù)。substring_index(str,delim,count)。str:要處理的字符串;delim:分隔符;count:計(jì)數(shù)
到此這篇關(guān)于MySQL連表查詢(xún)分組去重的實(shí)現(xiàn)示例的文章就介紹到這了,更多相關(guān)MySQL連表查詢(xún)分組去重內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
超簡(jiǎn)單的qps統(tǒng)計(jì)方法(推薦)
下面小編就為大家?guī)?lái)一篇超簡(jiǎn)單的qps統(tǒng)計(jì)方法(推薦)。小編覺(jué)得挺不錯(cuò)的,現(xiàn)在就分享給大家,也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2017-03-03Navicat連接mysql報(bào)錯(cuò)2003(10060)的解決方法
本來(lái)好好的navicat連接數(shù)據(jù)庫(kù),突然間今天就打不開(kāi)數(shù)據(jù)庫(kù)了,下面這篇文章主要給大家介紹了關(guān)于Navicat連接mysql報(bào)錯(cuò)2003(10060)的解決方法,文中通過(guò)圖文介紹的非常詳細(xì),需要的朋友可以參考下2023-04-04使用Canal和Kafka解決MySQL與緩存的數(shù)據(jù)一致性問(wèn)題
這篇文章主要介紹了使用Canal和Kafka解決MySQL與緩存的數(shù)據(jù)一致性問(wèn)題,文中通過(guò)圖文結(jié)合的方式給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作有一定的幫助,需要的朋友可以參考下2024-07-07MySQL查詢(xún)出現(xiàn)1055錯(cuò)誤的原因及解決方法
Mysql在使用過(guò)程中經(jīng)常遇到錯(cuò)誤,都是本人在實(shí)際應(yīng)用中處理檢驗(yàn)過(guò)的,本文對(duì)常見(jiàn)錯(cuò)誤出現(xiàn)的代碼進(jìn)行詳細(xì)分析,下面這篇文章主要給大家介紹了關(guān)于MySQL查詢(xún)出現(xiàn)1055錯(cuò)誤的原因及解決方法,需要的朋友可以參考下2023-05-05MySQL實(shí)現(xiàn)創(chuàng)建存儲(chǔ)過(guò)程并循環(huán)添加記錄的方法
這篇文章主要介紹了MySQL實(shí)現(xiàn)創(chuàng)建存儲(chǔ)過(guò)程并循環(huán)添加記錄的方法,涉及基本的mysql存儲(chǔ)過(guò)程創(chuàng)建、調(diào)用相關(guān)操作技巧,需要的朋友可以參考下2017-05-05SQL分頁(yè)查詢(xún)存儲(chǔ)過(guò)程代碼分享
本文主要分享了SQL分頁(yè)查詢(xún)存儲(chǔ)過(guò)程的具體實(shí)例代碼,具有一定的參考價(jià)值,需要的朋友一起來(lái)看下吧2016-12-12MySQL主從復(fù)制之半同步semi-sync?replication
這篇文章主要介紹了MySQL主從復(fù)制之半同步semi-sync?replication,半同步相對(duì)于異步復(fù)制而言,提高了數(shù)據(jù)的安全性,同時(shí)也造成了一定程度的延遲,這個(gè)延遲最少是一個(gè)TCP往返的時(shí)間。所以,半同步復(fù)制最好在低延時(shí)的網(wǎng)絡(luò)中使用,下文詳細(xì)內(nèi)容,需要的小伙伴可以參考一下2022-02-02MySQL與存儲(chǔ)過(guò)程的相關(guān)資料
這篇文章主要介紹了MySQL與存儲(chǔ)過(guò)程的相關(guān)資料,需要的朋友可以參考下2007-03-03