MySQL中“表”是强约束的行集合而非数据容器，“字段”由类型等属性定义而非简单别名，主键是聚簇索引锚点，关系需外键显式声明，所有设计决策依赖存储引擎行为细节。
MySQL 里没有“表”和“字段”的抽象概念，只有 CREATE TABLE 语句执行后真实存在的结构——理解这点，才能避开把数据库当 Excel 用的坑。
表（TABLE）不是容器，是约束集合
一张表本质是一组强约束下的行集合。它不“存储数据”，而是定义哪些数据能被接受、如何校验、怎样索引。
-
CREATE TABLE users (id INT, name VARCHAR(50))这条语句没建“空表格”，而是在磁盘上注册了名为users的结构描述 + 默认引擎（通常是 InnoDB）的元数据 - 插入时若
name超过 50 字符，MySQL 不会截断或警告，而是直接报错ERROR 1406 (22001): Data too long for column 'name' - 删除表（
DROP TABLE users）不只是清数据，还会释放其关联的索引、外键约束、统计信息等全部元数据
字段（COLUMN）必须带类型与隐含行为
字段名只是别名，真正起作用的是其声明的类型、是否允许 NULL、默认值、字符集等属性。
-
INT在 MySQL 中默认有符号，INT UNSIGNED才支持 0–4294967295；误用会导致插入负数失败或溢出变 0 -
VARCHAR(255)的 255 是字符数，但实际存储长度取决于字符集：UTF8MB4 下一个汉字占 4 字节，255 字符最多消耗 1020 字节 - 未显式声明
NOT NULL的字段，默认允许 NULL；但主键字段自动强制NOT NULL，哪怕你写id INT NULL PRIMARY KEY，MySQL 也会忽略NULL并设为非空
主键（PRIMARY KEY）不是“唯一标识”，而是聚簇索引锚点
InnoDB 引擎下，主键决定数据物理存放顺序。没有主键？MySQL 会悄悄生成隐藏的 row_id 作为聚簇索引，但无法被 SQL 访问，且可能引发重复值问题。
- 复合主键（如
PRIMARY KEY (user_id, order_id)）会让查询WHERE user_id = ?高效，但WHERE order_id = ?仍需全索引扫描 - 主键一旦设定，修改成本极高：
ALTER TABLE ... DROP PRIMARY KEY会重建整张表；若无新主键，InnoDB 将退化为隐式 row_id，性能与可维护性双双下降 - 自增主键（
id INT PRIMARY KEY AUTO_INCREMENT）的值不保证连续——事务回滚、批量插入失败、INSERT IGNORE都可能导致“跳号”
关系不是靠“想象”建立的，得靠外键（FOREIGN KEY）显式声明
所谓“一对多”“多对多”，在 MySQL 里只是一组 FOREIGN KEY 约束 + 对应索引的组合。没加约束，就只是应用层的约定，数据库完全不管。
- 添加外键前，被引用字段（如
orders.user_id指向users.id）必须已有索引，否则报错ERROR 1005 (HY000): Can't create table ... errno: 150 - 外键列与被引用列的数据类型必须严格一致：比如
users.id是BIGINT UNSIGNED，那么orders.user_id也必须是BIGINT UNSIGNED，差一个UNSIGNED都会失败 - 外键启用级联操作（如
ON DELETE CASCADE）看似方便，但大表删除时可能触发大量隐式更新，导致锁表时间远超预期
真正难的不是写出 CREATE TABLE，而是在业务变化时判断：这个字段该不该加索引？主键要不要拆成联合？外键约束该开还是关？这些决策背后全是存储引擎的行为细节，不是概念背熟就能绕开的。
