1.6 数据库相关面试题：

你做过数据迁移，面试官一定会从两个角度追问：一是“不同数据库本身性能有何差异”，二是“迁移过程中你怎么处理性能问题”。下面我把这两条线拧在一起，给你一个既能体现广度又能落地的回答框架。

一、先定调：性能差异的本质

数据库性能不是一个绝对值，而是数据结构 + 存储引擎 + 索引机制 + 并发控制 + 网络/磁盘 I/O的组合结果。老练的回答不是背参数，而是能说清楚：什么场景下，为什么A比B快。

二、关系型数据库性能对比（最常见）

1. MySQL（InnoDB）

• 索引：B+Tree聚簇索引，二级索引回表。
• 事务：MVCC + 行锁，读已提交/可重复读，写多容易锁冲突。
• 适合：中小型OLTP，读多写少，互联网高并发简单查询。
• 性能弱点：分析型大表JOIN、聚合查询慢，单库瓶颈。
• Java优化：批量insert用rewriteBatchedStatements=true，分库分表，读写分离。

2. Oracle

• 索引：B+Tree，但可设反向键索引、位图索引（OLAP），IOT表。
• 事务：多版本并发，行锁，undo表空间管理更精细，锁竞争通常比MySQL轻。
• 适合：大型企业OLTP，复杂事务，高并发写入。
• 性能弱点：授权费用，运维复杂。
• 迁移中：Oracle→MySQL要注意数据类型转换（NUMBER精度），序列→自增主键，PL/SQL存储过程重写。

3. PostgreSQL

• 索引：B+Tree，且支持GiST、SP-GiST、GIN、BRIN多种索引，适应地理、全文、时序等。
• 事务：MVCC通过事务ID实现，无回滚段，vacuum清理，写放大需监控。
• 适合：复杂查询，GIS，分析混合场景。
• 性能优点：并行查询、部分索引、表达式索引很强。

三、NoSQL与新分析型数据库性能差异

1. Redis

• 单线程处理命令，Lua脚本原子性，纯内存操作，10w+ QPS。
• 适合：缓存、计数器、分布式锁、排行榜。
• 迁移中：作为热数据缓存，迁移时预热策略避免雪崩。

2. MongoDB

• 文档模型，二级索引，嵌套数据减少JOIN。
• 写性能：默认write concern可调，无事务时写入很快，4.0后支持多文档事务但损耗性能。
• 适合：日志、爬虫、内容管理，Schema多变。
• 迁移：MySQL→Mongo需重新设计文档结构，经常把关联表嵌套成子文档，查询性能可能指数级提升。

3. Elasticsearch

• 倒排索引，近实时搜索，分片分布式查询。
• 写：不擅长，每秒refresh产生小段，写入吞吐较低。
• 适合：全文检索、日志分析、聚合。
• 迁移：从DB同步到ES做查询加速，注意数据一致性、深分页问题。

4. ClickHouse / Doris

• 列式存储，向量化执行，压缩比高，OLAP分析百亿级数据秒级出结果。
• 不适合：频繁单行更新/删除，不支持高并发点查。
• 迁移：从MySQL同步到ClickHouse做报表，全量→增量用DataX/Flink CDC。

四、从“数据迁移”角度谈性能，最能体现你的实战

面试官听到你做过数据迁移，一定会追问：“迁移时怎么保证性能，不拖垮源库？”

1. 全量迁移优化

• 分批拉取，避免整表锁：用分页游标，id > lastId limit batchSize，加read uncommitted隔离级别减少锁冲突。
• 源库读压力控制：多线程并读取，但限制并发数，Semaphore控制读线程数，避免拖慢线上业务。
• 目标库写入优化：
  • MySQL目标库：关闭binlog、关闭unique_checks、foreign_key_checks，事务批量提交（每2000行提交一次）。
  • HBase/ES：批量Bulk请求，HBase的BufferedMutator。
• 大数据迁移工具：DataX（限速、通道数控制）、Kettle，我自己用Java多线程程序+自定义写入池。

2. 增量同步性能

• Canal + MQ：解析MySQL binlog，投递到Kafka，消费端批量写入目标库。
  • 性能关键：解析binlog顺序消费，目标库写入支持upsert，保证幂等；按主键路由分片并行消费。
• 数据库本身CDC：如Oracle GoldenGate，SQL Server CDC，性能消耗较小但收费。
• 数据比对与补漏：定时任务全量校验行数、checksum，利用CRC32哈希对比，发现差异补录。

3. 异构数据库迁移的坑与性能

