1、寬表還是窄表？怎么做選擇？一張表多大合適？

??? 寬表

字段比較多的表，包含的維度層次比較多，造成冗余也比較多，毀范式設(shè)計(jì)，但是利于取數(shù)統(tǒng)計(jì)。適合做數(shù)據(jù)倉(cāng)庫(kù)、大數(shù)據(jù)等

? ? 窄表

往往對(duì)于OLTP比較合適，符合范式設(shè)計(jì)原則；就性能角度來(lái)講，一般窄表優(yōu)于寬表，而且窄表邏輯更加清晰。所以一般推薦用面向業(yè)務(wù)一般用窄表來(lái)實(shí)現(xiàn)。

那么究竟一張表多少字段合適呢？有沒(méi)有一個(gè)界限來(lái)判斷寬表還是窄表呢？

mysql的物理存儲(chǔ)結(jié)構(gòu)如下：

在計(jì)算機(jī)中磁盤(pán)存儲(chǔ)數(shù)據(jù)最小單元是扇區(qū)，一個(gè)扇區(qū)的大小是 512 字節(jié)，而文件系統(tǒng)（例如XFS/EXT4）他的最小單元是塊，一個(gè)塊的大小是 4k，而對(duì)于我們的 InnoDB 存儲(chǔ)引擎也有自己的最小儲(chǔ)存單元——頁(yè)（Page），一個(gè)頁(yè)的大小是 16K。

mysql物理存儲(chǔ)的結(jié)構(gòu)，由段-區(qū)-頁(yè)-行組成：

一個(gè)區(qū)是1M大小，由連續(xù)的64個(gè)16k的頁(yè)組成，每個(gè)頁(yè)又由N行組成。

在mysql內(nèi)存加載過(guò)程中，數(shù)據(jù)加載的最小單位是頁(yè)。所以每個(gè)頁(yè)中存儲(chǔ)的行越多，則數(shù)據(jù)加載的頁(yè)會(huì)越少，查找性能越高。

假設(shè)一頁(yè)16k=160行，則一行=100字節(jié)，100字節(jié)=10個(gè)字段=>1個(gè)字段=10字節(jié)，所以這里看下1行存儲(chǔ)10個(gè)10字節(jié)的字段，這樣一頁(yè)能存儲(chǔ)160行數(shù)據(jù)。所以到這里，可以根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景預(yù)估你單表所需要的實(shí)際字段數(shù)量及每個(gè)字段的長(zhǎng)度，合理進(jìn)行字段設(shè)計(jì)；數(shù)據(jù)量越大越不適合寬表設(shè)計(jì)，字段應(yīng)該盡可能的少。對(duì)于互聯(lián)網(wǎng)公司來(lái)說(shuō)，基本是要告別寬表，使用者窄表，一方面是為了性能，一方面也是方便了維護(hù)。

innodb關(guān)于數(shù)據(jù)行大小的限制

我們知道innodb的頁(yè)塊大小默認(rèn)為16kb，表中數(shù)據(jù)是存放在B-tree node的頁(yè)塊中，但如果表中一行的數(shù)據(jù)長(zhǎng)度超過(guò)了16k，這時(shí)候就會(huì)出現(xiàn)行溢出，溢出的行是存放在另外的地方，存放該溢出數(shù)據(jù)的頁(yè)叫uncompresse blob page。

innodb采用聚簇索引的方式把數(shù)據(jù)存放起來(lái)，即B+樹(shù)結(jié)構(gòu)，因此每個(gè)頁(yè)塊中至少有兩行數(shù)據(jù)，否則就失去了B+樹(shù)的意義（每一個(gè)頁(yè)中只有一條數(shù)據(jù)，整個(gè)樹(shù)成為了一條雙向鏈表），這樣就得出了一行數(shù)據(jù)的最大長(zhǎng)度就限制為了8k。

