舉個例子如一張消息表 結構如些 Id （自增主鍵） Content(內容) UserId(說話人Id) IsWonderful(是否是精彩發言) Top(是否置頂) IsBarrage( 是否是彈幕) 當這個結構的表 數據還少時取 經常發言 置頂發言 和彈幕 速度比較快 但是數據一多 30多萬條的時 ...
舉個例子如一張消息表
結構如些 Id （自增主鍵） Content(內容) UserId(說話人Id) IsWonderful(是否是精彩發言) Top(是否置頂) IsBarrage( 是否是彈幕)
當這個結構的表 數據還少時取 經常發言 置頂發言 和彈幕 速度比較快
但是數據一多 30多萬條的時候查找數據
37w條數據 中查找經常發言
用時4.753 秒
雖然加上索引之後可以找0.1秒鐘找到數據 但是每加一個索引 寫入速度就變慢一點 後面還有 彈幕置頂也要查找 豈不是都要加索引 這樣寫入非常慢尤其是這樣表寫入頻繁的情況下,更說明這張表的設計有很大的問題
這樣時候在在建一張表 結構是
Id 主鍵
Type 類型 1-精彩發言 2-置頂，3-彈幕
ChatMessageId 消息表Id
接下來 用事實驗證的時候了
接下來 我們看下分析
完美的利用了已經存在的主鍵索引
在37w條數據 中找到經常發言只用了0.0001秒 而且也沒增加新的索引 怎麼看到這裡是不是若有所思了
以後設計資料庫的時候不要老想的增加新的索引（除非寫入和改變很少的情況下） 儘量利用自帶的主鍵索引
