从MySQL读取is_primary字段始终返回'N'，生产环境异常但非生产环境正常

遇到这种环境不一致的问题确实头疼，我来帮你梳理几个高概率的排查方向，一步步缩小问题范围：

1. 先确认生产数据库的实际数据 #

直接登录生产数据库，执行查询语句验证目标记录的真实值：

SELECT device_uid, is_primary 
FROM tbl_user_history_mobile_devices 
WHERE fk_user_id = <你的测试用户ID>;

• 重点确认返回的is_primary是否确实为Y，有时候可能是数据本身的问题（比如生产环境的记录从未被更新为Y），或者存在分库分表/多租户配置导致你查错了库表。

2. 验证JPA字段映射的正确性 #

• 再次核对实体类与数据库字段的映射：实体类中@Column(name = "is_primary")对应数据库的is_primary字段，确认生产库的字段名、类型（enum('Y','N')）完全与非生产一致，没有拼写错误（比如是否误写为isPrimary）。
• 检查实体类的部署版本：确认生产环境运行的实体类代码与你本地一致，没有残留旧版本（比如之前用Boolean类型字段的代码，导致映射异常）。

3. 排查JPA/Hibernate缓存问题 #

生产环境可能开启了Hibernate二级缓存，导致读取到过期的缓存数据：

• 可以临时关闭二级缓存（修改application-prod.yml等配置文件），或者手动清除缓存后重新测试，看是否能读取到正确的Y值。
• 对比非生产环境的缓存配置，确认生产环境是否额外开启了非生产没有的缓存策略。

4. 检查JDBC驱动与数据库交互的差异 #

• 对比生产与非生产的JDBC驱动版本：不同版本的MySQL JDBC驱动对enum类型的映射可能存在差异，导致读取enum值时出现异常。尝试将生产环境的JDBC驱动版本与非生产统一。
• 用原生JDBC测试读取：在生产环境编写一个简单的测试程序，跳过JPA直接用JDBC查询该字段，看返回值是否正确。如果原生JDBC能读到Y，则问题出在JPA层面；如果原生JDBC也读N，则聚焦数据库本身的问题。

5. 核对数据库字符集与排序规则 #

非生产环境的is_primary字段带有COLLATE utf8mb3_unicode_ci，而生产环境未指定。虽然概率较低，但可以尝试将生产环境的字段排序规则修改为与非生产一致，避免因字符集差异导致的读取异常：

ALTER TABLE tbl_user_history_mobile_devices MODIFY COLUMN is_primary enum('Y','N') COLLATE utf8mb3_unicode_ci NOT NULL DEFAULT 'N';

6. 确认日志打印的变量正确性 #

再次核对生产环境部署的代码中，日志打印的变量是否正确：

logger.info(String.format("Device from DB - deviceId: %s, isPrimary: %s", 
    currentRecord.getDeviceUid(), 
    currentRecord.getDeviceIsPrimary()));

确保第二个参数确实是currentRecord.getDeviceIsPrimary()，而非其他字段（比如误写为currentRecord.getDeviceUid()），同时确认getDeviceIsPrimary()方法返回的是数据库字段值，而非硬编码的默认值。

先从最直接的数据库数据检查开始，逐步缩小范围，应该能快速定位到问题所在。

内容来源于stack exchange