Flask与MySQL本地正常远程报错(pymysql.err.InternalError)求助

从你给出的错误信息和服务器配置来看，核心问题是传入了无效的伊朗历日期1399-02-30，而本地与主服务器的MySQL对无效日期的处理策略不同，才导致本地运行正常但主服务器报错。下面是具体的分析和解决方案：

错误原因拆解 #

1. 无效的伊朗历日期：1399年对应公历2020-2021年，是伊朗历的平年，Esfand月也就是伊朗历第二个月只有29天，所以1399-02-30是完全不合法的日期。
2. MySQL版本与sql_mode差异：
   • 你的本地MySQL 5.7默认可能未开启严格模式，比如缺少STRICT_TRANS_TABLES、NO_ZERO_DATE这类sql_mode参数，会自动把无效日期转成合法值，比如自动转为1399-03-01，不会抛出错误。
   • 主服务器的MySQL 8.0默认启用了严格模式，遇到无效日期会直接抛出InternalError (1525)错误，拒绝执行SQL语句。
3. 时区与字符集的潜在影响：虽然时区本地是Iran Daylight Time vs 主服务器是Asia/Tehran和字符集本地是cp1252 vs 主服务器是utf8mb4的差异可能影响日期解析一致性，但本次错误的直接触发点还是无效日期本身。

分步解决方案 #

1. 修复应用层的无效日期生成逻辑 #

这是最根本的解决办法，从源头避免生成无效日期：

• 使用专门的伊朗历日期处理库，比如Python的jdatetime，来生成、解析和验证日期，不要手动拼接日期字符串。示例代码：

  import jdatetime
  # 验证日期是否合法
  try:
      valid_date = jdatetime.date(1399, 2, 30)
  except ValueError:
      print("无效的伊朗历日期！")
  

• 检查代码中生成s_time和e_time的逻辑，确保只生成符合伊朗历规则的合法日期。

2. 统一MySQL的sql_mode配置临时 workaround #

如果暂时没法修改应用代码，可以调整主服务器的MySQL配置，让它和本地一样采用宽松模式不推荐长期使用，严格模式能避免脏数据：

• 登录主服务器的MySQL，查看当前sql_mode：

  SELECT @@sql_mode;
  

• 修改MySQL配置文件Debian系统通常是/etc/mysql/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf，添加或修改sql_mode为和本地一致的值，例如：

  [mysqld]
  sql_mode = "NO_ENGINE_SUBSTITUTION"
  

• 重启MySQL服务生效：

  sudo systemctl restart mysql
  

3. 统一时区与字符集配置 #

为了避免后续出现其他日期或字符相关问题：

• 确保主服务器MySQL的时区配置和本地一致，或者在应用代码中明确指定时区，比如使用SQLAlchemy时，在连接字符串中添加?timezone=Asia/Tehran，并设置timezone=True。
• 将数据库字符集统一为utf8mb4主服务器已使用该字符集，同时在应用的数据库连接中指定字符集，比如SQLAlchemy连接字符串添加?charset=utf8mb4，避免字符编码转换错误。

额外建议 #

• 永远不要依赖MySQL的宽松模式来“修复”无效数据，这会导致数据不一致且难以排查问题，应用层的日期验证才是可靠的方案。
• 所有涉及伊朗历日期的操作，都使用成熟的日期库处理，避免手动计算月份天数、闰年等复杂逻辑。

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