LTM负载均衡器在应用等待大型SQL查询响应时断连的解决方案咨询

你提出的事务ID查询思路的可行性分析 #

你的想法核心是异步查询，但直接绑定事务ID（比如JWT）走不通：

• MSSQL的事务ID是会话级标识，一旦客户端断开连接，事务会立刻回滚，根本没法保留查询状态。JWT是身份验证令牌，和数据库查询任务没有天然关联，没法用来追踪未完成的查询。
• MSSQL本身不会帮你存储“查询任务ID”，要实现这种追踪必须在应用层做任务管理，但不一定非要用你想避开的“存结果到新表”方案——可以换轻量的存储方式。

优化后的异步查询方案（规避全量存表） #

如果不想把查询结果写到新表，推荐这么做：

• 用Celery这类异步任务框架把大型SQL查询包装成后台任务。用户发起请求时，立即生成一个UUID作为任务ID返回，直接断开连接，不用等查询完成。
• 查询执行时，不用把全量结果存数据库，而是分批写到Redis里（比如用任务ID作为Key，把结果分片存储）。这样既避免了写表开销，又能通过任务ID快速获取结果。
• 前端可以用轮询或者WebSocket来查询任务ID的状态，一旦任务完成，就从Redis拉取分片结果拼接成完整数据。

分页机制的区别 #

分页和你说的流程完全不是一回事：

• 分页是同步请求，每次只拉取固定行数的数据（比如MSSQL里用OFFSET/FETCH语法），单次请求耗时短，能避开LB超时问题。
• 但如果你的大型查询是复杂聚合或关联统计，没法拆分成分页查询，那分页就不适用，还是得用异步方案。

Django+MSSQL的具体实现建议 #

• 异步任务：用django-celery集成Celery，任务状态可以存在Celery自带的TaskResult表（不用自己新建），这个表只存任务ID、状态和Redis键，不存完整查询结果，符合你避开存新表的要求。
• MSSQL端优化：给查询涉及的字段加合适的索引；如果业务允许脏读，用WITH (NOLOCK)减少锁等待；或者把复杂查询拆成多个小查询，在Django里做结果聚合，降低单次查询的耗时。
• 请求拆分：把原来的长请求拆成“触发查询”和“获取结果”两个短请求，确保每个请求的响应时间都在LB的超时范围内，从根源上避免断开连接。

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