“集合”是SQL查询结果的逻辑概念而非MySQL数据对象，指SELECT返回的行集合（result set），用于UNION等集合运算；database才是表的容器，表间关系靠外键而非命名或目录体现。
“集合”在MySQL里不是表的容器，而是查询结果的逻辑概念
很多人看到“集合”就联想到“数据库是表的集合”，这是对术语的误用。MySQL中没有叫“集合”的数据对象，database才是表的容器；而“集合”实际出现在SQL操作层面，指SELECT语句返回的**行集合（result set）**，比如UNION、INTERSECT（MySQL 8.0+ 支持）、EXCEPT（MySQL至今不原生支持）等操作，都是对多个查询结果集做集合运算。
常见误解：以为CREATE TABLE students AS SELECT * FROM temp;是在“把集合存成表”——其实这只是用查询结果初始化表数据，students仍是标准表，和“集合”无隶属关系。
- 数据库 → 表 → 行 → 列，是MySQL真实的数据层级；“集合”不在这个层级中
-
UNION合并的是两个SELECT的结果集，不是两张表本身 - 想查“学生表和教师表里共有的姓名”，不能写
SELECT name FROM students INTERSECT SELECT name FROM teachers（MySQL 5.7 不支持），得改用INNER JOIN或子查询
为什么MySQL不把表叫“集合”，但SQL却大量用集合思维？
因为关系模型（Relational Model）的数学基础就是集合论：表对应“关系（Relation）”，行是“元组（Tuple）”，列是“属性（Attribute）”。所以SELECT返回的是满足条件的元组集合，WHERE是筛选子集，DISTINCT是去重（即取集合而非多重集/bag）。
但MySQL默认按bag模型处理结果（允许重复行），除非显式加DISTINCT——这点常被忽略，导致统计出错：
SELECT student_id FROM enrollments; -- 可能返回：101, 101, 102 → 3行（bag） SELECT DISTINCT student_id FROM enrollments; -- 返回：101, 102 → 2行（set）
- 所有
UNION默认去重，UNION ALL保留重复，性能更好但语义不同 - MySQL 8.0+ 支持
INTERSECT和EXCEPT，但要求各查询列数、类型严格一致，否则报错：ERROR 1222 (21000): The used SELECT statements have a different number of columns - 用
JOIN替代INTERSECT更兼容老版本，也更容易加索引优化
表之间怎么形成“数据集合关系”？靠外键，不是靠命名或目录
真正体现“集合关联”的，是表之间的约束与连接逻辑，不是物理存放位置。比如orders和order_items属于同一业务集合（订单域），但MySQL不感知这种语义——必须靠FOREIGN KEY显式声明关系：
ALTER TABLE order_items ADD CONSTRAINT fk_order_id FOREIGN KEY (order_id) REFERENCES orders(id);
- 没加外键，两张表再“名字像”“放同个database里”，MySQL也当它们完全无关
- 外键能防脏数据（如插入不存在的
order_id），但会降低写入性能，高并发写场景常被禁用 - 逻辑上一对多的表，物理上可以分库（如
orders在trade_db，users在user_db），这时就得用应用层join或冗余字段，无法用外键
日常开发中最容易混淆的三个点
不是概念不清，而是命令/关键词的字面意思误导了直觉：
-
SHOW TABLES显示的是当前database下的表名列表，不是“某个集合里的元素”——它不返回数据，只返回元信息 -
INFORMATION_SCHEMA.TABLES是MySQL自带的系统表，存所有表的描述信息，但它本身也是张表，不是“集合管理器” - 用
mysqldump导出时加--databases school shop，生成的SQL里会有多个CREATE DATABASE，但这只是工具行为，MySQL服务器并不维护“school+shop”这个联合集合
归根结底：MySQL只认database、table、row、column这四级实体；所谓“集合”，只是你写SQL时脑子里的数学模型——它指导你怎么写JOIN、要不要DISTINCT、能不能用UNION，但不会改变存储结构或权限体系。