數據類型和schema優化

數據類型的優化

合理使用范式和反范式

三大范式：
1、表不可分
2、不能存在傳遞依賴
3、表里其他列的值必須唯一依賴于主鍵

約定大于規范，沒有必要嚴格遵守范式，以業務為準，需要取舍。有時候空間換時間，沒有明確的標準。

• 如果排序操作命中了索引，就不需要加載進內存中排序了，效率更高

主鍵的選擇

自然主鍵

充當主鍵的字段本身具有一定的含義，是構成記錄的組成部分，比如學生的學號，除了充當主鍵之外，同時也是學生記錄的重要組成部分。

代理主鍵（推薦使用）

就是充當主鍵的字段本身不具有業務意義，只具有主鍵作用，比如UUID，主鍵生成器（有自己的生成策略），自增id

字符集的選擇

utf-8會有只能存2個字節的中文的情況，有的中文是不能存的，因此建議使用utf8mb4
man utf-8

存儲引擎的選擇

存儲引擎：數據文件的組織形式

my.ini 配置文件默認是Innodb

在mysql剛開始誕生的時候，并沒有innodb引擎，用的是myisam引擎，它不支持事務。
innodb引擎后來被創造之后，一開始是以插件的形式運行的，但是在5.5版本之后，默認使用的是innodb存儲引擎。

適當的書數據冗余

視圖：Oracle有物化視圖（數據更新能夠及時更改）
數據冗余要保證修改時的一致性！（可以用觸發器）

適當拆分

當我們的表中存在類似于 TEXT 或者是很大的 VARCHAR類型的大字段的時候，如果我們大部分訪問這張表的時候都不需要這個字段，我們就該義無反顧的將其拆分到另外的獨立表中，以減少常用數據所占用的存儲空間。

這樣做的一個明顯好處就是，每個數據塊中可以存儲的數據條數可以大大增加，既減少物理 IO 次數，也能大大提高內存中的緩存命中率。

數據庫的拆分是非常麻煩的，以后我們講mycat的時候再詳細說。

執行計劃

https://hanquan.blog.csdn.net/article/details/106935632

《阿里這十年》這本書可以隨便看看

索引為什么用B+數

• hash表不適合范圍查詢
• 8.0之后沒有查詢緩存了，為什么？
• 索引下推是啥？
• 畫一個知識腦圖

.idb是數據文件和索引文件存在一起
.myd是數據文件
.myi是索引文件

索引基本知識

附：MySQL8.0為什么取消了查詢緩存

MySQL 8.0: Retiring Support for the Query Cache
MySQL服務器團隊有一篇關于此的詳細博客，其中Matt Lord說：

盡管MySQL Query Cache旨在提高性能，但它存在嚴重的可伸縮性問題，并且很容易成為嚴重的瓶頸。
自MySQL 5.6（2013）以來，默認情況下已禁用查詢緩存，因為眾所周知，它不能與多核計算機上在高吞吐量工作負載情況下進行擴展。
我們考慮了可以對查詢緩存進行哪些改進，以及我們可以進行的優化，這些優化可以改善所有工作負載。

雖然這些選擇本身是正交的，但工程資源是有限的。也就是說，我們正在轉變戰略，投資于更普遍適用于所有工作負載的改進。

建議把緩存放到客戶端

“Client + 2x ProxySQL”結果顯示，在將緩存移動到客戶端時，性能提高了5.2倍。

總結

以上是生活随笔為你收集整理的MySQL调优（二）：数据类型和schema优化，MySQL8.0取消查询缓存的原因的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。