TA貢獻1776條經驗 獲得超12個贊
如果這樣橫著拆會影響某些查詢，也可以考慮豎著拆。如果有一些大字段的話，最好把大字段單獨拆出一張表來，一般大字段只有查單條紀錄的時候才會用到，拆出大字段后，源表的查詢消耗io會減少很多
TA貢獻1843條經驗 獲得超7個贊
建議主要考慮80%常用到的查詢，剩余較少的查詢條件使用到的字段，先不要建立索引，試一下吧。
在制造企業中100W+的數據表是很常見的。但索引要建到20多個的就少見了，
如果真得需要，建議使用覆蓋索引。
TA貢獻1869條經驗 獲得超4個贊
硬件允許的話 用兩個數據庫 做讀寫分離 可以有效的緩解問題。
或者不一定非得在數據庫中解決所有問題吧 可以試試在程序中增加緩存層， ?查詢盡量在緩存中進行， 寫入則讓相應的緩存失效。
TA貢獻1772條經驗 獲得超8個贊
有沒有看看什么是瓶頸？磁盤IO ？CPU耗時？? 最好在profile里面查看一下。
不知道你數據庫的硬件配置，從這個數據量來看，數據文件和索引文件都很大，可能IO是瓶頸，考慮一下這部分數據是否可以放SSD硬盤，再增加內存，能緩解IO瓶頸。? 這個是從硬件角度處理
還有，可以考慮調整某些字段。我的經驗，字符型字段比較耗性能。如果有些字段存的是字符，但是這些字符又是標準的選項，那可以考慮將這字段換為int型，指向標準選項的索引。這個是從軟件角度處理
再，你表的主鍵是啥類型？
TA貢獻1801條經驗 獲得超16個贊
個人認為最開始的數據架構就沒做好。
一個表放100W條數據，操作，查詢都訪問這個表肯定影響效率。最好是做分割。10W量級的為一個表（或者單獨的數據庫。）。那么100W數據就變成10個表來存儲了。另外單獨建立一個庫 這個庫只保存用戶最索引ID 如 userid ?tableid .通過這個目錄庫來決定用戶要訪問和操作的的表。就是分布式管理，我語言表達差，就是這個意思。什么緩存都是浮云，緩存需要消耗大量的硬件資源的。
舉報