• 数据类型转换：MySQL datetime(3) → Oracle Timestamp，时区偏移。
• 大小写敏感：MySQL库表名大小写不敏感 → PostgreSQL严格小写，迁移时要统一引号。
• SQL方言：MySQL的limit 1,10→ Oracleoffset fetch/ 嵌套子查询，ORM 切换注意分页。
• 锁差异：Oracle默认读不加锁，MySQL可重复读有间隙锁，可能导致写入死锁，要改隔离级别。
• 性能差异：我曾把一张2000万行MySQL表迁移到PostgreSQL，复杂分析查询从3s降到200ms，原因是PG的并行seq scan和更好的统计信息。

五、面试话术模板（可以直接用）

“我负责过一次从 MySQL 到 PostgreSQL 的数据迁移，也做过 MySQL 到 Elasticsearch 的实时同步。

对于性能差异，我理解关键是场景匹配：MySQL 适合简单高并发 OLTP，PostgreSQL 分析查询强，ES 做搜索聚合，列式库做报表。迁移时全量我采用了分页游标 + 多线程分段读，目标端关闭约束批量提交，并用 DataX 管道化传输；增量用 Canal + Kafka + 消费端批量 upsert，保证有序和幂等。遇到过 Oracle 迁 MySQL 时 NUMBER 精度丢失问题，以及 PG 的 vacuum 对写入性能影响，都通过监控和参数调优解决了。

所以我的体会是：没有最好的数据库，只有最匹配场景的数据库，迁移的核心是评估源和目标在数据模型、事务、索引、写入机制上的差异，针对性设计数据流和异常处理。”

这段话一出来，面试官就会知道你不只是会用数据库，而是真实操盘过跨库迁移，并且有性能全局视野。还有什么具体场景需要细化的，可以继续深入。这个问题看似基础，但如果你能结合数据模型、事务保证、扩展方式和迁移实战来讲，就能迅速拉开与其他候选人的差距。我从老练的 Java 工程师视角，把这两个概念讲透。

一、关系型数据库（RDBMS）

1. 核心定义

以关系模型（表）组织数据，使用结构化查询语言（SQL）进行访问，强调数据的一致性和完整性。
数据之间通过外键建立关联，遵循 ACID 事务特性。

2. 典型产品

• MySQL、PostgreSQL、Oracle、SQL Server、DB2。

3. 核心特征

• 表与模式：预先定义 Schema，字段类型、长度、约束明确，修改 Schema 成本较高。
• 结构化查询语言：标准 SQL，复杂的 JOIN、子查询、聚合函数。
• ACID 事务：原子性、一致性、隔离性、持久性，适合金融、订单等强一致场景。
• 扩展方式：传统纵向扩展（升级硬件），也可通过分库分表、读写分离横向扩展，但成本较高、跨库事务复杂。
• 索引：通常采用 B+Tree，支持范围查询、排序，适合 OLTP。

4. Java 开发中的映射

• JDBC Template、MyBatis、JPA/Hibernate，自动生成 SQL，管理连接池。
• 事务管理@Transactional，依赖数据库行锁、MVCC。

二、非关系型数据库（NoSQL）

1. 核心定义

不局限于关系模型，采用键值、文档、列族、图等结构，通常牺牲部分一致性换取高性能、高可扩展性。
遵循 BASE（Basically Available, Soft state, Eventually consistent）思想。

2. 典型分类与代表

3. 核心特征

• Schema-less：无需预定义结构，文档字段可动态变化，适合敏捷开发。
• 非 SQL 查询：各有自己的查询语言或 API（如 MongoDB 的聚合管道，Redis 的命令）。
• 事务支持不一：早期多数不支持，现在 MongoDB、Redis 等开始支持弱事务，但性能开销大，不适合强一致场景。
• 高可扩展：天然支持分布式，数据自动分片，横向扩展简单，适合大数据量、高并发。
• 特殊索引结构：LSM-Tree、倒排索引、哈希索引等，针对特定场景优化。

三、核心区别对照表（面试时可瞬间列出）

四、在数据迁移中的体会（体现实战深度）

如果你做过迁移，一定会感受到这种差异的冲击：

• MySQL → MongoDB：需要将关联表内的数据合并成嵌套文档，原本的 JOIN 变成一次文档查询，性能可能提升几十倍，但牺牲了关联表的灵活性，更新时需要重写整个文档。
• Oracle → MySQL：要去除存储过程，数据类型（NUMBER）映射要注意精度丢失，序列改为自增主键，事务隔离级别从读提交改为可重复读，可能引发间隙锁死锁。
• MySQL → Elasticsearch：索引不再是 B+Tree，而变成倒排索引，原本的精确查询依然快，但LIKE '%keyword%'变成了全文搜索，性能质变，同时写入性能下降，必须用异步同步保证一致。
• 混合架构经验：订单表用 MySQL 保证事务，订单检索走 ES，缓存用 Redis，报表数据同步到 ClickHouse。
  这正是“不是替换，而是互补”的落地理念。