? ? 當(dāng)插入的一行數(shù)據(jù)不能在一個(gè)數(shù)據(jù)頁(yè)塊中存放時(shí)，為了保證該頁(yè)至少能存放兩行數(shù)據(jù)，innodb將會(huì)自動(dòng)部分?jǐn)?shù)據(jù)溢出到另外頁(yè)中，一部分?jǐn)?shù)據(jù)將存放在數(shù)據(jù)頁(yè)塊中，其大小為該列的前768字節(jié)，同時(shí)接著還有偏移指向溢出頁(yè)。

? ? 如上面所說(shuō)大字段的前768字節(jié)會(huì)存放在數(shù)據(jù)頁(yè)塊中，那么如果有10個(gè)大字段（如varchar（1000），text，blob同varchar同樣存儲(chǔ)前768字節(jié)），同樣會(huì)超過(guò)一行數(shù)據(jù)8k的限制（10*768<8000,11*768>8000）。如果插入的值超過(guò)8000字節(jié)，則會(huì)報(bào)錯(cuò)（BLOB或TEXT同理）

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?innodb的表數(shù)據(jù)結(jié)構(gòu)（B+樹(shù)）

回顧一下Innodb是如何查找數(shù)據(jù)的？

要查找一條數(shù)據(jù)，怎么查？

如 select * from user where id=5;

這里 id 是主鍵，我們通過(guò)這棵 B+ 樹(shù)來(lái)查找，首先找到根頁(yè)（每個(gè)頁(yè)都有一個(gè)編號(hào)），你怎么知道 user 表的根頁(yè)在哪呢？

其實(shí)每張表的根頁(yè)位置在表空間文件中是固定的，即 page number=3 的頁(yè)，找到根頁(yè)后通過(guò)二分查找法，定位到 id=5 的數(shù)據(jù)應(yīng)該在指針 P5 指向的頁(yè)中，那么進(jìn)一步去 page number=5 的頁(yè)中查找，同樣通過(guò)二分查詢法即可找到 id=5 的記錄

總結(jié)一下：

1、InnoDB 存儲(chǔ)引擎的最小存儲(chǔ)單元是頁(yè)，頁(yè)可以用于存放數(shù)據(jù)也可以用于存放鍵值 + 指針，在 B+ 樹(shù)中葉子節(jié)點(diǎn)存放數(shù)據(jù)，非葉子節(jié)點(diǎn)存放鍵值 + 指針。

2、索引組織表通過(guò)非葉子節(jié)點(diǎn)的二分查找法以及指針確定數(shù)據(jù)在哪個(gè)頁(yè)中，進(jìn)而在去數(shù)據(jù)頁(yè)中查找到需要的數(shù)據(jù)；

如果每個(gè)節(jié)點(diǎn)就一個(gè)數(shù)據(jù)，那么整個(gè)葉節(jié)點(diǎn)就是一個(gè)雙向鏈表（圖中是單向鏈表，實(shí)際是雙向的）了，就失去了樹(shù)的意義。

2、SQL優(yōu)化

sql的優(yōu)化的關(guān)鍵是是要確定優(yōu)化的方向，也就是定位性能的缺陷：

一、分析SQL語(yǔ)句的執(zhí)行計(jì)劃

什么是執(zhí)行計(jì)劃呢？

簡(jiǎn)單來(lái)說(shuō)，就是SQL在數(shù)據(jù)庫(kù)中執(zhí)行時(shí)的表現(xiàn)情況，通常用于SQL性能分析、優(yōu)化等場(chǎng)景。

MySQL邏輯架構(gòu)分為三層，如下圖：

客戶端：

????如，連接處理、授權(quán)認(rèn)證、安全等功能；

核心服務(wù)：

????MySQL大多數(shù)核心服務(wù)均在這一層，包括查詢解析、分析、優(yōu)化、緩存、內(nèi)置函數(shù)（如，時(shí)間、數(shù)學(xué)、加密等），所有的跨存儲(chǔ)引擎的功能也在這一層，如，存儲(chǔ)過(guò)程、觸發(fā)器、視圖等；

