在项目管理系统（PMIS）中，需要存储项目进度、成本、资源分配等数据，请设计数据模型（表结构），并说明如何优化查询性能（如索引策略、分库分表策略），以及如何处理数据一致性问题。
答案
1) 【一句话结论】：设计PMIS数据模型时，需构建包含项目、任务（含进度字段）、成本、资源的核心实体表，通过索引优化高频查询，分库分表应对数据量增长，用TCC等分布式事务保障数据一致性，平衡性能与正确性。
2) 【原理/概念讲解】：
采用关系型数据库，通过实体-关系（ER）模型转化为表结构，核心实体包括项目（Project）、任务（Task，新增Progress字段记录任务完成百分比）、成本（Cost）、资源（Resource），表间通过外键关联（如任务表外键关联项目表，成本表外键关联项目表）。
索引策略：B树索引（树形结构，支持范围查询，类比“有序目录”）、哈希索引（哈希表结构，等值查询高效，类比“字典查特定单词”）、全文索引（文本搜索）。
分库分表：垂直拆分（按业务模块，如项目表、任务表分库，减少单库表数）、水平拆分（按数据范围，如按项目ID范围分表，扩展性好），水平拆分需注意数据倾斜（如热门项目数据集中）。
数据一致性：单库用ACID事务（保证原子性等），分布式用TCC模式（Try-Confirm-Cancel三阶段，避免阻塞但增加网络调用开销）。
3) 【对比与适用场景】：
| 索引类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| B树索引 | 树形结构，支持范围查询 | 顺序访问效率高，支持索引下推 | 按ID排序、范围查询（如项目ID>100） | 索引维护成本高，不适合等值查询 |
| 哈希索引 | 哈希表结构，等值查询高效 | 查询速度快，不支持范围查询 | 等值查询（如查询ProjectID=100） | 无法处理范围查询，数据更新时重建索引 |
| 全文索引 | 用于文本搜索 | 支持模糊匹配 | 文本搜索（如任务名称包含“设计”） | 构建成本高，更新慢 |
| 分库分表策略 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 垂直拆分 | 按业务模块拆分表（如项目表、任务表分库） | 减少单库表数，提升单表性能 | 业务模块独立，数据量小 | 跨库查询复杂，需分布式事务 |
| 水平拆分 | 按数据范围拆分表（如按ProjectID范围分表） | 扩展性好，单表数据量可控 | 数据量巨大，需分表 | 数据倾斜风险（如热门项目数据集中） |
| 事务模式 | 定义 | 特性 | 适用场景 | 注意点 |
|---|---|---|---|---|
| ACID事务 | 单库事务，保证原子性等 | 性能高，无网络开销 | 单库操作，数据量不大 | 分布式环境下不可用 |
| TCC模式 | Try-Confirm-Cancel三阶段 | 避免阻塞，性能较高 | 高并发跨库操作 | 增加网络调用和状态检查开销 |
4) 【示例】：
-- 项目表
CREATE TABLE project (
ProjectID INT PRIMARY KEY AUTO_INCREMENT,
ProjectName VARCHAR(100) NOT NULL,
StartDate DATE,
EndDate DATE,
Status VARCHAR(20) DEFAULT '进行中'
);
-- 任务表（新增Progress字段）
CREATE TABLE task (
TaskID INT PRIMARY KEY AUTO_INCREMENT,
ProjectID INT,
TaskName VARCHAR(100),
StartDate DATE,
EndDate DATE,
Status VARCHAR(20),
Progress INT DEFAULT 0, -- 任务完成百分比
FOREIGN KEY (ProjectID) REFERENCES project(ProjectID)
);
-- 成本表
CREATE TABLE cost (
CostID INT PRIMARY KEY AUTO_INCREMENT,
ProjectID INT,
CostType VARCHAR(50), -- 如人工费、材料费
Amount DECIMAL(10,2),
RecordDate DATE,
FOREIGN KEY (ProjectID) REFERENCES project(ProjectID)
);
-- 资源表
CREATE TABLE resource (
ResourceID INT PRIMARY KEY AUTO_INCREMENT,
ResourceName VARCHAR(50),
ResourceType VARCHAR(20), -- 如人力、设备
ProjectID INT,
FOREIGN KEY (ProjectID) REFERENCES project(ProjectID)
);
-- 索引策略
CREATE INDEX idx_project_id ON project(ProjectID);
CREATE INDEX idx_task_project_id ON task(ProjectID);
CREATE INDEX idx_cost_project_id_cost_type ON cost(ProjectID, CostType);
CREATE INDEX idx_task_progress ON task(Progress); -- 进度字段索引
-- 分库分表示例（水平拆分任务表按ProjectID范围）
CREATE TABLE task_1 (LIKE task);
CREATE TABLE task_2 (LIKE task);
-- 分表规则：INSERT INTO task_1 (ProjectID, ...) WHEN ProjectID BETWEEN 1 AND 10000;
-- INSERT INTO task_2 (ProjectID, ...) WHEN ProjectID BETWEEN 10001 AND 20000;
-- TCC事务示例（扣减资源）
BEGIN TRY
-- Try阶段：预检查资源是否足够
SELECT * FROM resource WHERE ResourceID = 1 AND AvailableQuantity >= 10;
-- Confirm阶段：执行扣减
UPDATE resource SET AvailableQuantity = AvailableQuantity - 10 WHERE ResourceID = 1;
COMMIT;
END TRY
BEGIN CATCH
-- Cancel阶段：回滚扣减操作
ROLLBACK;
END CATCH;
5) 【面试口播版答案】：
“面试官您好，针对项目管理系统数据模型设计，我会从表结构、查询优化、数据一致性三方面说明：
首先，核心表设计包括项目表（存储项目基本信息）、任务表（关联项目，新增Progress字段记录任务完成百分比）、成本表（记录成本类型和金额）、资源表（关联项目资源）。表间通过外键关联，比如任务表用项目ID外键关联项目表，确保数据关联性。
其次，查询性能优化：对高频查询字段建索引，比如项目表的主键ProjectID（B树索引，支持范围查询），任务表的ProjectID和TaskID联合索引（B树，支持范围和等值查询），成本表的ProjectID和CostType联合索引（B树，支持范围查询），任务表的Progress字段索引（B树，支持进度范围查询）。
然后，分库分表策略：当数据量超过单库容量时，采用水平拆分任务表（按项目ID范围分表），比如ProjectID 1-10000在表t_task_1，10001-20000在表t_task_2，避免单表过大，同时注意数据倾斜风险。
最后，数据一致性处理：通过TCC模式处理跨库操作，比如扣减资源时，先预检查资源是否足够（Try阶段），再执行扣减（Confirm阶段），如果检查失败则回滚（Cancel阶段），避免数据不一致，虽然TCC模式会增加网络调用和状态检查开销，但适合高并发场景。”
6) 【追问清单】：
- 问：索引选择依据是什么？
回答要点：根据查询模式，B树索引适合范围查询（如按项目ID排序），哈希索引适合等值查询（如查询特定项目ID），避免过度索引导致写性能下降。 - 问：分库分表的具体策略如何选择？
回答要点：垂直拆分适合业务模块独立（如项目表和任务表分库），水平拆分适合数据量巨大（如按项目ID范围分表），需考虑数据倾斜风险，通过分区键（如项目ID）均匀分布数据。 - 问：分布式事务如何处理？
回答要点：采用TCC模式，将操作拆分为Try（预检查）、Confirm（执行）、Cancel（回滚）三个阶段，确保跨库操作原子性，避免数据不一致，适用于高并发场景。 - 问：如何处理并发问题？
回答要点：通过乐观锁（如版本号）控制并发，比如成本表加Version字段，更新时检查版本是否一致，避免脏读。 - 问：如何验证数据一致性？
回答要点：测试分布式事务的异常场景（如网络中断），确保TCC模式能正确回滚，避免数据不一致。
7) 【常见坑/雷区】：
- 索引过多导致写性能下降：避免为非查询字段建索引，定期分析索引使用情况，删除冗余索引。
- 分库分表策略选择错误：水平拆分时未考虑数据倾斜，导致热门项目数据集中在某表，影响查询性能。
- 分布式事务性能开销：TCC模式增加网络调用和状态检查开销，不适合低并发场景。
- 跨库查询复杂：垂直拆分后跨库查询需通过分布式事务或中间件（如MyCat）处理，否则影响性能。
- 数据一致性验证不足：未测试分布式事务的异常场景，导致实际生产中数据不一致。