Python MySQL Connector插入无报错但查询表返回空的问题排查

• 最直接的根因：未执行数据库事务提交。Python版MySQL Connector默认关闭自动提交（autocommit=False），所有写操作（INSERT/UPDATE/DELETE）只会暂存在当前连接的事务上下文里，没有显式执行COMMIT指令的话，改动根本不会持久化到磁盘的物理表中。你用独立的数据库客户端执行SELECT查询时，按照MySQL默认的REPEATABLE READ事务隔离规则，是看不到其他连接未提交的事务改动的，因此查询结果永远为空——整个流程不会抛出任何报错，很容易让人误以为写入流程已经正常完成。
• 字符串拼接SQL的写法存在隐性缺陷。目前代码是直接把用户、消息内容拼进SQL语句，一方面存在SQL注入风险，另一方面如果用户发送的邮件内容包含单引号、特殊转义字符，会直接触发语法错误；同时之前的拼接逻辑把SQL语句的分号、硬编码值嵌在字符串片段里，容错性极差，你之前修复的语法错误本质就是这类拼接逻辑的疏漏。
• 全局复用单数据库连接的设计有长期运行隐患。MySQL 5.7默认的服务端空闲断连超时（wait_timeout）为8小时，长时间运行后服务端会主动断开空闲连接，后续执行写操作时会直接抛断连错误，目前测试阶段因为运行时间短没有暴露这个问题。
• 表结构主键设计存在潜在冲突。当前表把mail_submitter_id设为主键，意味着同一个用户只能存一条modmail记录，后续测试时如果同一用户重复发送带(MAIL)标识的私信，会触发主键唯一约束报错——目前没报这个错，本质就是之前的INSERT根本没持久化，主键约束没有真正生效。

• 每次数据库写操作完成后，显式调用connection.commit()提交事务，将改动持久化；如果写操作执行出错，必须调用connection.rollback()回滚未完成的事务，避免数据库会话状态卡死。
• 替换字符串拼接的SQL写法，改用驱动支持的参数化查询，由驱动自动处理特殊字符转义，从根源上避免SQL注入和语法错误问题，参考实现代码：

  insert_statement = """
  INSERT INTO modmails_table 
  (mail_submitter_username, mail_submitter_discriminator, mail_submitter_id, mail_message, mail_report_resolved)
  VALUES (%s, %s, %s, %s, %s)
  """
  # 将参数作为元组传入execute方法，不要手动拼接SQL字符串
  cursor.execute(insert_statement, (
      author.display_name,
      author.discriminator,
      author.id,
      message.content,
      0
  ))
  # 显式提交事务完成写入
  connection.commit()
  

• 补充异常捕获逻辑，在捕获到数据库连接断开、查询报错时，自动重连数据库并重试操作，避免机器人长时间运行后数据库功能完全失效。
• 调整表结构的主键设计：如果需要保留同一用户的多封modmail历史记录，可以把原来的mail_submitter_id主键替换为自增的mail_id字段作为主键；如果只需要保留用户最新的未处理modmail，可以在INSERT语句后追加ON DUPLICATE KEY UPDATE逻辑，同一用户发新邮件时自动覆盖旧的未处理记录。

你可以在机器人进程持有的数据库连接上直接执行SELECT * FROM modmails_table;查询，就能看到之前所有INSERT暂存在事务里的临时数据——这部分数据只有在执行COMMIT提交后，才会被所有数据库客户端正常查询到。

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