三張表Student(Sno主鍵),SC(Sno外鍵,Cno外鍵),Course(Cno主鍵)，怎么用mysql去設(shè)置呢？

工具/材料：Management Studio。

創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司是一家服務(wù)多年做網(wǎng)站建設(shè)策劃設(shè)計(jì)制作的公司,為廣大用戶提供了成都網(wǎng)站制作、成都做網(wǎng)站，成都網(wǎng)站設(shè)計(jì)，廣告投放平臺(tái)，成都做網(wǎng)站選創(chuàng)新互聯(lián)，貼合企業(yè)需求，高性價(jià)比，滿足客戶不同層次的需求一站式服務(wù)歡迎致電。

1、首先在桌面上，點(diǎn)擊“Management Studio”圖標(biāo)。

2、之后在該界面中，右鍵點(diǎn)擊Student表里“設(shè)計(jì)”選項(xiàng)。

3、接著在該界面中，右鍵點(diǎn)擊“Sno”屬性里“設(shè)置主鍵”選項(xiàng)。

4、然后在該界面中，表Student設(shè)置Sno主鍵成功。

5、之后在該界面中，右鍵點(diǎn)擊Course表里“設(shè)計(jì)”選項(xiàng)。

6、接著在該界面中，右鍵點(diǎn)擊“Cno”屬性里“設(shè)置主鍵”選項(xiàng)。

7、然后在該界面中，表Course設(shè)置Cno主鍵成功。

8、接著在該界面中，右鍵點(diǎn)擊SC表里“設(shè)計(jì)”選項(xiàng)。

9、然后在該界面中，右鍵點(diǎn)擊“Sno”屬性里“關(guān)系”選項(xiàng)。

10、接著在該界面中，選擇主鍵表為Student表里的“Sno”屬性。

11、然后在該界面中，右鍵點(diǎn)擊“Cno”屬性里“關(guān)系”選項(xiàng)。

12、接著在該界面中，選擇主鍵表為Course表里的“Cno”屬性。

13、最后在該界面中，表SC設(shè)置Sno外鍵，Cno外鍵成功。

mysql多表聯(lián)合查詢優(yōu)化的問(wèn)題

SELECT * FROM(

SELECT id,title,inputtime,description,url,thumb,status FROM sc_news

WHERE title like '%中國(guó)%'

UNION

SELECT id,title,inputtime,description,url,thumb,status FROM sc_pic

WHERE title like '%中國(guó)%'

UNION

SELECT id,title,inputtime,description,url,thumb,status FROM sc_video

WHERE title like '%中國(guó)%'

) AS a

這樣會(huì)不會(huì)快點(diǎn)。

MySQL 對(duì)于千萬(wàn)級(jí)的大表要怎么優(yōu)化

對(duì)大數(shù)據(jù)的數(shù)據(jù)庫(kù)管理優(yōu)化的總結(jié)：

常用的優(yōu)化sql----突出快字，使完成操作的時(shí)間最短

1、用索引提高效率：

2、選擇有效率的表名順序，及數(shù)據(jù)結(jié)構(gòu)及字段；

3、使用DECODE函數(shù)可以避免重復(fù)掃描相同記錄或重復(fù)連接相同的表；

4、刪除重復(fù)記；

5、過(guò)內(nèi)部函數(shù)提高SQL效率；

......

讀寫(xiě)分離-----操作不在一個(gè)表里完成

1、主數(shù)據(jù)庫(kù)A，進(jìn)行事務(wù)性增、改、刪操作（INSERT、UPDATE、DELETE）；

2、從數(shù)據(jù)庫(kù)B，進(jìn)行SELECT查詢操作；

3、A復(fù)制到B，使數(shù)據(jù)保持一致性；

垂直劃分 ------數(shù)據(jù)不存儲(chǔ)在一個(gè)服務(wù)器里

按照功能劃分，把數(shù)據(jù)分別放到不同的數(shù)據(jù)庫(kù)和服務(wù)器。如博客功能的放到服務(wù)器A，儲(chǔ)存文件放到服務(wù)器B；

水平劃分------相同數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)不放在一張表里

把一個(gè)表的數(shù)據(jù)根據(jù)一定的規(guī)則劃分到不同的數(shù)據(jù)庫(kù)，兩個(gè)數(shù)據(jù)庫(kù)的表結(jié)構(gòu)一樣。

數(shù)據(jù)歸檔處理-----時(shí)間優(yōu)先原則存儲(chǔ)讀取

