MySQL自动截断引发的死循环

一个容易被忽视的类型陷阱

最近在处理一个大数据量业务时，我遇到了一个有趣的MySQL问题。业务需求很简单：需要遍历业务表中的所有数据。由于数据量较大，我决定使用分页查询的方式，并为此编写了一个存储过程。

最初的实现方案

CREATE PROCEDURE page_query(
    id INT
)
BEGIN
    SELECT * FROM t WHERE id > id ORDER BY id LIMIT 1000;
END;

然后在Java代码中循环调用这个过程：

int nextId = 0;
do {
    List<Data> ts = query(nextId);
    if (ts.size() == 0) {
        break;
    }
    nextId = getMaxId(ts);  // 获取结果集中最大的ID
} while (nextId > 0);

问题的出现

这个逻辑看起来完美无缺，但在实际运行中却出现了死循环！经过仔细排查，我发现问题出在类型不匹配上：

1. 我的业务表t中的id字段是BIGINT类型
2. 存储过程参数id却被定义为了INT类型
3. 当ID增长超过INT的最大值（2^31-1）时，MySQL没有报错，而是自动进行了截断

问题分析

MySQL的这种行为被称为"隐式类型转换"。在严格SQL模式未启用时，MySQL会尝试自动转换数据类型，而不是抛出错误。具体到本例：

• 当传入的BIGINT值超过INT范围时，MySQL会截断高位，只保留低32位
• 这导致查询条件WHERE id > [截断后的值]始终成立
• 结果就是程序陷入了无限循环

解决方案

1. 最直接的修复：修改存储过程参数类型为BIGINT

CREATE PROCEDURE page_query(
    id BIGINT  -- 修改为与表字段一致的类型
)
BEGIN
    SELECT * FROM t WHERE id > id ORDER BY id LIMIT 0,1000;
END;

2. 更安全的做法：启用严格SQL模式

SET sql_mode = 'STRICT_TRANS_TABLES';

启用严格模式后，MySQL会在类型不匹配时抛出错误，而不是静默截断。

经验教训

1. 类型一致性：存储过程参数类型应与表字段类型严格匹配
2. 防御性编程：对于关键业务逻辑，启用严格SQL模式
3. 边界测试：大数据量场景下，务必测试ID接近类型上限时的情况
4. 监控机制：长时间运行的批处理任务应有超时机制

感叹一句，细节是最容易被忽视的，很多问题的出现往往是因为细节的错误。