一. 问题背景与现象
项目技术栈采用MyBatis+通用Mapper自动生成工具（非MyBatis-Plus），核心功能依赖一张系统配置表sys_config（表结构含id、type、config_key、config_value字段）。某次迭代中，业务流程执行到“查询配置表所有数据”步骤时出现异常：数据库中明确存在1条有效数据，但调用Mapper方法SysConfigMapper.selectAll()后始终返回空集合。

此问题排查存在额外限制：项目本地环境因依赖第三方服务无法启动，所有调试操作必须在开发环境服务器上进行，且业务流程链路较长（涉及5个以上服务调用），增加了问题定位难度。

二. 初期排查：陷入弯路
2.1 初步排查方向
首先在业务代码关键节点添加日志（如调用selectAll()前打印“开始查询配置表”，调用后打印“查询结果数量：0”），确认问题确实出在该Mapper方法调用环节，而非后续数据处理。由于业务流程长，团队初步怀疑：是否存在“流程执行中删除配置数据，执行后重新插入”的隐藏逻辑？比如某上游服务在事务中临时清理数据，导致查询时数据暂不可见。

2.2 触发器验证方案
为验证数据是否被动态修改，在开发环境sys_config表上创建触发器，监控DELETE和INSERT操作：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
-- 监控删除操作的触发器
CREATE TRIGGER trg_sys_config_delete 
AFTER DELETE ON sys_config
FOR EACH ROW
INSERT INTO sys_config_oper_log (oper_type, oper_time, data_id)
VALUES ('DELETE', NOW(), OLD.id);

-- 监控插入操作的触发器
CREATE TRIGGER trg_sys_config_insert 
AFTER INSERT ON sys_config
FOR EACH ROW
INSERT INTO sys_config_oper_log (oper_type, oper_time, data_id)
VALUES ('INSERT', NOW(), NEW.id);

重新执行业务流程后查询sys_config_oper_log，未发现任何DELETE或INSERT记录，排除了“数据动态变更”的可能性，排查陷入僵局。

三. 关键突破：开启MyBatis Debug日志
意识到“怀疑业务逻辑”的思路走偏后，决定回归框架本身——MyBatis查询空值的核心原因往往是“实际执行的SQL与预期不符”，因此需要打印真实执行的SQL语句。

3.1 修改logback配置
在开发环境服务器的logback-spring.xml中，将MyBatis核心类的日志级别调整为DEBUG，确保输出SQL执行细节：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
<logger name="org.mybatis.spring.SqlSessionTemplate" level="DEBUG" additivity="false">
    <appender-ref ref="CONSOLE"/>
    <appender-ref ref="FILE_LOG"/>
</logger>
<!-- 打印Mapper接口调用日志 -->
<logger name="com.example.project.mapper.SysConfigMapper" level="DEBUG" additivity="false">
    <appender-ref ref="CONSOLE"/>
    <appender-ref ref="FILE_LOG"/>
</logger>

3.2 分析日志内容
重新执行流程后，查看日志文件，发现selectAll()对应的实际SQL如下：

ounter(lineounter(lineounter(line
DEBUG [main] com.example.project.mapper.SysConfigMapper.selectAll:159 - ==>  Preparing: SELECT id, type, config_key, config_value FROM sys_config WHERE type = 1 
DEBUG [main] com.example.project.mapper.SysConfigMapper.selectAll:159 - ==> Parameters: 
DEBUG [main] com.example.project.mapper.SysConfigMapper.selectAll:159 - <==      Total: 0

日志明确显示：SQL中被硬编码添加了WHERE type = 1条件，而数据库中现存数据的type值为2，导致查询结果为空。

四. 问题根源：被篡改的自动生成Mapper.xml
打开SysConfigMapper.xml文件（路径：src/main/resources/mapper/SysConfigMapper.xml），查看selectAll节点的SQL配置：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
<!-- 问题代码：自动生成后被手动添加了WHERE条件 -->
<select id="selectAll" resultMap="BaseResultMap">
    select 
        id, type, config_key, config_value 
    from 
        sys_config 
    where 
        type = 1  <!-- 多余的硬编码条件 -->
</select>

正常情况下，自动生成工具生成的selectAll方法应无额外条件，代码如下：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
<!-- 正确代码：自动生成的默认配置 -->
<select id="selectAll" resultMap="BaseResultMap">
    select 
        id, type, config_key, config_value 
    from 
        sys_config 
</select>

经沟通确认，此前维护人员为临时满足某需求，直接修改了自动生成的Mapper.xml文件，且未在文档中记录，导致后续迭代中该硬编码条件成为“隐藏坑”。

五. 解决与反思
5.1 问题解决
删除Mapper.xml中selectAll节点的WHERE type = 1条件，重新部署开发环境后，调用SysConfigMapper.selectAll()成功查询到数据库中的1条数据，问题解决。

5.2 排查反思
此次问题排查浪费了大量时间，核心原因在于两个“认知偏差”：
过度信任“自动生成组件”：默认认为“自动生成的Mapper文件不会被手动修改”，初期排查完全跳过了对Mapper.xml的检查，导致方向走偏；

优先怀疑业务逻辑而非框架配置：面对查询空值，先陷入“业务删插数据”的复杂假设，却忽略了“SQL语句与预期不符”这一最直接的可能性。

由此总结出两点排查建议：
遇到ORM框架查询异常时，优先打印实际执行SQL（如MyBatis开启DEBUG日志、JPA开启show-sql），这是定位问题最高效的手段；
对“自动生成的代码”保持审慎：即使是工具生成的文件，也可能存在人工修改，排查时需将其纳入检查范围，避免因“想当然”遗漏关键细节。