三张表Student(Sno主键),SC(Sno外键,Cno外键),Course(Cno主键)，怎么用mysql去设置呢？

工具/材料：Management Studio。

创新互联网站建设公司是一家服务多年做网站建设策划设计制作的公司,为广大用户提供了成都网站制作、成都做网站，成都网站设计，广告投放平台，成都做网站选创新互联，贴合企业需求，高性价比，满足客户不同层次的需求一站式服务欢迎致电。

1、首先在桌面上，点击“Management Studio”图标。

2、之后在该界面中，右键点击Student表里“设计”选项。

3、接着在该界面中，右键点击“Sno”属性里“设置主键”选项。

4、然后在该界面中，表Student设置Sno主键成功。

5、之后在该界面中，右键点击Course表里“设计”选项。

6、接着在该界面中，右键点击“Cno”属性里“设置主键”选项。

7、然后在该界面中，表Course设置Cno主键成功。

8、接着在该界面中，右键点击SC表里“设计”选项。

9、然后在该界面中，右键点击“Sno”属性里“关系”选项。

10、接着在该界面中，选择主键表为Student表里的“Sno”属性。

11、然后在该界面中，右键点击“Cno”属性里“关系”选项。

12、接着在该界面中，选择主键表为Course表里的“Cno”属性。

13、最后在该界面中，表SC设置Sno外键，Cno外键成功。

mysql多表联合查询优化的问题

SELECT * FROM(

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

WHERE title like '%中国%'

UNION

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

WHERE title like '%中国%'

UNION

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

WHERE title like '%中国%'

) AS a

这样会不会快点。

MySQL 对于千万级的大表要怎么优化

对大数据的数据库管理优化的总结：

常用的优化sql----突出快字，使完成操作的时间最短

1、用索引提高效率：

2、选择有效率的表名顺序，及数据结构及字段；

3、使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表；

4、删除重复记；

5、过内部函数提高SQL效率；

......

读写分离-----操作不在一个表里完成

1、主数据库A，进行事务性增、改、删操作（INSERT、UPDATE、DELETE）；

2、从数据库B，进行SELECT查询操作；

3、A复制到B，使数据保持一致性；

垂直划分 ------数据不存储在一个服务器里

按照功能划分，把数据分别放到不同的数据库和服务器。如博客功能的放到服务器A，储存文件放到服务器B；

水平划分------相同数据结构的数据不放在一张表里

把一个表的数据根据一定的规则划分到不同的数据库，两个数据库的表结构一样。

数据归档处理-----时间优先原则存储读取

将数据库中不经常使用的数据迁移至近线设备，将长期不使用的数据迁移至文件形式归档。这样，随着应用的需要，数据会在在线、近线和文件文档之间移动，如当应用需要访问很久以前的某些数据，它们的物理位置在近线设备，则会自动移动到在线设备。对用户的应用而言，这些都是透明的，就像所有数据都存放在在线设备一样，不会对数据库应用产生任何影响。

MySQL中3表join流程分析

常听说MySQL中3表 join 的执行流程并不是前两张表 join 得出结果，再与第三张表进行 join；而是3表嵌套的循环连接。那这个3表嵌套的循环连接具体又是个什么流程呢？与前两张表 join 得出结果再与第三张表进行 join 的执行效率相比如何呢？下面通过一个例子来分析分析。

set optimizer_switch='block_nested_loop=off';

关联字段无索引的情况下强制使用索引嵌套循环连接算法，目的是更好的观察扫描行数。

表结构和数据如下：

示例SQL：

通过 slow log 得知一共扫描 24100 行：

执行计划显示用的索引嵌套循环连接算法：

扫描行数构成：

总行数=100+4000+20000=24100。

从这个结果来看，join 过程像是先 t1 和 t3 join 得出 20 行中间结果，再与 t2 进行 join 得出结果。这结论与我们通常认为的 3表 join 实际上是3表嵌套的循环连接不一样，接着往下看。

