Sequelize执行SELECT查询时随机抛出异常的问题求助

AI 小北

2026-5-1

解决Sequelize查询MySQL时的偶发不稳定异常

嘿，我看你遇到了在AWS Lambda+Serverless环境下，Sequelize查询分类信息的偶发异常问题——10次执行里有3次触发，错误提示里的logic: '%%'其实已经给出了关键线索，这大概率是搜索文本为空时，Sequelize构建查询条件出现了解析错误，再加上Serverless环境的执行复用特性，就导致了这种不稳定的表现。

先分析下触发原因：

你的代码里没有对body.searchText做空值校验，当请求中偶尔缺失这个字段、或者字段值为null/undefined时，调用.toLowerCase()后会得到空字符串，最终让like条件变成%%，而Sequelize对这种极端条件的偶发解析会出错。
AWS Lambda的执行环境是会复用的，如果某次请求的body参数有问题，残留的状态可能会影响后续的请求，加重了异常的偶发性。

接下来是具体的修复方案，一步步来：

1. 给搜索文本加空值兜底，避免无效的like条件

首先在获取searchText的时候，先做非空兜底，确保不会出现undefined或者空字符串的情况：

let searchText = (body.searchText || '').toLowerCase();

这样即使body.searchText不存在，也会被转为空字符串，我们接下来再处理空字符串的场景。

2. 动态构建查询条件，跳过空搜索的无效or条件

当searchText是空字符串时，%searchText%就是%%，这时候其实相当于没有搜索条件，我们可以动态跳过这部分的or条件，避免Sequelize解析异常：

exports.searchProductCategories = (body, username, shopId) => {
  return new Promise((resolve, reject) => {
    // 给所有参数加兜底，避免undefined
    let searchText = (body.searchText || '').toLowerCase();
    let limit = body.limit || 10;
    let offset = body.offset || 0;
    
    // 先构建基础的shopId过滤条件
    const whereConditions = {
      [KEY_SHOP_ID_COLUMN]: shopId // 简化写法，不需要用Sequelize.where
    };

    // 只有当搜索文本不为空时，才添加名称/描述的模糊搜索条件
    if (searchText.trim() !== '') {
      whereConditions[Sequelize.Op.or] = [
        Sequelize.where(Sequelize.fn('lower', Sequelize.col(KEY_NAME_COLUMN)), Sequelize.Op.like, `%${searchText}%`),
        Sequelize.where(Sequelize.fn('lower', Sequelize.col(KEY_DESCRIPTION_COLUMN)), Sequelize.Op.like, `%${searchText}%`)
      ];
    }

    db.product_category.findAndCountAll({
      where: whereConditions,
      order: [[Sequelize.fn('lower', Sequelize.col(KEY_NAME_COLUMN)), "ASC"]],
      offset: offset,
      limit: limit,
      attributes: ['id', 'name', 'description'],
    }).then(result => {
      resolve({
        [KEY_STATUS]: 1,
        [KEY_MESSAGE]: "Categories listed successfully",
        [KEY_DATA]: result.rows,
        [KEY_TOTAL_COUNT]: result.count
      });
    }).catch(error => {
      reject({
        [KEY_STATUS]: 0,
        [KEY_MESSAGE]: "Categories list failed",
        [KEY_ERROR]: error.message
      });
    });
  })
}

3. 排查Lambda入口的请求参数处理

因为异常是偶发的，还要确保Lambda函数的请求参数处理是干净的，避免执行环境复用导致的参数残留。比如如果是API Gateway触发的，每次都要重新解析body：

// 示例Lambda入口函数，确保每次请求都重新解析body
exports.handler = async (event) => {
  // 兜底处理，避免event.body为空导致JSON.parse报错
  const body = JSON.parse(event.body || '{}');
  // 调用你的查询函数
  const result = await searchProductCategories(body, event.requestContext.authorizer?.username, event.pathParameters?.shopId);
  // 返回响应
  return {
    statusCode: 200,
    body: JSON.stringify(result)
  };
};

4. 额外的优化建议

给limit和offset也添加兜底值，避免因为请求中没有传递这两个参数导致Sequelize查询异常。
把原本复杂的Sequelize.where(Sequelize.col(KEY_SHOP_ID_COLUMN), Sequelize.Op.eq, shopId)简化为{ [KEY_SHOP_ID_COLUMN]: shopId }，减少条件构建的复杂度，降低出错概率。

这样调整后，应该就能解决这个偶发的查询异常问题了——核心就是避免让Sequelize处理%%这种无效的like条件，同时做好参数的兜底校验。

内容的提问来源于stack exchange，提问作者KIRAN K J