存儲(chǔ)引擎

????負(fù)責(zé)MySQL中的數(shù)據(jù)存儲(chǔ)和讀取中間的服務(wù)層通過(guò)API與存儲(chǔ)引擎通信，這些API屏蔽了不同存儲(chǔ)引擎間的差異；

查詢緩存：對(duì)于select語(yǔ)句，MySQL查詢緩存保存查詢返回的完整結(jié)果。當(dāng)查詢命中該緩存，MySQL會(huì)like返回結(jié)果，跳過(guò)了解析、優(yōu)化和執(zhí)行截?cái)唷ySQL查詢緩存保存查詢返回的完整結(jié)果。并不是什么情況下查詢緩存都會(huì)提高系統(tǒng)性能的。緩存和失效都會(huì)帶來(lái)額外的消耗，所以只有當(dāng)緩存帶來(lái)的資源節(jié)約大于其本身的資源消耗時(shí)才會(huì)給系統(tǒng)帶來(lái)性能提升。這根具體的服務(wù)器壓力模型有關(guān)。關(guān)于是否開(kāi)啟查詢?cè)斠?jiàn)這篇文章：https://blog.csdn.net/yongqi_wang/article/details/86674088

注意?：1. 查詢緩存不返回舊的數(shù)據(jù)。當(dāng)表更改后，查詢緩存值的相關(guān)條目被清空。

? ? ? ? ? ? ? 2.?如果你有許多mysql的?服務(wù)器更新相同的MyISAM?表，在這種情況下查詢緩存不起作用。

? ? ? ? ? ? ??3.?查詢緩存不適用于服務(wù)器方編寫(xiě)的語(yǔ)句。

explain

顯示了mysql如何使用索引來(lái)處理select語(yǔ)句以及連接表。可以幫助選擇更好的索引和寫(xiě)出更優(yōu)化的查詢語(yǔ)句。

使用方法，在select語(yǔ)句前加上explain就可以了：如：explain select * from test1

EXPLAIN列的解釋：

table：

• 顯示這一行的數(shù)據(jù)是關(guān)于哪張表的

type：

• 這是重要的列，顯示連接使用了何種類(lèi)型。從最好到最差的連接類(lèi)型為const、eq_reg、ref、range、indexhe和ALL。

各個(gè)連接的含義：

const，通過(guò)索引一次命中，匹配一行數(shù)據(jù)；

eq_ref，唯一性索引掃描，對(duì)于每個(gè)索引鍵，表中只有一條記錄與之匹配，常用語(yǔ)主鍵或唯一索引掃描；

ref，非唯一性索引掃描，返回匹配某個(gè)單獨(dú)值的所有行，用于=、<或>操作符帶索引的列；

range，只檢索給定范圍的行，使用一個(gè)索引來(lái)選擇行，一般用于between、<、>；

index，只遍歷索引樹(shù)；

all，全表掃描；

system，表中只有一行記錄，相當(dāng)于系統(tǒng)表；

• 通常優(yōu)化至少到range級(jí)別，最好能優(yōu)化到ref

possible_keys：

• 指出 MySQL 使用哪個(gè)索引在該表找到行記錄。如果該值為 NULL，說(shuō)明沒(méi)有使用索引，可以建立索引提高性能；

key：

• 實(shí)際使用的索引。如果為NULL，則沒(méi)有使用索引。很少的情況下，MYSQL會(huì)選擇優(yōu)化不足的索引。這種情況下，可以在SELECT語(yǔ)句中使用USE INDEX（indexname）來(lái)強(qiáng)制使用一個(gè)索引或者用IGNORE INDEX（indexname）來(lái)強(qiáng)制MYSQL忽略索引

key_len：

• 使用的索引的長(zhǎng)度。在不損失精確性的情況下，長(zhǎng)度越短越好

ref：

• 顯示索引的哪一列被使用了，如果可能的話，是一個(gè)常數(shù)

