最近在弄一个人脸识别后台项目核心流程是前端设备采集人脸后提取特征值再通过 Spring Boot 接口记录到数据库里最后供后端做 1:1 验证或者 1:N 检索。这个项目听起来不难但真正落地时才发现数据库怎么建、表怎么设计、特征向量用什么格式存直接决定了后面识别功能的性能和稳定性。我最初的想法很简单把特征值塞进库里不就行了实际操作下来踩了不少坑光是存储格式的选择就反复改了两版。这篇文章我把整个人脸识别项目在 Spring Boot 中建立数据库、管理特征数据的完整过程整理出来从表结构设计到 JPA 映射、特征向量存储、批量导入优化、常见异常排查都有内容偏向可以落地的实操方案给正在做同类项目的朋友一个参考。不管你用的是开源人脸识别库还是厂商提供的 SDK只要后端是 Java Spring Boot 这套表设计和数据管理的思路基本都能复用。1. 先从整体架构看数据库在项目里的位置人脸识别系统的后端逻辑其实可以分成两条链路。一条是注册链路摄像头抓拍人脸人脸检测算法从图片中定位人脸区域特征提取模块把该人脸转换为一个固定维度的浮点数组。这个数组就是人脸特征也叫特征向量或 embedding常见的有 128 维、256 维、512 维。注册链路最后一步就是把这份特征值连同用户的身份信息一起写入数据库。另一条是识别链路设备实时抓拍同样提取特征值然后在数据库里找出与当前特征最相似的历史记录达到设定的相似度阈值就认为是同一个人。所以数据库在整个项目里扮演的角色是双重的。它既要承担身份信息的存储又要承担特征向量的存储还要在识别时作为比对的“底库”。这就带来几个有别于普通业务表的顶层设计问题。第一特征的写入频率不高但读取和比对频率可能很高尤其在门禁考勤场景下设备每过一个人就要做一次全库检索。第二特征数据是不可直接看懂的二进制内容一旦存错格式或者编码损坏整条记录就废了只能重新录入。第三人脸特征通常对应用户的核心隐私数据安全层面需要额外注意。这些约束决定了数据库表不能随便设计也不能简单地把用户表和人脸表混在一起。基于这些诉求大多数项目采用“用户基础信息 人脸特征数据 识别日志”的三表结构模型。用户表只管身份信息人脸表专门存特征与图片关联日志表记录每一次识别事件。三张表分工明确后续做业务扩展、统计报表、特征更新都很方便。如果一开始就图省事把特征字段塞进用户表等一个人有多张人脸或者特征需要版本更新时改造代价会非常大。技术栈方面我的项目选择的是 Spring Boot 2.7 MySQL 8.0 Spring Data JPA HikariCP。JPA 的好处是实体关系映射方便适合业务模型清晰的场景MySQL 则是团队最熟悉、运维成本最低的选择。如果团队的 SQL 功底很强换 MyBatis-Plus 也可以后面几节讲的核心内容依然适用区别主要在数据访问层的写法。2. 数据库表结构三张核心表的设计与演进数据库建库建表是整个项目的起点设计得好后面能省掉无数麻烦。我主导的这个项目前后设计了三版表结构最终定型成三张核心表加若干辅助表。下面把每张表的结构、字段含义、索引设计和演进过程逐一说明。2.1 用户基础信息表 user_info这张表不必多解释就是维护人员的基本资料但它和人脸表的关联关系要提前定好。我的设计如下字段名类型允许为空说明idbigint 自增主键否用户内部主键usernamevarchar(64)否用户名带唯一索引real_namevarchar(64)是真实姓名id_cardvarchar(32)是证件号码用于实名场景phonevarchar(32)是手机号departmentvarchar(128)是部门或分组信息statustinyint default 1否启禁用状态1启用0禁用created_atdatetime否创建时间updated_atdatetime否最后更新时间字段设计需要注意几个点。username 和 id_card 都建议加唯一索引因为业务里经常要根据这两个维度去查用户。status 这个字段看着简单但实际项目中不少开发者会忽略导致人员离职后还能被识别通过这属于安全管理漏洞千万不要省。department 字段为什么不做成独立的部门表这个我在项目中纠结过。如果公司规模大、组织层级深、部门经常调整确实应该单独设计 department 表用户表存 department_id 外键。但对于中小型项目一个字符串字段足够满足按部门筛选的需求了。我最终保留了字符串方案因为人脸识别项目的核心是底库检索组织架构属于次要维度做复杂了反而增加维护成本。2.2 人脸特征表 face_feature这张表是整个数据库设计的关键也是最容易出问题的部分。先想清楚一张人脸图片经过特征提取后得到的是几百个浮点数组成的数组。这些浮点数直接翻译成“人能看懂的数值”没有意义它只是数学上的一个坐标点通过计算不同坐标点之间的距离来判定相似度。所以 face_feature 表需要解决的第一个问题是特征向量用什么格式存储。常见的方案有这么几种我逐一对比过。存储方案实现方式优点缺点适用场景浮点数组字符串用逗号拼接成字符串存入 text直观调试方便占用空间大解析耗时数据量小临时测试Base64 编码将浮点数转二进制再 Base64 编码体积可控存取快不可读需要编解码逻辑中小规模生产BLOB 二进制直接把二进制数据存入 blob 字段存取效率高脱离程序无法解析有统一 SDK 的内部系统JSON 数组以 JSON 数组格式存储可读性好跨语言方便体积大解析慢微服务跨语言场景向量数据库存到专用的向量检索库天然支持相似度检索性能最强引入额外组件运维复杂识别底库达到百万量级我在项目中最终选了 Base64 编码方案。原因很简单MySQL 的 fine 控制、调试时可以把 Base64 解码后人工检查特征维度是否完整Java 侧处理起来也顺手。向量数据库虽然性能好但我们的底库规模也就几十万用 MySQL 加内存比对完全够用没必要引入额外组件增加部署复杂度。这里也建议读者先评估自己的数据量几十万级以内真的不必一上来就上向量库先让 MySQL 跑起来后续再演进也不迟。face_feature 表的最终字段设计如下字段名类型允许为空说明idbigint 自增主键否主键user_idbigint否关联 user_info.idface_keyvarchar(64)否同一用户多张人脸时的别名feature_datalongtext否Base64 编码后的特征向量feature_dimint否特征维度如 512image_urlvarchar(255)是人脸照片地址algorithm_versionvarchar(32)否提取算法版本statustinyint default 1否状态1启用0停用created_atdatetime否创建时间updated_atdatetime否更新时间这个表有几个细节值得展开。一是 user_id 和 face_key 的组合应该加唯一索引确保一个人对同一个别名不会重复注册。人脸算法通常允许为同一个用户录入多张不同角度的照片face_key 就是用来标识“这是这个用户的第几张脸”。我见过有人直接用 user_id 做主键导致一个人只能录入一张人脸这是个硬伤。二是 algorithm_version 字段必须有。不同版本的算法提取出的特征向量计算方式不一样维度也可能不同如果把两个不同算法版本的特征混在一个底库里比对出来的相似度完全不可信。之前我在项目里就遇到识别率突然下降的问题最后排查下来是新注册的人用了新版算法旧底库还是老算法两个版本的空间定义都不一致数据库里根本没有区分导致完全没法用。加了版本号之后比对阶段就只检索同一个算法版本的数据问题立刻解决。三是 status 字段配合 user_info.status 做双重过滤。人员信息被禁用时识别阶段就不该再把人脸数据纳入底库检索这样从数据层面就切断了安全隐患。2.3 识别记录表 recognition_log识别记录表用于记录每一次识别尝试包括成功和失败的方便审计、排查异常和处理纠纷。这张表的字段设计相对直观字段名类型允许为空说明idbigint 自增主键否主键user_idbigint是命中用户 ID未命中的情况为空similarity_scoredouble否相似度分数thresholddouble否本次判断阈值capture_image_urlvarchar(255)是抓拍原图地址device_novarchar(64)是设备编号recognize_timedatetime否识别时间create_timedatetime否记录创建时间record 表上要建一个 recognize_time 的普通索引因为后台最常用的查询就是“某个时间段内某台设备的识别记录”。这里的照片和特征数据不同人脸照片属于敏感隐私生产环境建议做好访问控制和脱敏不要随意开放查询接口。2.4 三张表的关联关系与日常管理从关系上说user_info 一对多 face_featureuser_info 一对多 recognition_log。外键逻辑在 JPA 层用注解维护数据库物理层面通常不加外键约束而是在应用层保证一致性。原因在于识别场景下写入频率高物理外键会影响插入和删除性能而且分库分表后外键会变成障碍。这个取舍在行业里是主流做法。日常管理方面有几个操作频率很高的场景。更换照片或算法版本时需要将旧特征标记为停用并插入新特征而不是物理删除旧数据保护历史记录的可追溯性。人员离职时包括用户信息和特征数据都要做逻辑删除避免识别到底库里已经离职的人。定期清理 recognition_log 中的历史数据例如保留 90 天超出部分归档防止日志表无限膨胀。3. Spring Boot 集成数据库依赖、配置与实体映射表结构定好了接下来就是 Spring Boot 项目里如何把它变成可运行的代码。这一节从依赖引入、配置文件、实体类映射到事务控制依次说明。3.1 项目依赖与数据源配置Spring Boot 项目引入数据库相关依赖我在 pom.xml 中配置的是以下几项dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency依赖引入后在 application.yml 里配置数据源。这里给出我实际使用的配置并解释关键参数含义spring: datasource: url: jdbc:mysql://localhost:3306/face_db?useUnicodetruecharacterEncodingutf-8serverTimezoneAsia/ShanghairewriteBatchedStatementstrueallowMultiQueriestrue username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver hikari: minimum-idle: 5 maximum-pool-size: 20 idle-timeout: 30000 connection-timeout: 30000 jpa: hibernate: ddl-auto: update show-sql: false open-in-view: false先看 JDBC URL 里的参数。useUnicodetrue 和 characterEncodingutf-8 是必须的否则中文姓名存入数据库可能乱码这个坑很多人踩过。serverTimezoneAsia/Shanghai 解决 Java 和 MySQL 服务器时区不一致导致的时间偏移问题。rewriteBatchedStatementstrue 是批处理优化的关键参数后面批量导入特征时会提到。allowMultiQueriestrue 允许一次执行多条 SQL在初始化数据脚本时比较方便。HikariCP 的参数需要根据并发量调整。maximum-pool-size 默认是 10我的识别接口并发峰值不算太高调到 20 足够。最小空闲连接数 5 意味着系统启动后预热五个连接避免第一个请求进来时临时建连接带来延迟。这里有一个容易忽略的信息连接池不是越大越好MySQL 默认最大连接数是 151如果多个服务实例共同连接同一个数据库每个实例的 maximum-pool-size 加起来不能超过这个上限否则数据库会拒绝连接。ddl-auto 我设置的是 update 而不是 create。生产环境很多人喜欢配置为 none由 DBA 手动管理表结构这个更稳妥。但项目早期为了快速迭代我用 update 让 JPA 根据实体类自动同步表结构省去手工写建表脚本的时间。这里提醒一下update 模式只会新增字段不会删除字段也不会修改已有字段类型。如果实体类的字段改名或者调类型需要自己手动去数据库执行 ALTER TABLE否则运行时会报列名不存在的错误。改成 show-sql: false 是必须的。开发阶段开 true 可以看 SQL 方便调试生产环境一定关掉不然日志文件会迅速膨胀而且打印 SQL 也会有性能损耗。3.2 实体类与表结构映射实体类映射我直接给出核心代码。先看 UserInfo 实体Entity Table(name user_info) Data public class UserInfo { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; Column(nullable false, unique true, length 64) private String username; Column(name real_name, length 64) private String realName; Column(name id_card, length 32) private String idCard; private String phone; private String department; Column(nullable false) private Integer status 1; Column(name created_at, nullable false, updatable false) private LocalDateTime createdAt; Column(name updated_at, nullable false) private LocalDateTime updatedAt; OneToMany(mappedBy userInfo, cascade CascadeType.ALL, orphanRemoval true) private ListFaceFeature faceFeatures new ArrayList(); }这里有几个注解细节要说明。Column(name real_name) 是因为 Java 属性名采用驼峰风格而表字段采用下划线风格JPA 的物理命名策略默认会自动完成转换但如果项目里显式指定了列名格式上要统一。nullable false 和 unique true 与表结构一一对应实体类要保持一致否则 ddl-auto 同步出来的表就和设计偏差了。OneToMany 的关系我设置了 CascadeType.ALL 和 orphanRemoval true。这意味着删除用户时关联的人脸特征会自动删除不用手工写删除逻辑。好处是代码简洁坏处是如果删除用户时忘了考虑关联数据容易误删。实际项目中我更推荐只把 CascadeType 用在创建和更新场景删除操作走 Service 层手动处理避免意外级联删除造成事故。我的最终代码里其实是把这个级联删除了的后面会再提到。FaceFeature 实体映射如下Entity Table(name face_feature, uniqueConstraints { UniqueConstraint(columnNames {user_id, face_key}) }) Data public class FaceFeature { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; ManyToOne(fetch FetchType.LAZY) JoinColumn(name user_id, nullable false) private UserInfo userInfo; Column(name face_key, nullable false, length 64) private String faceKey; Column(name feature_data, nullable false, columnDefinition longtext) private String featureData; Column(name feature_dim, nullable false) private Integer featureDim; Column(name image_url, length 255) private String imageUrl; Column(name algorithm_version, nullable false, length 32) private String algorithmVersion; Column(nullable false) private Integer status 1; Column(name created_at, nullable false, updatable false) private LocalDateTime createdAt; Column(name updated_at, nullable false) private LocalDateTime updatedAt; }重点说一个坑。ManyToOne 关联默认的抓取策略是 EAGER也就是查 face_feature 时会自动把 user_info 也查出来看起来很贴心但在批量查询场景下会触发严重的 N1 查询问题。我在后来优化识别底库加载时特意显式指定了 fetch FetchType.LAZY需要用户信息时才主动关联查一次性能差别非常大。如果你的表数据量大还默认用 EAGER接口一次要查几千个人脸它就会给每个 user_id 各发一条 SQL妥妥的生产事故级别问题。另外featureData 字段我用了 columnDefinition longtext是考虑到 512 维浮点数转成 Base64 后大概会有 2700 个字符varchar(255) 是存不下的。这个细节经常有人忽略注册接口报出字段长度超限的错误。看到 Data truncation 提示时先查一下字段类型够不够。3.3 事务边界与识别查询的性能取舍Spring Boot 中使用事务最常见的是 Transactional 注解。但人脸识别项目和普通 CRUD 项目不同识别链路并不总是需要走数据库事务。我这边把事务的使用场景分成了三类。写入类操作比如注册用户和录入人脸整体是一个事务。用户信息表和人脸特征表要同时插入只要有一张表失败就全部回滚避免出现“用户建好了人脸没存进去”的脏数据。这个用 Transactional(rollbackFor Exception.class) 标注在 Service 方法上就行。查询类操作比如按用户名查用户、查用户的人脸列表如果方法内部只做查询可以加 Transactional(readOnly true)。readOnly 提示数据库连接可以走只读路由如果后续接了读写分离这些查询会自动走从库减轻主库压力。但别把所有查询方法都加上事务识别阶段的底库加载耗时长如果方法内没有多个查询要保证原子性完全不需要事务。这里我实际踩过一个坑为识别底库加载方法加 Transactional(readOnly true) 后Hibernate 会打开一个长事务来维持实体状态一致性结果这个事务占用连接的时间过长直接导致连接池被占满其他接口全部超时。排查了很久才定位到是长事务引起的连接池耗尽。之后的结论是底库加载方法一律不加事务直接用 Repository 返回 DTO 或简单实体JPA 的会话在方法返回后就关闭连接及时归还给连接池。这个优化上线后连接池从长期高水位降到了正常水平。4. 特征数据的存取与比对核心环节表结构和实体映射就绪后真正的人脸数据存取与比对逻辑开始登场。这一节我按“特征写入、特征读取、底库检索、批量优化”的顺序逐步说明。4.1 特征向量的编码与写入特征值拿到手后第一步是把它从浮点数组转换成可存储的字符串。我写了一个编解码工具类核心逻辑如下public class FeatureCodec { public static String floatArrayToBase64(float[] features) { ByteBuffer buffer ByteBuffer.allocate(features.length * 4); for (float f : features) { buffer.putFloat(f); } return Base64.getEncoder().encodeToString(buffer.array()); } public static float[] base64ToFloatArray(String base64) { byte[] bytes Base64.getDecoder().decode(base64); FloatBuffer buffer ByteBuffer.wrap(bytes).asFloatBuffer(); float[] features new float[buffer.remaining()]; buffer.get(features); return features; } }这段代码的逻辑不难理解先把每个 float 占 4 字节的二进制数据紧凑排布然后做 Base64 编码。相比直接用逗号拼接字符串Base64 的体积大概能压缩三分之一解析速度也更快。解码时注意用 ByteBuffer.wrap 包一层再通过 asFloatBuffer 读取避免自己一个个字节去拼又慢又容易出错。这里要强调一个编解码的安全事项解码前必须校验 Base64 字符串长度是否符合预期维度。理想情况下512 维特征解码后应该是 2048 个字节也就是 512 乘 4。如果读到长度不符的数据说明存储或者传输过程出了问题直接抛异常比静默处理要好。我见过有的同事解码时不校验结果拿一个残缺数组去比对相似度全部失真。写入数据库的 Service 层代码如下Service RequiredArgsConstructor public class FaceRegisterService { private final UserInfoRepository userInfoRepository; private final FaceFeatureRepository faceFeatureRepository; Transactional(rollbackFor Exception.class) public Long registerFace(FaceRegisterRequest request) { UserInfo user userInfoRepository.findById(request.getUserId()) .orElseThrow(() - new BusinessException(用户不存在)); FaceFeature feature new FaceFeature(); feature.setUserInfo(user); feature.setFaceKey(request.getFaceKey()); feature.setFeatureData(FeatureCodec.floatArrayToBase64(request.getFeatures())); feature.setFeatureDim(request.getFeatures().length); feature.setAlgorithmVersion(request.getAlgorithmVersion()); feature.setImageUrl(request.getImageUrl()); feature.setStatus(1); faceFeatureRepository.save(feature); return feature.getId(); } }核心的流程是查用户、组装实体、保存特征。这里有一个经验之谈featureDim 字段千万别省。虽然我们可以在比对时通过解码 length 自动算出维度但把维度单独存一个字段在做校验和排查问题时一目了然。特别是有多个算法版本并行时看一眼数据库就知道某个人的特征是多少维的不用写代码去解码验证。4.2 特征底库的加载与内存比对底库比对是人脸识别项目最核心的使用场景。实时抓拍的特征值要跟库里所有合法特征做相似度计算取最高分看是否超过阈值。很多开发者第一个想到的写法是根据算法版本查出所有特征然后在内存里逐条解码、计算余弦相似度。这个方案对于十万级底库完全可行。我就是这么做的先用 repository 查询所有启用状态的特征然后依次解码调用相似度计算接口。关键点在于不要在高频的比对接口里每次都查询数据库和逐条解码。更优的做法是服务启动时加载一次底库到本地内存缓存然后定期刷新比如每五分钟从数据库同步一次增量变化。识别接口直接走内存缓存性能能提升一个量级。缓存实现我用的最简单的方式一个 ConcurrentHashMap 就够了Component public class FaceFeatureCache { private final MapString, float[] featureCache new ConcurrentHashMap(); private final MapLong, Long userCache new ConcurrentHashMap(); public void reload(ListFaceFeature allEnabledFeatures) { featureCache.clear(); userCache.clear(); for (FaceFeature feature : allEnabledFeatures) { featureCache.put(feature.getId().toString(), FeatureCodec.base64ToFloatArray(feature.getFeatureData())); userCache.put(feature.getId(), feature.getUserInfo().getId()); } } }加载完成后比对时直接遍历 featureCache 的 value 数组做相似度计算。有人可能会问为什么不用数据库的向量索引或者 SQL 计算相似度MySQL 本身没有高效的向量检索能力。SQL 里的余弦相似度计算要全表扫描加实时解码效率比内存遍历低一个数量级。内存方案的一个额外优势是特征数据被一次加载后不会产生数据库连接的频繁占用。所以在十万级这个量级内存缓存是性价比最高的选择。超过百万级后内存缓存就会显得吃力这时再把数据迁移到专门的向量检索数据库。迁移的判断标准是底库规模超过 100 万或者单条识别响应要求低于 100 毫秒。到这个阶段架构上的改动会比较大但这是量变到质变的正常路径。4.3 批量导入特征时的性能优化人脸识别项目经常会有初始化底库的需求比如把历史照片批量提取特征后一次性导入。如果几百上千条数据逐条 save每一条都开一个事务时间可能长达几分钟甚至更久。这里分享一套实测有效的批次优化组合。首先是 JPA 层面开启批量插入在 application.yml 中追加两个配置spring: jpa: properties: hibernate: jdbc: batch_size: 50 order_inserts: truebatch_size 告诉 Hibernate 攒到 50 条再合并执行插入。order_inserts 的作用是把同类型的插入排序到一起避免 Hibernate 自动帮实体间穿插顺序导致批量效果被破坏。然后是 JDBC URL 上的 rewriteBatchedStatementstrue这一步很关键。没有这个参数Hibernate 虽然发的是批处理语句MySQL 驱动却可能一条一条地执行批量优化形同虚设。参数加上之后MySQL 驱动才会真正把多条 SQL 合并成一条多值插入语句性能提升非常明显。最后在代码层面分批提交事务Transactional public void batchImport(ListFaceFeature features) { for (int i 0; i features.size(); i) { faceFeatureRepository.save(features.get(i)); if (i % 100 99) { faceFeatureRepository.flush(); faceFeatureRepository.clear(); } } }每满 100 条就 flush 一次把缓存中的实体同步到数据库同时 clear 掉一级缓存。如果不做 flushHibernate 的一级缓存会一直堆积数据量大时内存占用会非常高最终可能导致 OutOfMemoryError。我实测下来一万条特征数据在未优化前要七八分钟优化后不到二十秒差距巨大。5. 常见问题与排查实录项目开发过程中数据库层面遇到的问题千奇百怪这里把最有代表性的整理出来方便大家做对照排查。5.1 中文乱码现象是数据库里中文显示为问号或者乱码。按顺序检查三个位置。建库时确认 character set 是 utf8mb4不是 utf8mb3。连接字符串确认带 characterEncodingutf-8。表字段的 collation 确认是 utf8mb4_general_ci 或 utf8mb4_unicode_ci。一个容易忽略的细节是MySQL 8 默认字符集是 utf8mb4但如果你用的是 5.7 版本utf8 实际只支持三个字节存储一些特殊字符会报错。项目建库时直接用 utf8mb4 最省心。5.2 字段长度超限报错信息是 Data truncation: Data too long for column feature_data。原因就是 featureData 列长度不够。如果建表时给了 varchar(255)512 维特征 Base64 后肯定超。解决方法是改成 longtext。这里提醒一下ddl-auto 是 update 时JPA 不会自动帮你把 varchar 改成 longtext必须手动执行 ALTER TABLE。5.3 特征底库无法加载现象是识别接口全部返回失败日志里出现 base64 解码异常。大概率有两种原因。一种是数据库中混入了脏数据某个特征字段被非法修改。另一种是算法版本切换后新代码解码旧数据失败。排查方式是写一个校验脚本遍历底库所有记录对每条 featureData 执行一次解码异常的就标记出来重新录入。我在项目中就是靠这个脚本定位到几条历史脏数据清理后接口恢复正常。5.4 识别底库不更新上线内存缓存后新增的人脸无法立即生效这是正常的因为缓存有刷新周期。如果刷新周期结束后仍然没有生效检查缓存的刷新逻辑是否只查询了 status1 的数据以及 userInfo 的懒加载是否在缓存加载完成后还能正常访问。懒加载这个坑很隐蔽我在 4.2 节提到过加载底库时如果 userInfo 是 LAZY而事务已经关闭访问 userInfo.getId() 会抛出 LazyInitializationException。解决方式是在缓存加载前先做好数据投影或者把 userId 也一并查出来放到缓存里不要等事务结束后再去触发懒加载。5.5 数据库连接池耗尽症状是应用日志不断报 Connection is not available, request timed out所有接口响应变得很慢。常见原因有三个。一是长事务持有连接二是连接池最小值配置过高三是并发高峰超过了 maximum-pool-size。我遇到的情况是长事务持连接导致的解决办法在 3.3 节已经提过查询方法不加事务识别接口走内存缓存。另外可以开启 HikariCP 的泄漏检测把 leak-detection-threshold 设为 60000 毫秒这样连接泄漏时日志里能打印出堆栈信息快速定位问题代码。5.6 多人并发注册时数据冲突现象是两个人脸特征同时写入偶尔出现主键冲突。这个跟 Spring Boot 自身无关是底层 ID 生成策略的问题。我的表用的是数据库自增主键并发写入时 MySQL 自增机制本身是安全的。如果出现冲突检查是否在代码里自己给 id 设了值。另外注意自增主键在事务回滚后会消耗 ID属于正常现象千万别因为 ID 不连续就去改动生成策略。6. 扩展话题从 MySQL 走向向量检索的演进路径很多读者可能觉得讲完上面这些就够了但我还是想留一点篇幅聊聊后续演进。人脸识别底库规模是逐步增长的当业务从几千人扩展到百万级MySQL 加内存缓存方案的局限会原形毕露内存占用过大单机无法支撑全量加载耗时太长刷新周期内识别结果不增反降已有的特征索引无法做类似“最近邻居”的检索只能全遍历。到这个阶段把特征数据迁移到专用的向量检索数据库是更合适的路径。迁移时不需要推翻原有数据结构face_feature 表仍然可以作为权威数据源向量库只承担检索加速的角色。业务写入时先更新 MySQL再异步同步到向量库查询时直接走向量库MySQL 平时不参与比对。这个架构的优点是保留关系数据库的强一致性和审计能力同时获得向量检索的高性能。如果你现在正准备选型我建议先抓住一个问题底库未来半年到一年能达到什么量级。如果不超过 50 万用本文的 MySQL 方案是效率和成本的最优解如果明确要奔着百万级去从第一天就考虑引入向量库省得后面迁移数据时还得设计双写逻辑。人脸识别项目的数据库管理说到底就是“把算法的数学表达落到工程存储”的过程。表结构设计、字段选型、事务边界、缓存策略每一个决策都依赖对业务规模和技术成本的清晰判断。我个人做完这个项目最大的感受是不要盲目追新工具十万级以内把 MySQL 用透已经能解决绝大部分问题也不要忽视版本和状态管理一个算法版本字段就能让整个底库分析有据可依。如果你正在搭类似系统建议先从三张表出发把用户、特征、日志先拆出来用 Base64 存特征配合内存缓存做比对这套组合足够支撑中小规模的人脸识别应用。等底库真的大到内存吃不消的那一天再往向量检索方向演进这样的路径最稳也最省人力。