將數(shù)據(jù)庫(kù)中不經(jīng)常使用的數(shù)據(jù)遷移至近線設(shè)備，將長(zhǎng)期不使用的數(shù)據(jù)遷移至文件形式歸檔。這樣，隨著應(yīng)用的需要，數(shù)據(jù)會(huì)在在線、近線和文件文檔之間移動(dòng)，如當(dāng)應(yīng)用需要訪問(wèn)很久以前的某些數(shù)據(jù)，它們的物理位置在近線設(shè)備，則會(huì)自動(dòng)移動(dòng)到在線設(shè)備。對(duì)用戶的應(yīng)用而言，這些都是透明的，就像所有數(shù)據(jù)都存放在在線設(shè)備一樣，不會(huì)對(duì)數(shù)據(jù)庫(kù)應(yīng)用產(chǎn)生任何影響。

MySQL中3表join流程分析

常聽(tīng)說(shuō)MySQL中3表 join 的執(zhí)行流程并不是前兩張表 join 得出結(jié)果，再與第三張表進(jìn)行 join；而是3表嵌套的循環(huán)連接。那這個(gè)3表嵌套的循環(huán)連接具體又是個(gè)什么流程呢？與前兩張表 join 得出結(jié)果再與第三張表進(jìn)行 join 的執(zhí)行效率相比如何呢？下面通過(guò)一個(gè)例子來(lái)分析分析。

set optimizer_switch='block_nested_loop=off';

關(guān)聯(lián)字段無(wú)索引的情況下強(qiáng)制使用索引嵌套循環(huán)連接算法，目的是更好的觀察掃描行數(shù)。

表結(jié)構(gòu)和數(shù)據(jù)如下：

示例SQL：

通過(guò) slow log 得知一共掃描 24100 行：

執(zhí)行計(jì)劃顯示用的索引嵌套循環(huán)連接算法：

掃描行數(shù)構(gòu)成：

總行數(shù)=100+4000+20000=24100。

從這個(gè)結(jié)果來(lái)看，join 過(guò)程像是先 t1 和 t3 join 得出 20 行中間結(jié)果，再與 t2 進(jìn)行 join 得出結(jié)果。這結(jié)論與我們通常認(rèn)為的 3表 join 實(shí)際上是3表嵌套的循環(huán)連接不一樣，接著往下看。

查看執(zhí)行計(jì)劃成本：

mysql explain format=json select * from t1 join t2 on t1.b=t2.b join t3 on t1.b=t3.b where t1.a21\G

其他信息：

IO成本= 1*1.0 =1

CPU成本= 100*0.2 =20

t1總成本=21

IO成本= 1*1.0 =1

CPU成本= 200*0.2 =40

t3表總成本= 驅(qū)動(dòng)表扇出*(IO成本+CPU成本) = 20*(1+40) =820

階段性總成本= 21+820 =841

此處 eval_cost=80，實(shí)則為 驅(qū)動(dòng)表扇出*被驅(qū)動(dòng)每次掃描行數(shù)*filtered*成本常數(shù) ，即 20*200*10%*0.2 。

簡(jiǎn)化公式為： eval_cost=rows_produced_per_json*成本常數(shù)

IO成本= 4*1.0 =4

CPU成本= 1000*0.2 =200

t2表總成本= 前2表join的扇出*(IO成本+CPU成本) = 400*(4+200) =81600

階段性總成本= 841+81600 =82441

此處 eval_cost=8000，即 rows_produced_per_json*成本常數(shù) ，即 40000*0.2

根據(jù)執(zhí)行計(jì)劃成本分析：

這樣看，3表 join 流程是：

注意，由于造的數(shù)據(jù)比較特殊，所以第 3 步得出的中間結(jié)果集實(shí)際上只有 1行，所以最終 t2 表的查找次數(shù)是 20*1=20 ，所以掃描總行數(shù)是 20*1000 。所以單看 slow log 中顯示的 24100 行，會(huì)誤認(rèn)為是先得出 t1 和 t3 join 的結(jié)果，再去和 t2 進(jìn)行 join。

當(dāng)我調(diào)整 t3 的數(shù)據(jù)，刪除20行，再插入20行，使?jié)M足 b21 的數(shù)據(jù)翻倍，這樣“第 3 步得出的中間結(jié)果集”變成 2 行：

