MySQL(2)数据库对象与应用

库建立好之后基本不动,和我们接触最频繁的是表. 建表就是声明字段的过程!

选择合适的类型[速度快 减少硬盘占用]

存储空间，还是存储范围有区别？

答案： 两者本质完全一样 ，只是在一些特殊情况下两者显示有区别(只是在显示的时候补全0的位数不一样)

实验

*zerofill 零填充(本字段同时即自动带有unsigned属性,因为负数不能零填充)

如 数字2在固定宽度4时 零填充 即为0002

M值是一个整数(固定宽度值)，只有在字段有零填充zerofill属性时 规定M值才有意义！

M值只是 显示效果 ,不会影响实际数据值！

如M值为1,实际值255,一样会显示255

列可以声明默认值(推荐声明)

因为null无法和别的值比较

null = 0 返回null

null <>0 返回null

null只能用is或is not比较 null is null当然对的。

例子：

【浮点型】有误差，不稳定！定点数更精确。

实际测试数据

Float(M,D)

M精度(总位数,不包含点) 精度值M 影响 存储的 值的范围.

D标度(小数位) 小数点后有几位（mysql比较特殊，mssql/oracle都不能指定）

testcolumn float(5,2) unsigned 范围0到999.99

float(5,2)的范围-999.99到999.99

给float(5,2)这样的字段插入值在进位时有一些规矩:暂时没搞清楚，不是简单的四舍五入

插入值688.826实际是688.83 末尾6 进位

插入值688.825实际是688.83 末尾5 进位

插入值688.824实际是688.82 末尾4 舍去

插入值688.005实际是688.00

插入值688.015实际是688.01 末尾5 5前面是1 舍去

插入值688.025实际是688.02 末尾5 5前面是2 舍去

插入值688.035实际是688.03 末尾5 5前面是3 舍去

插入值688.045实际是688.04 末尾5 5前面是4 舍去

一般使用tinyint、char(1)、enum类型。

varchar(M)

M代表宽度 即可容纳的【字符数】 (并不是字节数) varchar占用的字节数与编码有关:

utf-8 一个汉字3字节　英文字母1字节

对于utf8mb4号称占用4字节但是并不绝对(在utf8可以覆盖到的范围则仍然占用3字节)

utf8mb4最有优势的应用场景:存储emoji表情

例子：

性能太差，不推荐

MySQL在5.6.4版本之后，TimeStamp和DateTime支持到微妙

一个例子：

以如下这张表为例

show privileges 命令可以查看全部权限

查询时从user->db->table_pirv->columns_pirv依次验证，如果通过则执行查询。

本课程涉及建表SQL

场景1：歌单按时间排序

场景2：统计云音乐创建歌单的用户

场景3-1：统计云音乐创建歌单的用户列表和每人创建歌单的数量。

场景3-2：统计云音乐创建歌单的用户列表和每人创建歌单的数量，并且只显示歌单数量排序大于等于2的用户

SQL进阶语法-like

场景4：查询一个月内创建歌单（从第6行开始显示10条记录）

场景5：对于未录入歌曲的歌单(trackcount = null)，输出结果时歌曲数返回0.

连接的作用是用一个SQL语句把多个表中相互关联的数据查出来

场景6：查询收藏“老男孩”歌单的用户列表

子查询：内层查询的结果作为外层的比较条件。一般子查询都可以转换成连接，推荐使用连接。

场景7：查询出没有用户收藏的歌单

场景8：老板想看创建和收藏歌单的所有用户，查询play_list和play_fav两表中所有的userid

实例还是上节中的那些表

场景1：查询每张专辑总的点播次数和每首歌的平均点播次数。

场景2：查询全部歌曲中的最大的播放次数和最小的播放次数。

场景2续：查询播放次数最多的歌曲

count(*) 和 count(1) 基本一样，没有明显的性能差异。

count(*) 和 count(song_name) 差别在于 count(song_name) 会除去song_name is null的情况

场景3：显示每张专辑的歌曲列表

实例：查询一个月内userid为1,3,5的用户创建的歌单

学生表：

用于更正成绩的触发器：

本质上对创建数据库没有限制，可以使用实例副本进行创建。

大多情况下，需要可靠而有效地克隆 MySQL 实例数据。这包括 MySQL 高可用的解决方案，其中需要在将实例加入组复制集群之前配置实例，或者在经典复制模型中将其添加为 Slave。

为复制拓扑而创建 MySQL 副本一直很麻烦。涉及的步骤很多，首先要备份 MySQL 服务器，通过网络将备份传输到我们想要添加到复制集的新 MySQL 节点，然后在该节点上恢复备份并手动启动 MySQL 服务器。为了高可用，最好还要将其正确设置备份的 GTID，并启动并运行群集。涉及的手动步骤数量过多不利于高可用。CLONE 插件解决了这个问题并简化了副本配置。使您可以使用 MySQL 客户端（和 SQL 命令）来配置新节点并在发生时观察克隆进度。无需手动处理多个步骤并维护自己的基础架构来配置新的 MySQL 节点。

MySQL 8.0.17 引入了 CLONE SQL 语句，使当前的 MySQL 服务器成为另一个运行在不同节点的 MySQL 服务器的“克隆”。我们将执行 clone 语句的服务器实例称为“受体”。克隆的源服务器实例称为“供体”。供体克隆以一致的快照存储在 InnoDB 存储引擎中的所有数据和元数据，以替换受体中的数据。

成功执行 CLONE SQL 语句后，将自动重新启动受体服务器。重新启动涉及恢复克隆的快照数据，就像用老方法复制数据一样。恢复完成后，受体就是供体的克隆版，随时可以使用！

这里有一些关于克隆过程的重要注意事项。

不克隆 MySQL 配置参数，并且受体保留所有原始配置参数，如克隆之前。这样做是因为许多配置可能特定于节点（例如 PORT），因此保留它们似乎是一个不错的选择。另一方面，一些存储配置确实需要在供体和受体之间匹配（例如 innodbpagesize），如果这样的配置参数不匹配，CLONE 将报告错误。

CLONE 插件不会克隆二进制日志。

CLONE 插件目前仅支持 InnoDB 存储引擎。在其他存储引擎（如 MyISAM 和 CSV）中创建的表将被克隆为空表。克隆基础架构的设计允许克隆 MySQL 支持的任何存储引擎。但是，只有 InnoDB 序列化和反序列化方法已经实现并经过测试。

克隆会阻止供体中的所有并发 DDL。

需要注意的事实是受体放弃所有数据以及任何二进制日志，以便成为供体实例的克隆。在执行 CLONE 之前，如果认为有必要，需要备份当前受体数据。

---