深圳大学的科研管理系统需要存储大量科研数据（论文、项目、成果等），并支持复杂查询（如按导师、学科、时间范围检索）。请设计数据库模型，并说明如何优化查询性能（如索引策略、分库分表）。
答案
1) 【一句话结论】针对深圳大学科研管理系统，采用关系型数据库存储结构化科研数据（论文、项目），对象存储（如MinIO）存储非结构化数据（全文、图片），通过复合索引覆盖查询条件、索引下推优化，结合垂直分片（按业务表拆库）与水平分片（按学科ID哈希分表、时间范围范围分表），并采用哈希分片+虚拟分片解决数据倾斜，最终提升大规模数据查询性能。
2) 【原理/概念讲解】科研数据分为结构化（如论文标题、导师ID）和非结构化（全文、图片）。结构化数据需事务一致性，用关系型数据库（如MySQL）；非结构化数据存储成本高，用对象存储（如MinIO），数据库仅存储文件路径（路径指向对象存储）。索引优化：复合索引（如mentor_id, subject_id, publish_date）覆盖常用查询，索引下推（MySQL 5.6+）提前过滤数据，减少回表。分库分表：垂直分片按业务表拆分（论文、项目分不同库），水平分片按分片键拆分（论文表按学科ID哈希分表，项目表按时间范围范围分表）。分片键选择：哈希分片（均匀分布，如subject_id % 8）避免倾斜，若倾斜则用虚拟分片（如subject_id + publish_date % 8）。
3) 【对比与适用场景】
| 策略类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 垂直分片 | 按业务表拆分，每个分片含部分表 | 单表数据量减少，跨表JOIN复杂 | 论文、项目等业务表数据量差异大 | 需跨库JOIN，依赖中间件（如MyCat） |
| 水平分片 | 按分片键拆分同一表数据 | 单表数据分散，查询需指定分片 | 论文表（按学科ID）、项目表（按时间） | 分片键选择影响数据分布，需均匀 |
| 分片键策略 | 选择分片键的规则 | 哈希分片（均匀）、范围分片（有序）、组合分片（多字段） | 数据倾斜场景 | 虚拟分片（动态调整）解决倾斜 |
4) 【示例】
论文表（结构化数据）：
CREATE TABLE paper (
paper_id INT PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(200),
author VARCHAR(100),
mentor_id INT,
subject_id INT,
publish_date DATE,
file_path VARCHAR(255) -- 指向MinIO的路径（如：minio.sdu.edu.cn/papers/2023/123.pdf）
);
-- 复合索引覆盖查询
CREATE INDEX idx_mentor_subject_date ON paper (mentor_id, subject_id, publish_date);
-- 分库分表示例（按学科ID哈希分片，分8个库）
-- db1.paper1 存储subject_id % 8 = 0的论文
-- db2.paper2 存储subject_id % 8 = 1的论文，依此类推
5) 【面试口播版答案】
面试官您好，针对深圳大学科研管理系统的需求，我设计的数据库模型核心是混合存储结构化与非结构化数据，并优化查询性能。首先，结构化数据（论文、项目）用关系型数据库（如MySQL），因为需要事务一致性；非结构化数据（论文全文、图片）用对象存储（如MinIO），数据库仅存储文件路径，避免存储成本过高。然后，索引优化：为论文表添加复合索引（导师ID、学科ID、发布时间），覆盖“按导师+学科+时间范围检索”的查询，索引下推（MySQL 5.6+）可提前过滤数据，减少回表次数。分库分表方面，考虑到不同学科（如计算机、数学）的论文数据量差异大，采用垂直分片（论文、项目分不同库），同时对于数据量大的论文表，按学科ID哈希分片（如subject_id % 8），分散数据量；项目表按时间范围范围分片（如按年分表），避免近期数据集中。分片键选择上，哈希分片能均匀分布数据，若学科ID分布不均，可结合时间范围作为虚拟分片键（如subject_id + publish_date % 8），解决数据倾斜。总结来说，通过混合存储、复合索引、分库分表及分片键优化，能有效提升大规模科研数据的查询性能，比如分库分表后查询响应时间从秒级缩短，QPS提升（理论依据是数据分散减少单库压力）。
6) 【追问清单】
- 问：分库分表后，如何保证跨库事务的一致性？
回答要点：跨库事务可通过两阶段提交（2PC）实现强一致性，但可能存在延迟或失败；若对一致性要求不高，可采用最终一致性（如异步复制），结合补偿机制保障数据一致性。 - 问：分片键选择不当导致数据倾斜，如何解决？
回答要点：若分片键（如学科ID）分布不均，可采用虚拟分片（如按学科+时间范围组合分片键），或结合多个字段（如subject_id + publish_date）作为分片键，确保数据均匀分布。 - 问：非结构化数据存储在对象存储，数据库存储路径，是否会影响查询性能？
回答要点：对象存储的读取速度较慢，但通过CDN加速或预取策略，可减少对数据库的压力；数据库仅存储路径，查询时通过路径拼接访问对象存储，整体性能影响可控。 - 问：索引过多会影响写性能，如何平衡？
回答要点：优先设计覆盖索引（包含查询所需所有字段），减少回表；定期分析慢查询日志，优化索引；对于写密集型场景，可考虑读写分离（主从复制），主库负责写，从库负责读。
7) 【常见坑/雷区】
- 分片键选择导致数据倾斜：如按时间范围分片，近期数据集中在一个分片，导致该分片压力过大，需选择均匀分布的分片键（如哈希取模结合多个字段）。
- 跨库事务的延迟：两阶段提交可能导致事务延迟或失败，需评估业务场景是否需要强一致性，若允许最终一致性，可降低延迟。
- 非结构化数据存储的冗余：若多个表引用同一非结构化数据，需统一存储路径，避免冗余，可通过对象存储的版本控制或引用计数管理。
- 索引过度设计：添加过多索引影响写性能（如插入、更新），需评估索引必要性，优先覆盖常用查询的索引。
- 分库分表后跨库查询复杂：垂直分片后，跨表JOIN需要跨库操作，需通过中间件（如MyCat）优化路由，否则影响性能，需评估业务场景是否需要频繁跨库查询。