再來(lái)看slow log 中掃描的總行數(shù)為44100，t1、t3的掃描行數(shù)不變，t2 的掃描行數(shù)變?yōu)? 20*2*1000=40000 ：

為什么執(zhí)行計(jì)劃中分析得到的是 t2 表查找 400 次呢？

因?yàn)閳?zhí)行計(jì)劃對(duì)t1 join t3 的扇出是個(gè)估算值，不準(zhǔn)確。而 slow log 是真實(shí)執(zhí)行后統(tǒng)計(jì)的，是個(gè)準(zhǔn)確值。

為什么執(zhí)行計(jì)劃中，t2表的執(zhí)行次數(shù)是用“t1 join t3 的扇出”表示的？這不是說(shuō)明 t1 先和 t3 join，結(jié)果再和 t2 join？

其實(shí)拆解來(lái)看，“3表嵌套循環(huán)” 和 “前2表 join 的結(jié)果和第3張表 join” 兩種算法，成本是一樣的，而且如果要按3表嵌套循環(huán)的方式展示每張表的成本將非常復(fù)雜，可讀性不強(qiáng)。所以執(zhí)行計(jì)劃中這么表示沒(méi)有問(wèn)題。

總的來(lái)說(shuō)，對(duì)于3表join或者多表join 來(lái)說(shuō)，“3表嵌套循環(huán)” 和 “先2表 join，結(jié)果和第3張表join” 兩種算法，成本是一樣的。要注意的一點(diǎn)是3表嵌套循環(huán)成本并非如下圖寫(xiě)的：n m x，而是 n (m+a x)，其中 a 為 t2 滿足單個(gè)等值條件的平均值。

當(dāng)被驅(qū)動(dòng)表的關(guān)聯(lián)字段不是唯一索引，或者沒(méi)有索引，每次掃描行數(shù)會(huì)大于1時(shí)，其扇出誤差會(huì)非常大。比如在上面的示例中：

t3 實(shí)際的扇出只有 20，但優(yōu)化器估算值是 總掃描行數(shù)的 10%，由于t3表的關(guān)聯(lián)字段沒(méi)有索引，所以每次都要全表掃描200行，總的掃描行數(shù)= 20*200 =4000，扇出= 4000*10% =400，比實(shí)際的20大了20倍。尤其對(duì)于后續(xù)表的 join 來(lái)說(shuō)，成本估算會(huì)產(chǎn)生更嚴(yán)重的偏差。

如果是 left join，每個(gè)被驅(qū)動(dòng)表的 filtered 都會(huì)被優(yōu)化器認(rèn)定為 100%，誤差更大！

通常建議join不超過(guò)2表，就是因?yàn)閮?yōu)化器估算成本誤差大導(dǎo)致選擇不好的執(zhí)行計(jì)劃，如果要用，一定要記?。宏P(guān)聯(lián)字段必須要有索引，最好有唯一性或者基數(shù)大。

mysql 三張表關(guān)聯(lián)查詢?cè)趺磧?yōu)化

關(guān)聯(lián)的表用join,保證每張表都可以使用索引,可以最大限度縮小數(shù)據(jù)范圍的那張表盡量?jī)?yōu)先查詢.寫(xiě)好的語(yǔ)句可以用explain分析一下看看.

explain mysqlsql語(yǔ)句

MYSQL 如何優(yōu)化LEFF JOIN多張表的查詢效率

你這個(gè)需求，就是N個(gè)表的各自SUM求和，無(wú)論用什么語(yǔ)句，從效率上是沒(méi)法提高的，因?yàn)閿?shù)據(jù)運(yùn)算沒(méi)法避免。

給你幾個(gè)參考建議：

左連接是沒(méi)有必要的，你需要的其實(shí)就是不同表各自的sum，應(yīng)該各自查詢就好了

分開(kāi)語(yǔ)句寫(xiě)，語(yǔ)句更精簡(jiǎn)

這樣的需求，最好使用存儲(chǔ)過(guò)程和循環(huán)語(yǔ)句，在需求上可以更靈活，可以查詢?nèi)我馓鞌?shù)和任意起始日期的數(shù)據(jù)

當(dāng)數(shù)據(jù)量很多（天數(shù)積累），并且查詢比較頻繁的時(shí)候，應(yīng)該引入“中間表”或“臨時(shí)表”，表中每條記錄記錄一天的sum值（可以通過(guò)存儲(chǔ)過(guò)程或者定時(shí)任務(wù)維護(hù)），這樣再次查詢會(huì)更有效率。