Flask应用使用Google Cloud SQL时任务API返回结果不一致问题

• 查询对象未显式执行的设计缺陷：当前代码中Tasks.query.order_by(Tasks.time_create.desc())仅生成SQLAlchemy的查询构造器，并未真正触发SQL执行拉取结果。直接将该构造器传给Marshmallow序列化时，序列化逻辑会从关联的数据库会话中动态拉取数据，受会话缓存、连接状态影响，每次调用拿到的结果快照不固定，就会出现同个接口返回结果不一致的问题。
• 云数据库场景下的会话缓存机制不匹配：之前本地用SQLite时，文件型数据库没有连接层的结果缓存，查询构造器首次被序列化时就会直接读取全量文件数据，行为稳定。当切换到Google Cloud上的MySQL存储时，数据库连接会在连接池中复用，会话默认的身份映射缓存没有在每次请求后清空，加上MySQL自身的短期查询缓存，就会放大结果不一致的问题——哪怕本地连Cloud SQL MySQL测试，只要复用同个未清理的连接，同样会触发该问题。
• 字段类型设计的隐性排序问题：当前time_create被定义为字符串类型，排序逻辑基于字符串的字典序对比，没有固定的数值排序基准，在结果集不稳定的情况下，排序结果的随机性会进一步放大接口返回的差异。

• 显式触发查询执行：在查询语句末尾加.all()，也就是把查询行修改为：

  Task = Tasks.query.order_by(Tasks.time_create.desc()).all()
  

  这行修改会强制立即执行SQL查询，将拿到的全量结果固化为Python列表后再传给序列化器，序列化过程基于固定的静态数据处理，不会再动态拉取会话中的不稳定缓存数据。
• 配置连接池与会话回收逻辑：在Flask应用的配置项中添加连接回收参数，避免长期复用带缓存的数据库连接：

  # 连接超过30分钟自动回收，匹配MySQL默认的长连接超时规则
  app.config["SQLALCHEMY_POOL_RECYCLE"] = 1800
  # 关闭不必要的SQLAlchemy事件追踪开销
  app.config["SQLALCHEMY_TRACK_MODIFICATIONS"] = False
  

  同时注册请求结束的钩子，在每次响应返回后清理当前请求的会话：

  @app.teardown_appcontext
  def shutdown_session(exception=None):
      db.session.remove()
  

  从机制上避免跨请求残留的会话缓存影响查询结果。
• 优化字段类型匹配业务逻辑：将time_create字段从字符串类型调整为标准日期时间类型，让排序基于真实的时间数值对比，从根源上消除字符串排序带来的结果不确定性：

  time_create = db.Column(db.DateTime)
  

• 增加序列化入参校验：在调用序列化器前，先判断待传入的对象是列表类型的固定结果，避免后续代码重构时再次出现把查询构造器直接传给序列化器的问题。

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