做数据库这行的，估计都遇到过这种场面：别人伸手问你要表结构，还特意补一句“只要结构，数据一个都不要”。我第一次收到这个需求时，还很认真地回问了一句“要不要把几个常用测试数据也带上，方便你验证？”对方当时就笑了，说SchoolDB那四张表，他们只是要拿去搭空库、做底层评审用，带数据反而碍事。
这事给我的启发很大，“DDL语句”本身就是一个独立交付物。它能精确表达一张表长什么样、字段怎么定义、主外键怎么关联，又不掺任何业务数据。尤其像SchoolDB这类典型教学或展示用数据库，四张核心表的表结构，常被拿去做格式模板、接口联调和教程示例。甚至之前和一个刚入行的朋友聊天，他还把“数据库DDL”和“项目截止日期deadline”搞混，说“明天就要交表结构DDL了”，我们俩笑了半天——不过仔细一想，这两个“DDL”确实都有点让人头大。
整篇内容，我主要想和你聊清楚两件事：一张表的结构该怎么设计、怎么写成合格的DDL；以及当你手头已经有一个现成的库，如何用Navicat、dbstudio或命令行只把结构导出来，不带走任何数据。
1. “只要结构，不要数据”到底是个什么需求
1.1 这个需求在哪些场景下最常出现
先别急着写SQL，把这需求想明白再动手，省得白干。
我遇到的第一个高频场景是环境初始化。测试环境、预发布环境要重建一套库，开发手里已经有生产库了，但生产里的数据不能随便拷到非生产环境，尤其是涉及个人信息、成绩信息这类数据，安全管控很严，拷过去容易出问题。这时候你要的其实只是create table那一段结构，也就是DDL，数据一条都别带。
第二个场景是技术方案评审和技术文档编写。你给架构师看表结构设计，不需要把几十万条记录拍在人家脸上，把字段名、类型、主外键关系写清楚就够了。很多团队的《数据库设计说明书》里，附的就是一张表的建表DDL，干净利落。SchoolDB这种内部演示库，经常被拿去当教学案例，文档里需要的就是“仅有结构”的建表脚本。
第三个场景是联调对接。下游系统需要知道你的接口返回什么字段、你这张表能不能支持某种关联查询，它关心的是字段和约束，不是数据。把表结构DDL发给对方，对方建一个同结构的空表，就能开始联调，不用担心数据维度不匹配。
第四个场景其实也常见：拿一张空表去做性能测试、做灌数前的准备。先把表建出来，结构必须和生产一致，然后自己写脚本造数据。如果拿到一份带历史数据的表，造出来的数据反而不干净，影响测试的准确性。
1.2 写DDL之前，这些设计问题得先对齐
很多新手拿到需求就开始敲键盘，结果建出来的表要么字段不够，要么约束不对，后面反复改。我习惯在动手前先把下面几个问题过一遍：
- 主键怎么选？是用自增整数主键，还是有业务含义的编码字段？
- 字符集和排序规则有没有统一要求？
- 哪些字段业务上必须非空、哪些允许为空？
- 是否需要保留创建时间、更新时间这类审计字段？
- 表之间是物理外键，还是只做逻辑关联？
这些不确认好，后面建出来的表就是返工的起点。SchoolDB虽然在很多人眼里只是个演示项目，但正因为它常被用来教学、演示、联调，表结构反而要更规范，不能因为数据是“假的”就随便设计。把规范做好，这套结构换成生产环境照样能用。
2. SchoolDB四张表的整体设计与表关系
2.1 为什么会是这四张表
SchoolDB一般来说就是围绕教学管理中最核心的“学生选课”业务来建模的。学校这种场景，最朴素的需求就是：学生要选课，老师要教课，课程要有成绩。围绕这个，至少得有四张表：
- student 学生信息表
- teacher 教师信息表
- course 课程信息表
- sc 选课成绩表
你仔细看，这四张表刚好构成了一个最简单的“学生-课程-成绩”三元关系，再加一个“教师-课程”的归属关系。学生和课程是多对多的关系，靠sc这张中间表来解；课程和教师是多对一的关系，course表里加一个授课教师字段就解决了。所以SchoolDB用四张表就能把一整块业务闭环描述清楚，这也是它经常被拿来当示例的原因。
有些资料里会把teacher表和course表合并，或者再加一张院系表department，变成五张、六张表。那个就要看业务范围怎么划定了。如果只需要展示核心的选课成绩关系，四张表是成本最低、也最容易理解的方案。反过来，如果要做完整教务系统，光年级、班级、院系、专业就要加好几张表。我在设计这类演示库时，习惯遵循一个原则：边界先收紧，核心关系优先，后续再加表比删表容易得多。
2.2 表与表之间的主外键关系
四张表之间的关系，我用文字描述一下：
- student：主键是 sid 学号，每名学生唯一。
- teacher：主键是 tid 工号，每名教师唯一。
- course：主键是 cid 课程编号，含外键 tid 指向teacher表，表示这门课由哪位老师教。
- sc：选课成绩表，字段里有 sid、cid、score 和 semester。sid 和 cid 分别外键指向student表和course表，并且(sid, cid)做联合唯一键，确保同一名学生同一门课只能有一条记录。
这个关系模型最关键的设计点在于sc表。它不是student表的一个属性，也不是course表的一个属性，而是独立的一张中间表。中间表可以扩展出很多字段，比如成绩、学期、平时分、考试分、补考标记。如果图省事，把成绩字段直接放进student表或者course表，就会出现大量冗余，多门课的成绩根本存不下来，也没有办法统计平均分、最高分。所以看到过业务经验的人都明白，多对多关系要拆成独立中间表，这就是数据库规范化的基本操作。
2.3 字段类型选择：这里面的取舍很有意思
类型选择这块容易被新手忽略，但恰恰是DDL里最有讲究的部分。
先说字符串。像学号、工号、课程编号，这类字段业务上通常是由固定规则生成的编码，比如“20240001”，长度一般比较稳定。如果长度严格一致，可以考虑char，否则建议用varchar并预留一定余量。姓名、课程名、专业名建议直接varchar，因为没法确定未来会不会超长，给足长度比抠那点空间更划算。这里有个经验：对中文字段如果用utf8mb4，一个汉字占3到4个字节，varchar(50)不要理解成“只能存50个字母”，而是能存50个字符，方向别搞反。
再说数值。学分偶尔会有0.5这种值，所以用decimal(3,1)而不是int；成绩如果是百分制，两位小数基本够用，用decimal(5,2)或者干脆用更小的decimal(4,1)。有人会图省事全用float，这里我说句实在话：涉及精确值（成绩、金额、比例），别用float和double，因为浮点数的存储误差会在计算中放大，关键时刻能让你对不上账。固定精度就用decimal，它才是靠谱的。
日期时间也一样。出生日期用date就够，不需要时分秒。如果还要记录创建、更新时间，就分别加datetime或者timestamp。大部分演示库可以不做得很复杂，但两个基本字段我觉得值得留：create_time和update_time，这在数据排查的时候能救命。
性别用char(1)还是tinyint？我见过两边都有。用char(1)存'M'/'F'直观，用tinyint存0/1省空间。SchoolDB这种教学库，我更推荐char(1)加注释，可读性好，学习者一眼能看懂。生产库可能会根据团队规范选tinyint，这个没有绝对答案，只要全表统一就行。
然后是索引和外键。主键默认就是索引，所以student.sid、teacher.tid、course.cid这些主键字段不用额外加索引。外键字段比如course.tid、sc.sid、sc.cid，如果不加索引，在多表关联时会有性能隐患，建议显式创建。物理外键是否要加，团队之间有争议，但作为DDL教学示例，我倾向于加，因为约束清晰、能防止脏数据。实际生产中如果性能敏感，可能会去掉物理外键只保留逻辑关联，这个要根据业务取舍。还有一点，外键定义需要表引擎统一，MySQL里只有InnoDB支持外键，所以四张表都要用InnoDB，不能有的MyISAM有的InnoDB。
3. 四张表的DDL语句与逐字段说明
前面铺垫那么多，现在直接上干货。下面四份DDL是SchoolDB最基础也最常见的结构版本。字段名和类型你可以根据自己项目调整，但设计思路是通用的。
3.1 学生信息表 student
CREATE TABLE student ( sid VARCHAR(20) NOT NULL COMMENT '学号', sname VARCHAR(50) NOT NULL COMMENT '姓名', gender CHAR(1) DEFAULT 'M' COMMENT '性别：M-男，F-女', birthdate DATE COMMENT '出生日期', major VARCHAR(100) COMMENT '专业', enroll_year SMALLINT COMMENT '入学年份', phone VARCHAR(20) COMMENT '联系电话', email VARCHAR(100) COMMENT '邮箱', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (sid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='学生信息表';这份结构里值得说的地方有几个。
主键选了 sid VARCHAR(20)。真实场景里，如果学号由学校统一编码，业务上唯一，直接用业务编码做主键，后续关联sc表也更直观。缺点是如果学号规则变了，改主键很麻烦。很多真实系统会再加一个自增id作为代理主键，把学号变成普通唯一键，各有利弊。在这个演示库里，我更喜欢业务主键，原因就是简单好懂，和教学场景匹配。
性别字段我加了 DEFAULT 'M'，虽然性别不应该是默认男，但很多教学系统的历史包袱就是这样。如果从零设计，我可能不设默认值，直接必填，让业务层去控制。
email 字段没加唯一索引。原则上学校邮箱应该唯一，但实际数据里可能存在空值和重复历史数据，如果贸然加唯一约束，导入数据时容易报错。所以这里宁可先不加，等数据清洗干净再考虑。
create_time 和 update_time 是审计字段。MySQL 5.7及以上支持 DEFAULT CURRENT_TIMESTAMP 和 ON UPDATE CURRENT_TIMESTAMP，数据写入和更新时不用应用层手动维护时间，非常省心。如果用的是MySQL 5.5或更低版本，ON UPDATE 的写法可能不受支持，需要自己处理，这也是一个版本兼容性问题。
3.2 教师信息表 teacher
CREATE TABLE teacher ( tid VARCHAR(20) NOT NULL COMMENT '教师工号', tname VARCHAR(50) NOT NULL COMMENT '教师姓名', title VARCHAR(30) COMMENT '职称：讲师、副教授、教授', dept VARCHAR(100) COMMENT '所在院系', phone VARCHAR(20) COMMENT '联系电话', email VARCHAR(100) COMMENT '邮箱', hire_date DATE COMMENT '入职日期', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (tid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='教师信息表';teacher表结构本身不复杂，和外键关系中的“被引用”角色有关。course表里会有一个外键指向teacher表，所以在建表顺序上，teacher必须在course之前建，这是外键依赖的自然要求。
职称字段为什么用varchar而不是枚举？如果一个字段的取值范围未来可能变化，用枚举会比较灵活。但有一个很现实的问题：有些学校除了讲师、副教授、教授，还有“研究员”“高级工程师”“外聘专家”等职称，往往会超出枚举的预设值，导致插入失败。所以我把职称放开为varchar，并把约束交给应用层校验。教学库这种规模，放开更省事。
dept 和 major 这类“码表类”字段，如果要做完整的规范化设计，应该拆成院系表department，然后这里只存dept_id。但在四张表的场景里，我保留文本字段，因为拆出第五张表就超出了“四张表”的边界，演示需求也撑不起这个复杂度。代码和文档里可以通过注释说明扩展思路，这比硬塞一张表进来更体现设计感。
还有一点，email和phone没有加唯一索引，和student表同理。教师邮箱理论上应该唯一，但历史数据可能有重复，先不加，后面做数据治理时再补。
3.3 课程信息表 course
CREATE TABLE course ( cid VARCHAR(20) NOT NULL COMMENT '课程编号', cname VARCHAR(100) NOT NULL COMMENT '课程名称', credit DECIMAL(3,1) COMMENT '学分', hours SMALLINT COMMENT '学时', tid VARCHAR(20) COMMENT '授课教师工号', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (cid), KEY idx_course_tid (tid), CONSTRAINT fk_course_teacher FOREIGN KEY (tid) REFERENCES teacher (tid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='课程信息表';course表是四张表里连接“人与课”的桥梁关系比较特殊的位置。
credit用decimal(3,1)，可以存3位数字，保留1位小数，0.5学分这样的小数没有问题。用decimal而不是float，原因前面说了，精确值用浮点容易出偏差。一学分可能看不出差异，但成绩排名、学分绩点这种统计场景，误差会累积。
hours是学时，SMALLINT能存的最大值大约32000，一学期几百个学时足够。如果你见过有些表把学时设成VARCHAR，我只能说那是被应用层的数据污染了，别学。
tid字段我建了普通索引idx_course_tid。这是一个外键字段，也是将来查询“某位老师教哪些课”的高频过滤条件，不加索引，多表关联时全表扫描的代价会很痛。物理外键约束fk_course_teacher保证了tid必须存在于teacher表，防止你给课程关联一个不存在的老师。
这里有一个常见的争议：物理外键到底该不该加？加了以后，删除教师时会受约束，必须先清掉该教师的课程记录，限制了灵活性。但在SchoolDB这种教学场景，我更看重数据完整性，所以保留外键。如果将来做生产，可以考虑去掉外键、应用层保证逻辑关系，降低耦合，这个一定要根据实际项目判断。
3.4 选课成绩表 sc
CREATE TABLE sc ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT '选课记录自增主键', sid VARCHAR(20) NOT NULL COMMENT '学号', cid VARCHAR(20) NOT NULL COMMENT '课程编号', score DECIMAL(5,2) COMMENT '成绩。考试未通过或补考可单独处理', semester VARCHAR(30) COMMENT '学期，如2024-2025-1', create_time DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (id), UNIQUE KEY uk_sc_sid_cid (sid, cid), KEY idx_sc_cid (cid), CONSTRAINT fk_sc_student FOREIGN KEY (sid) REFERENCES student (sid), CONSTRAINT fk_sc_course FOREIGN KEY (cid) REFERENCES course (cid) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='选课成绩表';sc表是整个SchoolDB里最需要用心理解的一张表。
为什么既要有自增主键id，又要有(sid, cid)唯一键？因为sid+cid虽然在业务上能唯一标识一条选课记录，但它属于“业务联合主键”。如果以后出现补考记录、平时分和期末分多条记录的情况，联合主键没法扩展。所以我额外加一个自增id作为代理主键，同时保留(sid, cid)唯一约束，防止同一学期同一学生同一门课程重复插入。这套设计“进可攻退可守”，是中间表的常用姿势。
score用decimal(5,2)，允许空值。可能有同学会问，成绩不是应该必填吗？实际业务里存在“已选课未考试”的情况，成绩没出，不能写0也不能写负数，设置为允许空更合理，等考试成绩出来再UPDATE。
semester用varchar(30)，存“2024-2025-1”这种学期编码。也有人会把学期再拆成year和term两个字段，查询更方便。两种都行，看你们系统怎么约定。我这里保留一个varchar，是因为作为演示库不做过细拆分，注释里已经写清楚格式。
外键方面，sc表引用两张表，所以建表顺序必须是：先有student和course，才能建sc。否则执行建表语句会因为引用了不存在的父表而报错。这条规则在手工写DDL的时候特别容易忘。
4. 只用结构、不帶数据的几个实操办法
DDL怎么写是一回事，怎么从现成库里把结构导出来是另一回事。下面这几个方法，我按工具从图形化到命令行依次讲，你挑顺手的用。
4.1 Navicat 只用表结构怎么导出
Navicat算是数据库图形工具里被用得最多的之一。想要只导表结构，不导数据，操作路径是这样：
- 连接上MySQL实例，在左侧导航树里找到SchoolDB这个数据库。
- 右键点击SchoolDB数据库，弹出菜单里找到“转储SQL文件”。
- 在二级菜单里选择“仅结构”，不是“结构和数据”。
- 指定保存路径，点开始，导出完成后你会得到一个SQL文件，里面只有DROP TABLE IF EXISTS、CREATE TABLE，没有一行INSERT。
这个功能在不同版本里位置略有差异，老的Navicat for MySQL把“转储SQL文件”放在“工具”菜单下，新版本直接在数据库右键菜单里就能看到。如果你遇到右键菜单里没有“仅结构”的选项，多半是版本太老，建议升级，或者用下面这个备选方案。
备选方案：使用“数据传输”功能。在Navicat菜单栏找到“工具”→“数据传输”，源连接和目标连接都选同一个实例，但目标库可以选一个空库，然后在选项里勾选“仅结构”，同样可以完成结构复制。这个方法适合把表结构复制到另一个库或者另一个服务器上。
还有一个非常快的方法：在Navicat左侧预览表结构时，选中一张表，右键选择“复制创建语句”或者“SQL预览”，能直接拿到单表的CREATE TABLE语句，发给同事看单表结构特别方便。
注意，Navicat导出的文件默认会带CREATE DATABASE IF NOT EXISTS和USE语句。如果你只想保留四张表的CREATE TABLE，把前面两行删掉就行，否则导入时会把别人的库名也建出来，容易搞混。
4.2 神通数据库 dbstudio 怎么只备份表结构
神通数据库是国产关系型数据库之一，它自带的图形管理工具叫dbstudio，界面风格和大多数数据库客户端接近。用dbstudio只备份表结构，我的操作习惯是：
- 打开dbstudio，连接到要操作的库/模式。
- 在左侧对象树里找到“表”节点，或者直接在模式（schema）上右键。
- 找“生成DDL”或“导出DDL”这一类功能。不同版本的dbstudio菜单叫法不完全一样，有的叫“生成脚本”，点开后可以看到完整的建表语句，直接复制到SQL编辑器或者导出到文件。
- 如果是要做整库备份，通常在“备份/恢复”向导里，会有“仅备份结构”或“不包含数据”的选项。注意备份时模式和用户的对应关系，导出结构时选择正确的模式，否则得到的DDL可能会带上奇怪的模式名前缀。
这里我补充一个通用思路：不一定要死磕菜单名称。任何图形客户端，导表结构本质上就两种做法，一种叫“生成DDL”，一种叫“备份并勾选不含数据”，你只要找到这两个入口之一，就不会迷路。不同版本的菜单名会变，但逻辑不变。
4.3 命令行只导出表结构：mysqldump 最可控
如果已经连上了MySQL实例，我反而更推荐命令行，操作最可控，也最容易自动化。
mysqldump -u用户名 -p密码 -h主机地址 --no-data SchoolDB > schooldb_structure.sql--no-data 就是只导结构不导数据。如果你只想导出某几张表，在后面加上表名列表：
mysqldump -u用户名 -p密码 -h主机地址 --no-data SchoolDB student teacher course sc > schooldb_4tables.sql这个命令会把四张表的DROP TABLE IF EXISTS和CREATE TABLE都导出来。拿到新库执行前，如果目标是空库没问题，如果目标库里已经有同名表，请先确认要不要DROP或者手动加清除逻辑，否则会覆盖掉已有表。
如果数据库不是MySQL，再看几个对应的工具：
- PostgreSQL：pg_dump -s school_db > school_structure.sql，这里 -s 等价于 --schema-only。
- Oracle：用expdp/impdp时加CONTENT=METADATA_ONLY参数，或者传统exp里用ROWS=N。
- SQL Server：生成脚本向导里选择“仅架构”。
说到底，各家数据库都提供了“只导schema不导数据”的开关，只是参数名不同。理解了原理，换什么库都能顺手。
这里再说一个进阶用法。mysqldump导出的结构文件里，表顺序有可能是随机的。如果里面带了外键，建议在文件开头或第一个CREATE TABLE前加一行：
SET FOREIGN_KEY_CHECKS=0;导入结束再改成1。这能避免因为建表顺序问题导致外键创建失败。
4.4 把表结构导出成表格，方便评审和数据字典
很多人搜“navicat怎么把表结构导出为表格”，其实就是想让表结构变成Excel/Word表格，方便做数据字典或者评审会展示。
方法一：用SQL查信息模式。这个方法最通用，Navicat里打开查询窗口，执行下面这段SQL，然后选中结果集，右键导出成Excel：
SELECT C.TABLE_NAME AS '表名', C.COLUMN_NAME AS '字段名', C.COLUMN_TYPE AS '字段类型', C.IS_NULLABLE AS '是否为空', C.COLUMN_DEFAULT AS '默认值', C.COLUMN_COMMENT AS '注释' FROM INFORMATION_SCHEMA.COLUMNS C WHERE C.TABLE_SCHEMA = 'SchoolDB' ORDER BY C.TABLE_NAME, C.ORDINAL_POSITION;这段SQL把四张表的所有字段、类型、是否可空、默认值、注释一次性列出来。导出成Excel之后，再稍微调下格式，就是一份像模像样的数据字典。这个方式不限于Navicat，dbstudio、DataGrip，只要能执行SQL的客户端都能跑。
方法二：Navicat的“数据字典”功能。在部分版本里，数据库右键菜单有“数据字典”或者“模型”入口，可以生成一份结构化的文档，再导出成PDF/HTML。这个功能平时用的人不多，但做项目交付的时候特别好用。
方法三：只想给研发看单表结构，直接在Navicat里选中表，右键“复制创建语句”，得到的就是那条CREATE TABLE的纯文本，塞到设计文档里完事。
这三个方法我实际都用过，最推荐先学会SQL查information_schema的做法，因为它不依赖客户端版本，任何能连库的工具都能跑。之前我给一个项目补数据字典，四张表几分钟就导完了，比手工复制粘贴快了不知道多少倍。
5. 常见问题与排错实录
5.1 外键约束导不出来，或者导入时顺序混乱
这是只导结构最容易翻车的地方。表之间本身有依赖关系，比如sc表依赖student和course，course依赖teacher。如果导出工具没有帮你把顺序排好，到了新库，sc表先建，student表还没建，直接报外键错误。尤其是命令行mysqldump导出的文件，表顺序不一定按依赖关系排列。
解决思路有几条：
- 用工具导出后，检查生成的SQL是否自带SET FOREIGN_KEY_CHECKS=0。如果没有，在执行文件的开头手动加上，导入完成后改回1。
- 如果一定要保证建表顺序，就按依赖关系倒排：先建teacher，再建course，再建student，最后建sc。
- 也有更彻底的办法：把建表脚本里的FOREIGN KEY子句先去掉，建完所有表之后再通过ALTER TABLE ADD CONSTRAINT补上。日常开发里，我比较喜欢这个思路，它能避免“外键约束导致导来导去全崩”的情况。
ALTER TABLE的补充示例：
ALTER TABLE course ADD CONSTRAINT fk_course_teacher FOREIGN KEY (tid) REFERENCES teacher (tid);这样补外键的好处是，建表过程先完成，再逐一添加约束，哪个外键没建成功，单独排查也容易定位。
5.2 字符集和排序规则对不上
SchoolDB如果新建的时候用了utf8mb4，导出的文件里通常会带ENGINE=InnoDB DEFAULT CHARSET=utf8mb4。但如果你把脚本拿到老环境执行，老库默认字符集是latin1或utf8，CREATE TABLE里又没有显式写字符集，导入时就会按目标库默认字符集建表，中文直接变乱码，或者报“Specified key was too long”这种索引长度超限错误。
解决办法：导出后检查文件里的每个CREATE TABLE，确认都带DEFAULT CHARSET=utf8mb4。如果缺，批量补上。同时留意索引长度问题，varchar(255)在utf8mb4下索引长度会超过1000字节，如果建联合索引多字段，很容易逼近InnoDB的3072字节限制。演示库字段通常没那么长，影响不大，但养成给varchar设置合理长度的习惯很有必要。
另外，导入前还要看目标库的sql_mode。如果目标库的sql_mode比较严格，比如开启了ONLY_FULL_GROUP_BY或NO_ZERO_DATE，可能会因为某些字段默认值不兼容而报错。这时候一般是调整SQL脚本里的写法，而不是去改目标库的全局配置，因为全局配置可能影响其他应用。
5.3 导出成Excel后发现字段对不上、顺序乱
用SQL导出表结构到Excel，我踩过一个坑：如果SELECT *输出，字段顺序是按逻辑层返回的，不一定跟表里物理顺序一致。要保证和CREATE TABLE顺序一致，就必须用ORDINAL_POSITION排序，也就是上面4.4节代码里ORDER BY后面的字段，漏掉这一句，字段顺序就可能乱。
还有一个问题：COLUMN_TYPE显示成“int(11)”“varchar(50)”，括号和数字都带着，如果文档里要的是“数据类型”和“长度”分开的两列，需要把括号拆掉。我一般在SQL里直接用SUBSTRING_INDEX截取，或者导出后在Excel里用分列功能处理，都不难。举个例子，如果你想把“varchar(50)”拆出类型和长度，可以用：
SELECT COLUMN_NAME, SUBSTRING_INDEX(COLUMN_TYPE, '(', 1) AS DATA_TYPE, REPLACE(SUBSTRING_INDEX(COLUMN_TYPE, '(', -1), ')', '') AS DATA_LENGTH FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'SchoolDB';虽然这个小技巧不算复杂，但在整理数据字典时能省下不少手工活。
5.4 导出的SQL里带了奇怪的触发器、视图或者函数
有些图形工具的“备份”功能默认会连带导出触发器、视图、存储过程。如果你只需要四张表的结构，却导出上百行的视图和函数定义，文件会显得很臃肿，对方也可能执行失败。遇到这种情况，优先选择导出选项里“仅数据表”或“不包括视图对象”的开关。如果已经是导出的文件，就手动剔除无关对象，只保留DROP TABLE和CREATE TABLE部分。
SchoolDB这类演示库一般没有复杂的视图和存储过程，但当某个历史库被各种触发器堆满时，这个坑就会很明显。所以拿到结构以后，先看一眼文件内容，别急着发给别人。
6. 写在最后：一份结构脚本要经得起“别人拿去就能建库”
按我的经验，交付一份DDL脚本，最重要的不是它当下能跑，而是隔了三个月、换了一个人执行，也能跑起来。做到这点其实很简单，核心就是三个字：写清楚。表注释、字段注释、外键关系、字符集，该写的都写上。哪怕是一个看起来特别不起眼的性别字段，也把注释写成“性别：M-男，F-女”，而不是简简单单一个“性别”。
SchoolDB这四张表本身不复杂，但如果你把每一张表的结构当成生产环境来对待，把外键、唯一约束、索引都设计到位，这套脚本就能复用，不仅能用于教学演示，也可以作为项目初始结构的参考模板。尤其当别人问你“这个表结构能不能给我的新项目用”的时候，你会发现之前多花的那点设计时间，完全值回票价。
最后再分享一个小习惯：我每次导完结构，都会在测试库里重新执行一遍，执行完再用SHOW CREATE TABLE把表结构看一次，确认和原库一致，再交付出去。这一步只要十几秒，但能帮你省掉后续一大串“这个字段怎么少了”“那个外键怎么没了”之类的来回沟通。
如果你手头的SchoolDB四张表跟我的字段定义不完全一样，那太正常了，每个项目的业务要求不同，设计也会不同。关键是结构设计背后的逻辑你得拿捏住，什么时候用varchar，什么时候用decimal，什么时候该加中间表，这才是真正值钱的东西。
