Django对接SQL Server拉取10万条记录的性能优化方案

绝对不要每次用户请求时实时拉取SQL Server全量10万条记录——跨库网络传输、数据序列化反序列化的开销极高，不仅会让仪表盘首屏加载延迟达到数秒甚至十几秒，高并发场景下还很容易打满SQL Server的连接池，拖垮源库业务。

• 定时同步+缓存预处理（90%以上仪表盘场景首选）
  绝大多数业务仪表盘对数据实时性的容忍度在5分钟到1小时不等，完全不需要每次请求查源库。直接配Celery异步定时任务，按照业务可接受的延迟周期同步数据：第一次任务全量拉取10万条记录，之后每次只拉取自上次同步时间之后有变动的增量数据（要求SQL Server源表带update_time时间戳字段），同步完成后直接把仪表盘需要用到的原始数据、提前算好的聚合统计结果序列化后存入Redis缓存。
  用户访问仪表盘接口时直接从Redis读预处理好的数据，不需要碰跨库连接，接口响应速度可以稳定在10ms级别。注意别用Django本地内存做缓存，多实例部署时会出现数据不一致的问题。
• ETL增量同步到本地PostgreSQL
  如果仪表盘需要支持灵活筛选、多维度下钻等复杂查询，缓存存固定结果满足不了需求，就在PostgreSQL主库中建和SQL Server源表对应的映射表，还是用异步定时任务做增量同步，把跨库查询的开销完全转移到异步链路。所有仪表盘查询直接走本地PG，和正常读Django模型的性能没有区别。
  可以额外建几张聚合结果表，同步数据的时候就提前把常用维度的统计值算好存进去，连查询时的group by计算开销都能省掉，10万条规模的数据集就算做全表扫描，本地PG的响应时间也只有几毫秒。
• 强实时场景的兜底优化
  如果业务要求数据必须做到秒级以下的实时性，也绝对不要拉全量10万条原始记录到应用层计算：
  1. 跨库查询时只SELECT仪表盘实际用到的字段，禁止SELECT *，至少能砍掉一半以上的传输数据量
  2. 所有聚合、筛选逻辑尽量下推到SQL Server侧执行，只把最终几十到几百条的统计结果传回Django
  3. 给SQL Server的查询条件、排序字段建好对应索引，避免源库做全表扫描

不要在用户请求的同步链路里做任何跨库查询操作，一旦出现网络波动、源库响应慢的问题，会直接导致整个仪表盘接口超时，而且故障排查链路很长。所有跨库拉取数据的操作全部放到异步任务里执行，用户请求链路只访问本地缓存或者本地PostgreSQL。

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