1樓：混血王子
和我的業務類似，但是我沒你這麼大的量。我覺得redis的部分保留，水平分表應該不錯的，另外統計部分用中間表統計。還有就是提供你乙個思路，order用mongodb來存可能好點
2樓：「已登出」
從你的問題描述上看可以使用分庫設計。首先單庫在1千萬時出現效能障礙。我們假設1千萬是單機單庫的效能極限。
可以使用6臺伺服器成對部署資料庫日誌轉移前滾，形成雙機讀寫分離轉移備份構成乙個基本的工作單元。6臺伺服器是3個基本儲存單元。通過你的描述。
業務邏輯查詢主要發起方式是客戶。。6臺伺服器要配置高精度ntp伺服器保持較高的時間同步。為時間欄位的排序提供基準。
3樓：晴天好心情
一千萬mysql是完全沒有問題的。
1、優化表結構欄位等
2、索引優化
3、主鍵
4、sql語句
4.5、redis快取
5、換更大的記憶體和SSD
6、表拆分
7、讀寫分離
8、業務拆分
以上，從小到大結合你們的業務邏輯進行優化。
4樓：
有使用者緯度查詢需求，我認為若要分表應該以使用者id來分。
領取記錄可以加密後快取在在客戶端，請求服務時候帶到服務端解密後就知道使用者領取記錄。金鑰不可採用固定金鑰。使用者相關資訊加鹽作為金鑰相對更好一些
5樓：thinkinnight
主要查詢請求：
判斷某個使用者是否領取過某個禮品（佔80%的查詢請求，現在用redis前面扛著）
查詢乙個時間段的領取記錄(最近三天內)
查詢某個禮品的領取記錄
查詢某個使用者的領取記錄
主要瓶頸在插入語句上面
首先問題感覺沒有描述清楚，你列出了主要的查詢需求，又說瓶頸在插入語句，到底是要鬧哪樣？至少要把插入語句插入的是什麼描述清楚吧？
是否是使用者領取禮物之後，進行插入？同時，你乙個使用者可以領多個禮物嗎？只是類別不同？到底業務是什麼，這裡的資料結構有經過特殊設計嗎？
資料庫僅僅是做持久化的，那有哪些是可以放到記憶體中，然後之後慢慢用佇列塞到資料庫中的，有哪些請求是可以提前判斷攔住的，不要都直接通到資料庫，這些都可以考慮。
6樓：靈劍
什麼應用這麼土豪，羅老師的聊天寶嗎……
你光知道這些是不夠的，你得知道有多少使用者，有多少禮物，平均每個使用者每天領取多少禮物，禮物被領取的時間序列是怎樣的（是長期有效還是短期有效），這些資料都會影響優化方向。
從經驗上來說，寫入的tps應該不是瓶頸，瓶頸是單表裡的資料太多了。而且本身有些請求就很匪夷所思，查詢三天內的領取記錄，一次返回一億條？這是要做什麼呢？還是得理一下業務邏輯。
還有乙個要首先檢查的是這個表是不是沒有自增id的主鍵？雖然業務上用不到，但自增id的主鍵能保證資料不亂插入，我記得還是有作用的。
7樓：任弘迪
每天3kw，1kw就扛不住了。。。是上線了就回滾嗎？
有個問題沒提到，分表了按非key查的打算怎麼處理？
如果業務接受只查3天的話冷熱分離就行，分表會很麻煩。
要不試試TiDB也行。
MySQL 對於千萬級的大表要怎麼優化？
架構師 每當看到這種問題，總有一大堆人在下邊回答不搭邊的東西，從網上copy 幾萬字的內容對於問題有意義嗎？言歸正傳，mysql單錶到達千萬級別確實會有效能瓶頸，不的不說免費的mysql效能和sqlserver，oracel差的太多了。至於優化，可以做一下幾點 1。網上都寫爛的分庫分表，但是也要根據...
Unity開發怎麼優化大量物體的物理碰撞而產生的FPS等引數急劇下降？
unity用的是nvidia的physx，但只是cpu端的，沒有gpu加速，而且physx的gpu加速本身侷限也很大 其他答主提到的compute shader和physx的gpu加速差不多只能做一些相對簡單的物理粒子模擬，在題主提到的如大量石子堆疊漏口的應用場景涉及比較複雜的力傳導，可能很難模擬得...
為什麼 MySQL 的優化器不能做智慧型的型別轉換
聿明leslie MySQL做得最靈活的就是資料型別，幾乎每種型別都可以做相容計算，相容計算帶來的壞處就是很多SQL寫得不嚴格的話，執行不會報錯，但是可能執行效率不會太好。SQL裡面的表示式計算和程式語言裡的型別計算是同乙個道理，要做計算前需要做相容型別提公升，只有提公升到相同型別才能做表示式運算，...