在招聘信息推荐系统中，需要存储大量招聘信息（如岗位名称、要求、单位信息、发布时间等）和用户信息（如求职者技能、偏好）。请设计数据库表结构，并说明关键字段的设计思路（如索引、外键的使用）。

1) 【一句话结论】设计包含“单位信息”“招聘信息”“用户信息”三个核心表，通过外键关联建立表间关系，并针对发布时间、岗位名称等高频查询字段建立索引，确保数据完整性与查询效率。

2) 【原理/概念讲解】数据库表设计需遵循范式，减少冗余。主键（如自增ID）唯一标识记录，外键（如单位ID）建立表间关联（如招聘信息属于某个单位）。索引（如B树索引）加速查询，例如按发布时间排序或搜索岗位名称时，索引能快速定位数据。类比：招聘信息表是“岗位库”，单位表是“单位库”，外键是“岗位库里的单位编号”，索引是“岗位库的目录页，快速找到最新发布的岗位”。

3) 【对比与适用场景】

类别	类型	定义	特性	使用场景	注意点
主键	自增ID	表中唯一标识记录	不可空，唯一，自增	大多数表（如招聘信息、用户信息）	避免频繁更新
外键	单位ID	关联单位表主键	不可空，引用主键	建立表间关系（招聘属于单位）	可级联删除/更新（可选）
索引	发布时间（普通索引）	加速按时间查询	非唯一	查询最新发布岗位	索引列不宜过多，避免更新开销
索引	岗位名称（全文索引，可选）	加速文本搜索	可唯一/普通	搜索岗位关键词	全文索引适用于文本，提升搜索效率

4) 【示例】（SQL伪代码，最小可运行示例）：

-- 单位信息表（存储招聘单位）
CREATE TABLE unit (
    unit_id INT PRIMARY KEY AUTO_INCREMENT,
    unit_name VARCHAR(100) NOT NULL,
    address VARCHAR(200)
);

-- 招聘信息表（存储岗位详情，关联单位表）
CREATE TABLE job (
    job_id INT PRIMARY KEY AUTO_INCREMENT,
    job_name VARCHAR(100) NOT NULL,
    requirements TEXT,
    unit_id INT,
    publish_time DATETIME NOT NULL,
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (unit_id) REFERENCES unit(unit_id) -- 外键关联单位表
);

-- 用户信息表（存储求职者技能与偏好）
CREATE TABLE user_info (
    user_id INT PRIMARY KEY AUTO_INCREMENT,
    skills TEXT,
    preferences VARCHAR(255),
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- 索引设计（优化查询）
CREATE INDEX idx_publish_time ON job(publish_time); -- 按发布时间排序
CREATE INDEX idx_job_name ON job(job_name); -- 按岗位名称搜索（全文索引更优）

5) 【面试口播版答案】（约80秒）：
“面试官您好，针对招聘信息推荐系统，我设计三个核心表：单位信息表、招聘信息表、用户信息表。首先，单位信息表存储单位的基本信息（单位ID、名称等），招聘信息表通过外键（单位ID）关联单位表，包含岗位名称、要求、发布时间等；用户信息表存储求职者的技能和偏好。关键设计思路：主键用自增ID确保唯一，外键建立表间关系（如招聘属于单位），针对高频查询字段（发布时间、岗位名称）建立索引，加速查询。比如按发布时间排序最新岗位，或搜索岗位名称时，索引能快速定位数据。这样既保证数据完整性，又提升查询效率。”

6) 【追问清单】

• 问：为什么用自增ID而不是UUID？
  答：自增ID存储效率高，占用空间小，适合主键，且数据库自动生成，减少手动操作。
• 问：如何处理用户对多个岗位的偏好？
  答：用户信息表存储技能和偏好，若需记录用户浏览或申请的岗位，可增加“浏览记录”表，用外键关联用户和招聘信息，实现多对多关系。
• 问：索引会带来什么问题？
  答：索引会增加存储空间，更新数据时（如修改发布时间）会额外开销，需权衡查询和更新的频率，避免过度索引。
• 问：数据量很大时，如何优化？
  答：可分库分表（如按单位或发布时间分表），或使用全文搜索引擎（如Elasticsearch）处理岗位名称和要求的文本搜索，提升搜索效率。

7) 【常见坑/雷区】

• 坑1：忽略外键约束，导致招聘信息表中的单位ID无效，数据不一致。
• 坑2：未为高频查询字段建索引，导致查询慢，影响用户体验。
• 坑3：主键设计不当，如用字符串类型或UUID作为主键，导致存储空间大，索引效率低。
• 坑4：字段类型选择错误，如发布时间用字符串存储，无法进行时间排序。
• 坑5：未考虑数据冗余，如单位信息在招聘信息表中重复存储，导致数据不一致和存储浪费。