一、为什么我又写了一篇数据库八股文数据库在Java面试里的地位基本等于高考里的数学。你可以不喜欢但躲不掉。前两篇写了索引、事务、日志、锁这些基础但我在面试候选人和帮朋友做模拟面试时发现真正把候选人卡住的往往不是那些大而全的原理题而是几个看起来“偏实战”的方向——死锁的具体排查、唯一约束引发的一连串问题、数据库同步工具怎么选、以及这两年突然火起来的向量数据库和国产数据库适配。这篇第三篇我挑的就是这些方向。它们有一个共同特点网上资料不少但大多是零散的博客或者官方文档翻译很少有人告诉你面试官到底想听什么也没人告诉你实际项目里踩过哪些坑。所以这篇我不打算写那种“背诵版”的面试题答案而是把每个主题按“面试怎么问 底层原理 实际排查/实战过程”的节奏来讲你读完不仅能应付面试回到工位上遇到类似问题也知道从哪里下手。如果你是准备校招或跳槽的Java开发这篇可以直接当复习提纲用如果你是有几年经验但没系统梳理过这些点的工程师相信也能找到一些值得收藏的细节。二、数据库死锁会背四个条件远远不够2.1 面试官真正想听的标准答案与场景题“什么是死锁产生死锁的四个必要条件是什么”——这几乎是数据库面试的必问题。标准的背诵版本是互斥、持有并等待、不可剥夺、循环等待。但如果面试官只问到这里说明他还没打算深挖。真正容易把人问住的是紧接着的追问“你遇到过死锁吗线上怎么排查的怎么解决”先说最经典的死锁场景也是面试官最常挂在嘴边的例子。两个事务都先更新一条记录再更新另一条但更新的顺序正好相反-- 事务A START TRANSACTION; UPDATE account SET balance balance - 100 WHERE id 1; UPDATE account SET balance balance 100 WHERE id 2; COMMIT; -- 事务B START TRANSACTION; UPDATE account SET balance balance - 100 WHERE id 2; UPDATE account SET balance balance 100 WHERE id 1; COMMIT;事务A先锁了id1的行事务B先锁了id2的行接着事务A想锁id2发现被B持有事务B想锁id1发现被A持有。两个事务互相等待谁也不让谁死锁就诞生了。这个例子我在面试里说了一百遍它背后的核心其实是加锁顺序一致性——两个事务以不同的顺序去触碰同一组资源就为死锁埋下了伏笔。但真实业务里的死锁比这个复杂得多。比如我遇到过的一个线上案例一个订单服务先更新订单状态再插入一条操作日志另一个定时任务先查日志表再批量更新订单状态。看起来两个操作碰的不是同一张表但实际底层因为外键约束或二级索引锁的范围可能比你想的大得多。这就是为什么不能只背定义要真正理解锁的粒度。2.2 线上死锁排查从日志到定位的完整过程排查死锁第一件事是看死锁日志。MySQL里有两个入口-- 查看最近一次死锁信息 SHOW ENGINE INNODB STATUS;如果想记录所有死锁日志可以打开系统参数[mysqld] innodb_print_all_deadlocks ON死锁日志的信息量很大但关键就几块事务1持有什么锁、在等什么锁事务2持有什么锁、在等什么锁最后InnoDB判定回滚了哪个事务。我总结了一个快速定位技巧先找日志里“TRANSACTION”段落看两个事务的“WAITING FOR THIS LOCK TO BE GRANTED”里面会明确告诉你锁在哪个索引的哪个记录上然后顺着这个锁逆推业务代码基本就能定位到是哪两条SQL。以我那个订单案例为例最后定位出来订单状态更新走了主键id但日志表插入时因为有个订单号的唯一索引触发了对已存在记录的检查锁duplicate key check两个事务在订单号和主键两棵索引树上形成了交叉等待。解决方式也很直接——把定时任务改成先更新订单状态再做日志写入统一了资源访问顺序死锁就消失了。排查死锁有个常见误区不要一上来就加锁超时时间或者把所有隔离级别降到READ UNCOMMITTED。加锁超时innodb_lock_wait_timeout只能让报错提前暴露不能从根本上解决问题隔离级别调整则会引入脏读等新问题。正确的思路永远是定位到具体SQL看能不能通过调整事务顺序、缩小事务范围、统一加锁顺序来消除循环等待。三、唯一约束与重复数据增删改查里最容易翻车的地方3.1 MySQL处理重复键的三种方式别再只会报错面试里经常出现这样的题目“往一张有唯一索引的表里插入重复数据怎么处理”很多人第一反应是“报错啊Duplicate entry”。对但面试官想听的是你有没有处理方案。MySQL里处理重复键主要有三种方式我先把它们列个对比方式语法行为适用场景INSERT IGNOREINSERT IGNORE INTO ...冲突时静默忽略不报错幂等写入重复数据直接丢弃ON DUPLICATE KEY UPDATEINSERT INTO ... ON DUPLICATE KEY UPDATE ...冲突时执行更新操作存在则更新不存在则插入REPLACE INTOREPLACE INTO ...冲突时先删除旧行再插入新行需要完全替换整行数据这三种方式看着相似但底层逻辑差异很大。INSERT IGNORE一旦遇到任何错误不只是唯一键冲突都会降级为警告可能导致数据“悄悄丢失”所以线上用的时候要谨慎。ON DUPLICATE KEY UPDATE是应用最广的但它有个坑如果表上有多个唯一索引冲突时MySQL可能选错触发条件。REPLACE INTO最“暴力”它是先删后插所以会改变自增主键的值有外键引用时还可能直接失败。我实际使用中还有个经验批量导入场景下ON DUPLICATE KEY UPDATE会影响affected rows的计数用JDBC的executeBatch时容易出现返回行数和预期对不上的问题。如果不关心更新结果用INSERT IGNORE更省事如果一定要明确知道哪些数据被插入了、哪些被更新了那宁可自己先去查一遍冲突再分两条SQL处理。3.2 表里已经有重复数据怎么加唯一约束这是一个非常典型的“课程设计级需求”但实际项目里也经常出现一张表因为历史原因已经攒了一堆重复数据。现在业务要求某个字段或字段组合必须唯一DBA直接执行ALTER TABLE user ADD UNIQUE KEY uk_name(name);大概率会报错——因为已有重复值唯一索引根本建不出来。正确做法是先看重复情况再决定怎么去重。第一步找出重复数据。比如要保证name字段唯一先统计一下重复SELECT name, COUNT(*) AS cnt FROM user GROUP BY name HAVING cnt 1;第二步决定保留哪一条。一般策略是保留id最小的一条最早的数据或者按业务需求保留最新的一条。假设保留每条记录中id最小的那行删除多余重复行DELETE u1 FROM user u1 JOIN user u2 ON u1.name u2.name AND u1.id u2.id;这个写法比子查询快很多在数据量大时体感差别非常明显。第三步重新执行建唯一索引ALTER TABLE user ADD UNIQUE KEY uk_name(name);这里还有一个高频考点唯一索引对NULL值不起约束作用。也就是说name字段允许为NULL时两张记录的name都是NULL并不会被唯一索引拦住。这个问题面试也会问很多人会答错。我在实际项目里就踩过需求要求某个选填字段不能重复但没想清楚NULL值的含义最后是用“空字符串代替NULL”才保证了唯一性。如果你也遇到这种问题一定要先和业务确认空值到底允不允许出现多条。四、数据库同步主从复制、工具选型与一致性保障4.1 主从复制与Binlog理解同步的地基数据库同步相关的热词这两年热度一直很高什么“数据库同步工具”、“数据库同步软件”搜索量居高不下。但很多人一上来就聊工具忽略了底层的地基——同步到底在同步什么答案是binlog。MySQL主从复制的核心流程是主库把数据变更写入binlog从库的IO线程把binlog拉过来写到本地relay log然后SQL线程执行relay log里的语句完成数据回放。看起来简单但面试官很喜欢在这里挖细节比如binlog的三种格式STATEMENT记录原始SQL语句日志量小但某些函数NOW()、UUID()在从库执行时结果可能不一致。ROW记录行的变更前后值最精确日志量大是目前生产环境默认推荐格式。MIXED混合模式MySQL自动判断用哪种。如果你做数据同步比如用Canal监听binlog同步到ES、Redis或者数仓binlog_format必须设为ROW。因为ROW格式能拿到每行变更前后的完整数据这是增量同步的基础。很多新手在配置同步工具时不注意这一点结果解析出来发现字段缺失或者数据对不上排查半天才发现是binlog格式的问题。另一个面试高频点是从库延迟。主从延迟怎么估算简单的方法在主库执行SELECT NOW()记录时间在从库执行SHOW SLAVE STATUS看Seconds_Behind_Master参数然后对比主从时间差。但这只能算近似值要更精确地定位延迟发生在哪个环节需要看IO线程和SQL线程的状态。如果SQL线程一直在跑但Seconds_Behind_Master持续上涨说明从库的SQL执行能力跟不上主库的写入速度这时候就要考虑从库硬件升级、并行复制参数slave_parallel_workers调优或者干脆做读写分离架构的改造。4.2 常见同步工具对比与选型建议聊完地基再聊工具。网上搜“数据库同步工具”会出现一堆名字我按实现原理把它们分成几类这样你选型时思路会清晰很多类别代表工具原理适用场景binlog订阅型Canal、Maxwell、Debezium伪装成从库拉取binlog实时解析增量数据同步到ES/Redis/消息队列ETL批量型DataX、Kettle定时或离线抽取全量增量异构数据源迁移、数仓批量同步数据库原生复制MySQL主从、PG流复制数据库内核自带复制机制高可用、读写分离文件导入型mysqldump、DTS逻辑备份/物理迁移数据库迁移、版本升级实际项目里选型主要看两个维度实时性要求和数据量级。要求秒级实时、且下游是中间件ES、Redis、MQCanal是Java技术栈里的首选如果就是做一次性数据迁移DataX更简单粗暴如果是异构库之间的实时同步Debezium生态更完整但运维成本也更高。我记得有一次做课程设计需求是把MySQL的数据实时同步到另一个业务系统里。当时图省事用定时任务每天全量同步结果因为数据量增长全量同步时间越拖越长最终被业务方投诉。后来改成先做一次基础全量同步再用Canal订阅binlog做增量同步才真正解决了问题。这种“先全量、后增量”的思路是数据同步项目里最常用也最稳妥的起步方案。五、向量数据库Java面试里突然火起来的新考点5.1 向量检索的核心概念Embedding、相似度与索引“向量数据库”这个词在热搜词里出现得越来越频繁。我记得前两年聊数据库基本绕不开关系型、NoSQL、NewSQL但2023年之后向量数据库就成了面试里可能突然冒出来的“超纲题”。为什么会这样因为大量业务开始涉及语义搜索、图片相似检索、推荐系统而这些场景底层都是向量检索。面试里面向量数据库先问的一定是向量是什么简单理解就是把一段文本、一张图片或者一个用户行为通过模型比如BERT、Word2Vec转换成一个固定维度的浮点数数组。这个数组里不仅包含数据本身的特征还能通过数学计算衡量两个数据之间的相似度。最常用的三种相似度计算余弦相似度看两个向量的方向是否一致值越接近1越相似适合文本语义场景。欧氏距离看两个向量在空间中的直线距离距离越短越相似适合图像特征场景。点积考虑方向也考虑模长适合向量已经归一化的场景。有相似度还不够还要有高效的索引。因为暴力计算所有向量的相似度在大规模数据下完全不可行。向量数据库的核心就是各种近似最近邻ANN索引算法最常用的是HNSWHierarchical Navigable Small World它的思路可以理解为先有一个粗粒度的连接图能快速找到可能是近邻的区域再在细粒度上精确定位。学习成本有点高但你只需要记住HNSW是性能和召回率比较平衡的方案多数主流向量数据库都支持。5.2 Java项目接入向量数据库的实测体验Java后端接入向量数据库和接MySQL在编程模型上差异不大核心是把之前“查SQL”换成“查向量”。以下是我用一个开源向量数据库做的简单demo数据插入和检索都不复杂。// 引入客户端依赖后建立连接 MilvusServiceClient client new MilvusServiceClient( ConnectParam.newBuilder() .withHost(127.0.0.1) .withPort(19530) .build()); // 构建一个集合类似关系型数据库的表 CreateCollectionParam createParam CreateCollectionParam.newBuilder() .withCollectionName(demo_collection) .withDimension(512) .build(); client.createCollection(createParam); // 插入向量数据 ListListFloat vectors new ArrayList(); // 这里实际项目中 vectors 来自模型推理结果比如文本的 embedding InsertParam insertParam InsertParam.newBuilder() .withCollectionName(demo_collection) .withVectors(vectors) .build(); client.insert(insertParam); // 查询与某个向量最相似的 TopK 条 ListListFloat searchVectors new ArrayList(); searchVectors.add(queryVector); SearchParam searchParam SearchParam.newBuilder() .withCollectionName(demo_collection) .withVectors(searchVectors) .withTopK(10) .build(); client.search(searchParam);我做这个demo时踩过最大的坑是维度不匹配。模型输出的embedding维度是一回事创建集合时指定的维度是一回事插入数据时实际维度又是一回事三者只要有一个没对齐查询就直接失败或返回空结果。所以建议在项目里建一个统一的向量切面封装把模型的输入输出和向量数据库的维度配置锁死避免到处手写参数。面试如果聊到向量数据库还有两个加分项可以提一是向量数据库和传统数据库不是替代关系而是协同关系——元数据用MySQL存向量用Milvus存二是向量检索只能做“近似”查询如果业务要求精确匹配还是回到传统索引的确定性搜索。这两点能体现你对向量数据库的定位理解是清晰的而不只是会调SDK。六、国产数据库适配从MySQL迁过去的一路折腾6.1 驱动与SQL方言差异最容易踩的坑热搜词里“达梦数据库”、“人大金仓数据库”、“国产数据库排名”反复出现说明国产数据库的关注度确实在上涨。我在一个项目里把一套Spring Boot MyBatis的应用从MySQL迁移到达梦数据库一路踩坑踩到怀疑人生。简单总结下来最大的问题不在代码框架而在SQL方言。先看驱动和连接配置的差异。MySQL的驱动是com.mysql.cj.jdbc.Driver达梦是dm.jdbc.driver.DmDriver人大金仓KingbaseES用的驱动是com.kingbase8.DriverGaussDB的是org.postgresql.Driver它是基于PostgreSQL内核的。连接URL也不一样达梦的jdbc:dm://IP:5236/DBNAME金仓是jdbc:kingbase8://IP:54321/DBNAME。这些配置项本身不难改难的是改完之后一堆SQL不兼容。我整理了一个高频差异对照表功能点MySQL写法达梦/金仓写法分页LIMIT 10 OFFSET 20LIMIT 20, 10 或 ROWNUM/RESULT OFFSET自增列AUTO_INCREMENTIDENTITY(1,1) 或序列获取当前时间NOW()SYSDATE / CURRENT_TIMESTAMP字符串拼接CONCAT(a, b)a || b是否为空判断IFNULL(expr, val)NVL(expr, val)批量插入INSERT INTO t VALUES (...), (...), (...)部分版本不支持多值需用循环单条插入这些差异在早期“能用MySQL的开发习惯直接写SQL”的项目里几乎处处踩雷。尤其是分页MyBatis的PageHelper本质上是根据数据库方言来组装分页SQL的如果你只改驱动不配置对应的方言分页查出来要么是空结果要么直接报语法错误。6.2 适配国产数据库的正确姿势经历了那次折腾我总结了三个适配经验分享给同样要接国产数据库的同事。第一在项目里尽早引入数据库方言抽象层。如果项目用的是MyBatis尽量把动态SQL写规范避免在XML里写死某个数据库特有的函数如果是JPA/Hibernate尽量用JPQL和Criteria API来查询不要依赖原生SQL。JPA/Hibernate的方言机制会自动把JPQL翻译成对应数据库的SQL这是降低迁移成本最有效的方式。第二建立专门的兼容性回归用例集。迁移不是改几个配置就完事了SQL语法问题往往要跑到具体业务场景才暴露。最好把项目中所有SQL列一个清单逐个在目标数据库上跑一遍重点关注分页、日期时间、字符串处理、空值判断、批量插入这几类操作。我那次就是因为一个ISNULL判断没有改导致线上查询在数据为空时直接返回了错误结果。第三关注驱动版本和连接池的兼容性。有些国产数据库的驱动发布节奏慢对新的连接池组件支持不完善。比如我们当时用HikariCP连接达梦低版本的驱动偶尔会出现连接泄漏升级驱动后问题才消失。这种问题不好排查但如果你心里有数踩到的时候就不会一头雾水。另外国产数据库适配还经常遇到“集群部署”和“高可用”的概念差异。MySQL的主从切换和达梦的主备切换在配置和运维命令上完全不同这些不是Java代码层面能解决的但作为候选人如果能在面试里聊出“不仅SQL适配架构层面也需要评估容灾切换和性能监控”这个层次会比只停留在驱动和函数替换明显上一个档次。6.3 一次“教科书式”的迁移踩坑实录最后分享一次具体的迁移踩坑过程。当时一个内部管理系统要从MySQL 5.7迁移到某国产数据库系统用的是Spring Boot 2.x MyBatis Plus。本来以为框架比较主流迁移应该顺利结果迁移测试阶段一共报出来二十多个问题其中八成集中在SQL和数据类型映射上。第一个让我印象最深的是自增主键问题。MySQL里用AUTO_INCREMENTMyBatis Plus的IdType.AUTO能直接得到自增主键回填。但到了国产数据库有些版本返回的GeneratedKeys不稳定导致插入后主键没有自动回填后面关联插入就全乱了。解决方法是改用IdType.ASSIGN_ID雪花算法从数据库自增改成应用层生成主键这个问题才彻底绕过去。第二个坑是数据类型映射。MySQL的TINYINT(1)默认被当作Boolean处理但目标数据库里没有完全对应的类型映射导致MyBatis查询结果里把0和1映射成了Integer前端拿到数据后判断逻辑出错。这里没有银弹只能在配置层手动指定typeHandler或者修改表结构把布尔类型的字段改成明确的类型比如CHAR(1)存Y/N。第三个坑是索引命名和长度限制。MySQL里某个索引名到了国产数据库报长度超限索引建不出来。原因是两套数据库对“库名.表名.索引名”的整体长度限制不一致调整索引名长度后就正常了。这段经历让我深刻感受到一件事国产数据库的功能在快速补齐但生态细节和文档完善度相比MySQL还是有差距。所以做技术选型或面试准备时不要以“能不能跑通”为标准要以“线上能不能稳定跑一年”为标准。这句话同样适用于任何Java面试里聊到国产数据库的场景——面试官想听的是你有过真实迁移经验而不是背了两句“支持国产”的口号。