教育系统中，学生成绩数据需要实时更新（如考试后立即同步到成绩查询系统），同时保证数据一致性。请分析MySQL、TiDB、Cassandra等数据库的适用性，结合教育系统的特点（如数据一致性要求高、数据量增长快、读写比例），给出数据库选型建议，并说明如何优化数据库性能（如索引、分库分表）。
答案
1) 【一句话结论】教育系统成绩管理场景下，核心业务（成绩录入、查询）优先选用MySQL（或TiDB）保证强一致性，结合数据量增长需求引入TiDB分库分表，Cassandra因弱一致性不适用；优化上通过索引优化（如学号+课程ID复合索引）、读写分离（主库写从库读）、分库分表（按学校ID分库、按课程ID分表）提升性能。
2) 【原理/概念讲解】MySQL是传统关系型数据库，遵循ACID原则，强一致性适合结构化成绩数据（学号、课程、分数等），事务操作能保证数据一致性（如插入成绩后立即同步到查询系统）；TiDB是分布式MySQL，兼容MySQL生态（SQL语法、工具），支持水平扩展（分库分表），高并发下性能稳定，适合业务扩展（如学校数量增加、数据量增长）；TiDB通过分布式事务（两阶段提交）保证强一致性，协调者（Leader）和参与者（Follower）节点间通信可能存在微秒级延迟，但能保证数据一致性；Cassandra是NoSQL数据库，采用最终一致性模型，适合超大规模读/写场景（如全球教育系统），但弱一致性可能导致成绩查询延迟，不适合教育系统的高一致性要求。
3) 【对比与适用场景】
| 数据库 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| MySQL | 传统关系型数据库 | ACID，强一致性，读写均衡，事务支持 | 核心业务（成绩录入、查询、统计） | 单机性能有限，扩展性弱 |
| TiDB | 分布式MySQL | ACID，强一致性，水平扩展，兼容MySQL生态 | 业务扩展（数据量增长、高并发） | 分布式架构复杂度，学习成本 |
| Cassandra | NoSQL数据库 | 最终一致性，高可扩展性，无中心节点 | 超大规模读/写（如全球成绩查询） | 弱一致性，不适合高一致性要求 |
4) 【示例】
成绩更新流程（TiDB分布式事务处理）：
-- TiDB分布式事务示例
START DISTRIBUTED TRANSACTION;
INSERT INTO student_scores (student_id, course_id, score, update_time) VALUES (123, 101, 95, NOW());
COMMIT;
分库分表跨库事务示例（按学校ID分库，按课程ID分表）：
-- 分库分表后跨库事务（假设学校ID=1，课程ID=101）
START DISTRIBUTED TRANSACTION;
-- 分库1（学校ID=1）插入成绩
INSERT INTO school1.course_scores (student_id, course_id, score) VALUES (123, 101, 95);
-- 分库2（学校ID=2）插入成绩
INSERT INTO school2.course_scores (student_id, course_id, score) VALUES (123, 101, 95);
COMMIT;
5) 【面试口播版答案】
“面试官您好，针对教育系统成绩数据实时更新、高一致性的需求，我的核心结论是：核心业务（成绩录入、查询）优先选用MySQL（或TiDB）保证强一致性，结合数据量增长可引入TiDB分库分表，Cassandra因弱一致性不适用。接下来解释原理：MySQL是传统关系型数据库，遵循ACID原则，强一致性适合结构化成绩数据，事务操作能保证数据一致性；TiDB是分布式MySQL，兼容生态且支持水平扩展，适合业务扩展；Cassandra是NoSQL，最终一致性适合超大规模但弱一致性不满足教育系统要求。对比来看，MySQL适合核心业务，TiDB适合扩展，Cassandra不适合高一致性。选型上，教育系统成绩管理用MySQL+TiDB组合，比如成绩录入用MySQL事务保证一致性，然后通过消息队列同步到查询系统；优化方面，通过索引优化（如学号+课程ID复合索引）、读写分离（主库写，从库读）、分库分表（按学校ID分库、按课程ID分表）提升性能。这样既能保证实时更新和一致性，又能应对数据量增长。”
6) 【追问清单】
- “为什么选择TiDB而不是原生MySQL？” → 回答要点：TiDB支持水平扩展，原生MySQL单机性能有限，数据量增长时TiDB可分库分表，而原生MySQL扩展性差。
- “如何处理分布式环境下的数据一致性？” → 回答要点：用TiDB的分布式事务（两阶段提交），协调者与参与者节点间通信可能存在微秒级延迟，但能保证强一致性。
- “分库分表后如何保证跨库事务？” → 回答要点：用TiDB的分布式事务（两阶段提交）或消息队列+补偿机制（但教育系统要求高一致性，故用TiDB事务）。
- “Cassandra的最终一致性如何影响教育系统的成绩查询？” → 回答要点：最终一致性可能导致成绩查询延迟，不适合教育系统的高一致性要求。
- “索引优化策略是什么？” → 回答要点：针对成绩查询的复合索引（学号+课程ID），提升查询性能，同时避免过度索引影响写性能。
7) 【常见坑/雷区】
- 混淆MySQL和TiDB的分布式特性，认为TiDB就是MySQL的分布式版本但忽略其性能差异（如TiDB在分布式场景下有优化，而原生MySQL扩展性差）。
- Cassandra的强一致性误解，认为它有ACID（实际上Cassandra是最终一致性）。
- 分库分表后事务处理错误，比如用MySQL的分布式事务（两阶段提交）的复杂性，或忽略事务隔离级别（如读未提交导致脏读）。
- 忽略读写比例，比如教育系统写多读多，但Cassandra适合读多写少（实际Cassandra适合高并发读写，但弱一致性不满足教育系统要求）。
- 索引优化错误，比如过度索引导致写性能下降，或索引选择不当（如单字段索引而非复合索引）。