rows：

• MYSQL認(rèn)為必須檢查的用來(lái)返回請(qǐng)求數(shù)據(jù)的行數(shù)

Extra：

• 關(guān)于MYSQL如何解析查詢的額外信息。將在表4.3中討論，但這里可以看到的壞的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，結(jié)果是檢索會(huì)很慢。

• using filesort，MySQL會(huì)對(duì)數(shù)據(jù)使用一個(gè)外部索引排序，而不是按照表內(nèi)索引順序進(jìn)行讀取，若出現(xiàn)改值，則應(yīng)優(yōu)化SQL語(yǔ)句；

  using temporary，使用臨時(shí)表緩存中間結(jié)果，比如，MySQL在對(duì)查詢結(jié)果排序時(shí)使用臨時(shí)表，常見(jiàn)于order by和group by，若出現(xiàn)該值，則應(yīng)優(yōu)化SQL；

  using index，表示select操作使用了覆蓋索引，避免了回表查詢；簡(jiǎn)單來(lái)說(shuō)：使用到了索引 , 并且所取的數(shù)據(jù)完全在索引中就能拿到

  using where，where子句用于限制哪一行；簡(jiǎn)單來(lái)說(shuō)：表示使用到了索引 , 但是也進(jìn)行了where過(guò)濾

  using join buffer，使用連接緩存；

  distinct，發(fā)現(xiàn)第一個(gè)匹配后，停止為當(dāng)前的行組合搜索更多的行；

二：show profiles

定義：顯示sql執(zhí)行過(guò)程中各個(gè)環(huán)節(jié)的消耗情況，例如cpu使用情況，打開(kāi)表、檢查權(quán)限、執(zhí)行優(yōu)化器、返回?cái)?shù)據(jù)等分別用了多長(zhǎng)時(shí)間，可以分析語(yǔ)句執(zhí)行慢的瓶頸在哪。如果要使用這個(gè)命令首先要設(shè)置profiling為on，mysql默認(rèn)設(shè)置為off;

1、查看當(dāng)前profiling的值：

? ? ? select @@profiling

2、設(shè)置打開(kāi)profiling

? ? ? set profiling =1;
? ? ? or
? ? ? set profiling=on;

3、設(shè)置關(guān)閉profiling

? ? ? set profiling=0;
? ? ? or
? ? ? set profiling=off;

4、show profiles 默認(rèn)顯示最近15條的sql執(zhí)行情況，15這個(gè)數(shù)字由profiling_history_size常量決定，你可以配置為0到100的數(shù)字最? ? ? ? ? 大支持100，如果設(shè)置為0則類(lèi)似于關(guān)閉profiling選項(xiàng)。除了show profile 和show profiles 兩個(gè)命令不會(huì)被記錄之外，其余的語(yǔ)句? ? ? ? 都會(huì)被記錄，即使是語(yǔ)法錯(cuò)誤的sql也會(huì)被記錄。show profile 命令默認(rèn)獲取最新一條執(zhí)行的sql的消耗分析，如果想指定獲取某? ? ? ? 一條sql的profile 用如下命令：

5、show profiles 先獲取要分析的query_id，然后執(zhí)行show profile for query query_id;

? ? ? show profiles以及show profile 命令同時(shí)也支持 limit語(yǔ)句。show profile 命令 默認(rèn)只顯示Duration 列總消耗時(shí)間，如果要顯示更? ? ? ? 多可以設(shè)置 all參數(shù)
6、show profile [type];

type 參數(shù)支持如下：
| ALL ：表示所有的列
| BLOCK IO ：數(shù)據(jù)塊的輸出出入操作次數(shù)
| CONTEXT SWITCHES ： 上下文切換次數(shù)
| CPU：cpu使用時(shí)長(zhǎng) 包括系統(tǒng)時(shí)長(zhǎng)和用使用時(shí)長(zhǎng)
| IPC ：發(fā)送和接收數(shù)據(jù)的 次數(shù)
| PAGE FAULTS：重要的和次要的錯(cuò)誤次數(shù)
| SOURCE：執(zhí)行相應(yīng)操作的mysql源文件，包括源文件方法名，地址、所在行；
| SWAPS：swap次數(shù)

