功能介紹：
支援管理員發布、刪除、檢視公告資訊，支援使用者檢視公告並標記出已讀/未讀狀態。
設計思路：
首先設計公告表t_notice，使用noticeid作為主鍵並使用uuid作為預設生成規則，包含公告內容noticecontent、公告發布時間noticepublishtime。
其次設計關係表t_relation，使用relationid作為主鍵並使用uuid作為預設生成規則，包含noticeid、userid。
已讀/未讀實現原理：
通過t_relation表裡是否包含的資料來判斷使用者是否檢視過該公告。
主要場景分析：
管理員建立公告，使用者讀取公告，t_relation表中生成一條記錄。
管理員刪除公告，開啟資料庫事務，首先刪除t_notice表中的公告，其次刪除t_relation表中對應的資料，事務結束。
ps：
起初讀取公告歷史記錄（包含使用者讀取狀態）時，獲取對應pagesize的t_notice資料，並在for中迴圈查詢獲取該使用者是否讀取過這些公告，這樣有了n+1次資料庫的操作
dto findonebyuseridandnoticeid(string userid, string noticeid)
優化：
批量返回t_relation資料，避免多次運算元據庫。
list findbyuseridandnoticeidin(string userid, list noticeids)
這時候涉及到兩個list的取值問題，可以簡單的使用兩次for迴圈解決，時間複雜度是n^2，我採用的是將返回的資料轉化為map，noticeid作為key，假如能從map中取到值則已讀，反之未讀，時間複雜度為2*n。
記錄一次sql優化查詢
場景 關聯查詢，一張主表關聯4張表進行查詢。主表資料量是16萬，其中被關聯的一張表的數量是6萬。遇到頁面響應速度過慢的情況，首先考慮是否是sql查詢緩慢引起的。第一步開啟mysql的慢查詢日誌 網上教程很多，本篇文章不再贅述 第二步分析慢查詢日誌，這裡要說下分析工具。常用的有兩種，一是mysql自帶...
一次優化記錄
備註 由於隱私 部分使用了偽 偽sql 直接查十點查全部 select from 使用者優惠券表 where 優惠券id in select id from 優惠券表 where 限制 新使用者 and 90天內 總時間40 秒 這裡用exlpain分析 優惠券id是有索引的，但是實際上沒有走索引。...
一次優化記錄
今天收到乙個同事的求助，說有乙個sql跑了乙個多小時沒有結果。我看了看，這個sql是這樣的 隱藏了敏感資訊 select 號碼,列2,列3,max starttime flag from 表1 t1 where flag 0 and 號碼 not in select 號碼 from 表2 t2 gr...