查看执行计划成本：

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表总成本= 驱动表扇出*(IO成本+CPU成本) = 20*(1+40) =820

阶段性总成本= 21+820 =841

此处 eval_cost=80，实则为 驱动表扇出*被驱动每次扫描行数*filtered*成本常数 ，即 20*200*10%*0.2 。

简化公式为： eval_cost=rows_produced_per_json*成本常数

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*成本常数 ，即 40000*0.2

根据执行计划成本分析：

这样看，3表 join 流程是：

注意，由于造的数据比较特殊，所以第 3 步得出的中间结果集实际上只有 1行，所以最终 t2 表的查找次数是 20*1=20 ，所以扫描总行数是 20*1000 。所以单看 slow log 中显示的 24100 行，会误认为是先得出 t1 和 t3 join 的结果，再去和 t2 进行 join。

当我调整 t3 的数据，删除20行，再插入20行，使满足 b21 的数据翻倍，这样“第 3 步得出的中间结果集”变成 2 行：

再来看slow log 中扫描的总行数为44100，t1、t3的扫描行数不变，t2 的扫描行数变为 20*2*1000=40000 ：

为什么执行计划中分析得到的是 t2 表查找 400 次呢？

因为执行计划对t1 join t3 的扇出是个估算值，不准确。而 slow log 是真实执行后统计的，是个准确值。

为什么执行计划中，t2表的执行次数是用“t1 join t3 的扇出”表示的？这不是说明 t1 先和 t3 join，结果再和 t2 join？

其实拆解来看，“3表嵌套循环” 和 “前2表 join 的结果和第3张表 join” 两种算法，成本是一样的，而且如果要按3表嵌套循环的方式展示每张表的成本将非常复杂，可读性不强。所以执行计划中这么表示没有问题。

总的来说，对于3表join或者多表join 来说，“3表嵌套循环” 和 “先2表 join，结果和第3张表join” 两种算法，成本是一样的。要注意的一点是3表嵌套循环成本并非如下图写的：n m x，而是 n (m+a x)，其中 a 为 t2 满足单个等值条件的平均值。

当被驱动表的关联字段不是唯一索引，或者没有索引，每次扫描行数会大于1时，其扇出误差会非常大。比如在上面的示例中：

t3 实际的扇出只有 20，但优化器估算值是 总扫描行数的 10%，由于t3表的关联字段没有索引，所以每次都要全表扫描200行，总的扫描行数= 20*200 =4000，扇出= 4000*10% =400，比实际的20大了20倍。尤其对于后续表的 join 来说，成本估算会产生更严重的偏差。

如果是 left join，每个被驱动表的 filtered 都会被优化器认定为 100%，误差更大！

通常建议join不超过2表，就是因为优化器估算成本误差大导致选择不好的执行计划，如果要用，一定要记住：关联字段必须要有索引，最好有唯一性或者基数大。

mysql 三张表关联查询怎么优化

关联的表用join,保证每张表都可以使用索引,可以最大限度缩小数据范围的那张表尽量优先查询.写好的语句可以用explain分析一下看看.

explain mysqlsql语句

MYSQL 如何优化LEFF JOIN多张表的查询效率

你这个需求，就是N个表的各自SUM求和，无论用什么语句，从效率上是没法提高的，因为数据运算没法避免。

给你几个参考建议：

左连接是没有必要的，你需要的其实就是不同表各自的sum，应该各自查询就好了

分开语句写，语句更精简

这样的需求，最好使用存储过程和循环语句，在需求上可以更灵活，可以查询任意天数和任意起始日期的数据

当数据量很多（天数积累），并且查询比较频繁的时候，应该引入“中间表”或“临时表”，表中每条记录记录一天的sum值（可以通过存储过程或者定时任务维护），这样再次查询会更有效率。

本文标题：mysql怎么优化三张表 mysql怎么关联三张表
分享URL：http://cqwzjz.cn/article/dooices.html