提示：實(shí)際上這些數(shù)據(jù)全都存在mysql的表里，你可以執(zhí)行如下查詢一樣可以獲取相同的信息。
SELECT * FROM INFORMATION_SCHEMA.PROFILING WHERE QUERY_ID = query_id;

二、SQL語(yǔ)句

避免全表掃描：盡量避免用in、not in、is null、or、like、左值運(yùn)算、函數(shù)運(yùn)算

1、對(duì)查詢進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引。?? ?
2、應(yīng)盡量避免在 where 子句中對(duì)字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：select id from t where num is null??可以在num上設(shè)置默認(rèn)值0，確保表中num列沒(méi)有null值，然后這樣查詢：?? ?
select id from t where num=0???

3、應(yīng)盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描。?? ?
4、應(yīng)盡量避免在 where 子句中使用 or 來(lái)連接條件，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：?? ?
select id from t where num=10 or num=20?? ?
可以這樣查詢：?? ?
select id from t where num=10?? ?
union all?? ?
select id from t where num=20

5、in 和 not in 也要慎用，否則會(huì)導(dǎo)致全表掃描，如：?? ?
select id from t where num in(1,2,3)?? ?
對(duì)于連續(xù)的數(shù)值，能用 between 就不要用 in 了：?? ?
select id from t where num between 1 and 3??

6、下面的查詢也將導(dǎo)致全表掃描：?? ?
select id from t where name like '%abc%'?? ?

7、7.應(yīng)盡量避免在 where 子句中對(duì)字段進(jìn)行表達(dá)式操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：?? ?
select id from t where num/2=100?? ?
應(yīng)改為:?? ?
select id from t where num=100*2?? ?
?8、應(yīng)盡量避免在where子句中對(duì)字段進(jìn)行函數(shù)操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：?? ?
select id from t where substring(name,1,3)='abc'--name以abc開(kāi)頭的id?? ?
應(yīng)改為:?? ?
select id from t where name like 'abc%'?? ?

9、不要在 where 子句中的“=”左邊進(jìn)行函數(shù)、算術(shù)運(yùn)算或其他表達(dá)式運(yùn)算，否則系統(tǒng)將可能無(wú)法正確使用索引。

10、在使用索引字段作為條件時(shí)，如果該索引是復(fù)合索引，那么必須使用到該索引中的第一個(gè)字段作為條件時(shí)才能保證系統(tǒng)使用該索引，否則該索引將不會(huì)被使用，并且應(yīng)盡可能的讓字段順序與索引順序相一致。

11、 不要寫(xiě)一些沒(méi)有意義的查詢，如需要生成一個(gè)空表結(jié)構(gòu)：?? ?
select col1,col2 into #t from t where 1=0?? ?
這類(lèi)代碼不會(huì)返回任何結(jié)果集，但是會(huì)消耗系統(tǒng)資源的，應(yīng)改成這樣：?? ?
create table #t(...)?? ?
?? ?
12、很多時(shí)候用 exists 代替 in 是一個(gè)好的選擇：?? ?
select num from a where num in(select num from b)?? ?
用下面的語(yǔ)句替換：?? ?
select num from a where exists(select 1 from b where num=a.num)??

13、并不是所有索引對(duì)查詢都有效，SQL是根據(jù)表中數(shù)據(jù)來(lái)進(jìn)行查詢優(yōu)化的，當(dāng)索引列有大量數(shù)據(jù)重復(fù)時(shí)，SQL查詢可能不會(huì)去利用索引，如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對(duì)查詢效率起不了作用。?? ?