五、面试话术模板（一口清）

“关系型数据库的核心是关系模型和 ACID 事务，典型如 MySQL、Oracle，适合需要严格一致性的业务。
非关系型数据库是 NoSQL，种类很多，我常用 Redis 做缓存、MongoDB 存非结构化数据、ES 做搜索。它们的优势是 schema 灵活、横向扩展容易、特定场景性能极高。
在迁移项目中，我最大的感触是必须根据数据模型和查询方式重新设计结构，比如从 MySQL 迁到 MongoDB 时要把多表关联拍平成嵌套文档，同时评估事务场景的取舍。生产上我们通常是混合架构，各取所长。”

这套回答既讲清了概念，又融入了迁移和选型的实战思考，面试官一定会认为你对数据库有全面且落地的理解。
TDSQL 是腾讯自研的分布式数据库，在面试中问这个，面试官想看你对国产化替代、分布式数据库架构、以及与传统 MySQL 的差异有没有真实认知。我从 Java 工程师最关心的几个维度给你拆解。

一、TDSQL 的定位：不止是“国产 MySQL”

TDSQL 分为两个版本：

• MySQL 集中式版：对标传统单机 MySQL，增强安全、审计、加密，用于满足信创要求。
• PostgreSQL 版：兼容 Oracle 语法，适合去O。
• 分布式版（重点）：原生分布式，支持水平扩展，这是面试核心。

一句话总结：它是“金融级分布式数据库”，兼顾强一致和高可用。

二、核心架构与新技术属性

1. Shared-Nothing 架构 + 自动分片

• 数据按分片键（如用户ID）分散到多个 SET（物理节点组），每个 SET 内部一主多从。
• 应用层无需关心路由，原生分布式查询引擎自动解析 SQL 并下推。
• 新增属性：在线线性扩缩容，添加新 SET 后自动 Rebalance，业务无感知。

2. 全局一致性读（Global Consistent Read）

• 传统的 MySQL 分库分表方案（Sharding-JDBC、MyCAT）很难保证跨分片读全局一致。
• TDSQL 引入全局事务管理器（GTM），结合Paxos/Raft 一致性协议，实现跨分片的强一致读。
• 对 Java 开发影响：@Transactional跨分片操作时，不再需要自己处理最终一致性。

3. 强同步复制（MAR）

• 主库提交事务需等至少一个备库确认日志落盘，保证数据零丢失。
• 相比 MySQL 的半同步复制，TDSQL 使用 Raft 协议，避免主库故障时日志丢失。
• 同城双活、两地三中心部署，RPO=0。

4. HTAP 混合负载

• 同时支持 OLTP（交易）和 OLAP（分析），通过列存引擎和智能路由实现。
• 一条 SQL 可能被查询优化器自动路由到行存或列存，不需要 Java 代码改动。

5. 多级安全策略

• 国密算法加密、SQL 审计、敏感数据脱敏、强制访问控制，完全满足等保三级、金融行业要求。

三、与传统 MySQL 及其他分布式数据库的对比优势

Java 集成优势：

• 完全兼容 MySQL 协议，JDBC 连接串直接换 IP/端口，代码零改动。
• 分布式事务用@GlobalTransactional或直接@Transactional，TDSQL 内部协调。

四、在数据迁移与性能上的经验（结合你的背景）

如果你曾迁移到 TDSQL：

• 迁移工具：腾讯 DTS 支持 MySQL → TDSQL 全量+增量实时同步，延迟在秒级。
• 分片键选择：必须根据业务最频繁的查询设计，例如订单表用user_id，避免跨分片查询。
• 性能对比：单分片 TPS 与原生 MySQL 相当，但多分片后线性增长；复杂跨分片 SQL 稍有消耗，但比传统中间件方案好很多。
• 避坑：事务中避免跨分片过大操作；二级索引需要包含分片键或创建全局索引（消耗略高）。

五、面试话术模板

“TDSQL 我了解它的分布式版，是 Shared-Nothing 架构，自动分片，通过 GTM 实现跨分片强一致。相比我们自己用 Sharding-JDBC 分库分表，它的好处是 SQL 完全透明、扩容在线、主备强同步无数据丢失。
在 Java 侧几乎无感，JDBC 连接兼容 MySQL，原先的 MyBatis 代码不用改。我们也评估过，在金融场景下，用 TDSQL 替代 MySQL + 分库分表能省掉大量中间件运维和一致性补偿代码。迁移时通过 DTS 同步，关键要选对分片键，避免跨分片事务过大。”

这样回答，既体现了你对国产数据库的了解，又展示了从 Java 实战出发的选型思考。