目前表結構大致如下
comment:
id int(11), //自增主鍵
uid int(11), //發評論人id
aid int(11), //文章id
content text,
hot int(11),
time datetime
用的innodb引擎，索引大小 15G，資料大小 25G
應用場景：
hot更新非常頻繁，文章詳情頁會按aid篩選并按hot和time排序取前n條評論。
前端已經對每條評論資料做了快取，大部分讀操作都命中快取了，只有hot排序取條時要讀mysql，但也對結果做了短時間的快取。
后臺有like關鍵詞搜索評論內容的功能，也有按uid和aid精確查找的功能
自己的一點思路：
將content欄位單獨拆到新表用id與之關聯，讓comment表變小從而提高hot排序的效率
對于分表我比較保守，擔心分了以后篩選排序操作會變困難
還有其它方面的優化請大家補充
uj5u.com熱心網友回復：
1、使用率較低的欄位放一起，較高放一起。2、只能在資料層做快取嘛？可否在應用層做？
uj5u.com熱心網友回復：
關鍵字搜索建議用全誩檢索，或者是流行的一些全文檢索處理方法，這個資料庫中的效率不會高剩下的是精確檢索，在你的描述中， aid 多次出出現了，建議考慮按這個磁區，這樣檢索的時候通控制在某個小資料量的磁區上
對于 按hot和time排序取前n條評論 的問題， 如果你的 host 更新通常是新的，那就是和 time 最新有關聯，那么按照 time 分表可以考慮，這樣需要的資料都在近期的表中
uj5u.com熱心網友回復：
對于是否要分表我比較糾結，感覺1億資料量對mysql來說不算非常大，更擔心是分完表對業務的負面影響會大于收益，可能以后的操作都要引入一些中間件才能完成了，也可能我的思路有點保守了
uj5u.com熱心網友回復：
這就設計到索引的設計，其中包括區分度，最左前綴等等，最近個人微信公眾號更新了一系列這樣的文章。我在個人微信公眾號《andyqian》等你來撩，轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/105103.html
標籤：MySQL
上一篇：用MYSQL撰寫以下資料庫陳述句