Rust+mysql_async插入交易时block_index非空错误排查与解决

以下是排查方向和对应的解决方法：

1. 结构体字段与数据库列名映射不匹配 #

检查你的Transaction结构体中block_index字段的命名规则：

• mysql_async的Insertable/Queryable派生宏默认采用蛇形命名匹配，如果结构体用驼峰命名（比如blockIndex），会自动映射到block_index以外的列名，导致实际插入时该字段未被正确绑定。
• 解决：要么将结构体字段改为蛇形block_index，要么在字段上添加注解指定列名：

  #[derive(Insertable)]
  #[mysql_async(table_name = "transactions")]
  struct NewTransaction {
      // 其他字段
      #[mysql_async(name = "block_index")]
      block_index: Option<u64>,
  }
  

2. Insertable派生宏遗漏字段 #

如果使用#[derive(Insertable)]，确认没有误加#[mysql_async(skip)]注解在block_index字段上，这会导致该字段被排除在插入逻辑外，最终传入NULL。

• 解决：检查结构体的派生配置，确保block_index字段未被标记为跳过。

3. 手动拼接SQL时的字段/参数错误 #

如果是手动编写INSERT语句，排查以下两点：

• 是否在INSERT的字段列表中遗漏了block_index？
• 参数绑定的数量、顺序是否与字段列表对应？比如占位符数量不足，导致block_index的位置未传入值。
• 解决：开启mysql_async的SQL日志，查看实际执行的SQL语句。可以通过连接配置开启：

  use mysql_async::OptsBuilder;
  
  let opts = OptsBuilder::new()
      .with_user("user")
      .with_password("pass")
      .with_db_name("db")
      .with_log_level(mysql_async::LogLevel::Trace);
  

  对比日志中的SQL和你手动执行的正常SQL，找出差异。

4. 参数绑定顺序/类型错误 #

如果手动绑定参数，确认block_index的参数值没有被错误覆盖，或者顺序错位。建议使用命名参数绑定，避免顺序问题：

pool.exec_drop(
    r"INSERT INTO transactions (block_index, hash, amount) VALUES (:block_index, :hash, :amount)",
    params! {
        "block_index" => Some(1),
        "hash" => "tx_hash_xxx",
        "amount" => 100
    },
).await?;

5. 实例值被意外覆盖 #

在执行插入前，临时添加debug打印，确认Transaction实例的block_index值确实是Some(1)：

let new_tx = NewTransaction {
    block_index: Some(1),
    // 其他字段赋值
};
println!("Inserting transaction: {:?}", new_tx);
new_tx.insert(pool).await?;

排查是否有代码逻辑在构造实例后，将block_index意外改为None。

内容的提问来源于stack exchange，提问作者CodingApperentice