數(shù)據(jù)類型和schema優(yōu)化

數(shù)據(jù)類型的優(yōu)化

合理使用范式和反范式

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

約定大于規(guī)范，沒有必要嚴(yán)格遵守范式，以業(yè)務(wù)為準(zhǔn)，需要取舍。有時候空間換時間，沒有明確的標(biāo)準(zhǔn)。

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

主鍵的選擇

自然主鍵

充當(dāng)主鍵的字段本身具有一定的含義，是構(gòu)成記錄的組成部分，比如學(xué)生的學(xué)號，除了充當(dāng)主鍵之外，同時也是學(xué)生記錄的重要組成部分。

代理主鍵（推薦使用）

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

字符集的選擇

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

存儲引擎的選擇

存儲引擎：數(shù)據(jù)文件的組織形式

my.ini 配置文件默認是Innodb

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

適當(dāng)?shù)臅鴶?shù)據(jù)冗余

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

適當(dāng)拆分

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

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

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

執(zhí)行計劃

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

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

索引為什么用B+數(shù)

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

.idb是數(shù)據(jù)文件和索引文件存在一起
.myd是數(shù)據(jù)文件
.myi是索引文件

索引基本知識

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

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

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

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

建議把緩存放到客戶端

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。