14、索引并不是越多越好，索引固然可以提高相應(yīng)的 select 的效率，但同時(shí)也降低了 insert 及 update 的效率，?? ?
因?yàn)?insert 或 update 時(shí)有可能會(huì)重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。?? ?
一個(gè)表的索引數(shù)最好不要超過(guò)6個(gè)，若太多則應(yīng)考慮一些不常使用到的列上建的索引是否有必要。

15、盡量使用數(shù)字型字段，若只含數(shù)值信息的字段盡量不要設(shè)計(jì)為字符型，這會(huì)降低查詢和連接的性能，并會(huì)增加存儲(chǔ)開(kāi)銷(xiāo)。?? ?
這是因?yàn)橐嬖谔幚聿樵兒瓦B接時(shí)會(huì)逐個(gè)比較字符串中每一個(gè)字符，而對(duì)于數(shù)字型而言只需要比較一次就夠了。

16、盡可能的使用 varchar 代替 char ，因?yàn)槭紫茸冮L(zhǎng)字段存儲(chǔ)空間小，可以節(jié)省存儲(chǔ)空間，?? ?
其次對(duì)于查詢來(lái)說(shuō)，在一個(gè)相對(duì)較小的字段內(nèi)搜索效率顯然要高些。?

17、任何地方都不要使用 select * from t ，用具體的字段列表代替“*”，不要返回用不到的任何字段。

18、避免頻繁創(chuàng)建和刪除臨時(shí)表，以減少系統(tǒng)表資源的消耗

19、臨時(shí)表并不是不可使用，適當(dāng)?shù)厥褂盟鼈兛梢允鼓承├谈行?#xff0c;例如，當(dāng)需要重復(fù)引用大型表或常用表中的某個(gè)數(shù)據(jù)集時(shí)。但是，對(duì)于一次性事件，最好使用導(dǎo)出表。

20、在新建臨時(shí)表時(shí)，如果一次性插入數(shù)據(jù)量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，?? ?
以提高速度；如果數(shù)據(jù)量不大，為了緩和系統(tǒng)表的資源，應(yīng)先create table，然后insert。

21、如果使用到了臨時(shí)表，在存儲(chǔ)過(guò)程的最后務(wù)必將所有的臨時(shí)表顯式刪除，先 truncate table ，然后 drop table ，這樣可以避免系統(tǒng)表的較長(zhǎng)時(shí)間鎖定。?

22、盡量避免使用游標(biāo)，因?yàn)橛螛?biāo)的效率較差，如果游標(biāo)操作的數(shù)據(jù)超過(guò)1萬(wàn)行，那么就應(yīng)該考慮改寫(xiě)。

23、使用基于游標(biāo)的方法或臨時(shí)表方法之前，應(yīng)先尋找基于集的解決方案來(lái)解決問(wèn)題，基于集的方法通常更有效。

24、與臨時(shí)表一樣，游標(biāo)并不是不可使用。對(duì)小型數(shù)據(jù)集使用 FAST_FORWARD 游標(biāo)通常要優(yōu)于其他逐行處理方法，尤其是在必須引用幾個(gè)表才能獲得所需的數(shù)據(jù)時(shí)。
在結(jié)果集中包括“合計(jì)”的例程通常要比使用游標(biāo)執(zhí)行的速度快。如果開(kāi)發(fā)時(shí)間允許，基于游標(biāo)的方法和基于集的方法都可以嘗試一下，看哪一種方法的效果更好。

25、盡量避免大事務(wù)操作，提高系統(tǒng)并發(fā)能力；

26、盡量避免向客戶端返回大數(shù)據(jù)量，若數(shù)據(jù)量過(guò)大，應(yīng)該考慮相應(yīng)需求是否合理。

27、使用復(fù)合索引

28、避免索引失效

29、避免回表查詢

30、不要索引上左任何運(yùn)算操作

31、小表驅(qū)動(dòng)達(dá)標(biāo)。小表查詢條件放在where子句的左邊

總結(jié)

以上是生活随笔為你收集整理的从建表到SQL优化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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