为何SQLAlchemy会话首次查询远慢于后续调用？

核心结论 #

是的，数据库缓存是导致首次调用速度显著慢于后续的主要原因，同时还有应用侧的一些初始化开销叠加影响。

具体原因拆解 #

1. SQL Server 数据库层面的缓存机制

• 查询计划缓存（Query Plan Cache）：首次执行SELECT * FROM Orders WHERE order_date <= ?时，SQL Server需要完成SQL解析、语法检查、生成最优执行计划（比如判断是否使用order_date上的索引、选择扫描/查找方式），这个编译过程会消耗额外时间。后续执行时，数据库会直接复用已缓存的执行计划，跳过编译步骤。
• 数据页缓存（Buffer Pool）：首次查询需要从磁盘读取符合条件的Orders表数据页到内存缓冲区，磁盘IO的延迟很高；后续查询直接从内存缓冲区读取数据，完全避免了磁盘IO开销，这是速度差异最明显的来源。

2. 应用侧的初始化开销

• SQLAlchemy 连接池初始化：第一次创建DBContextManager会话时，可能涉及到与SQL Server的TCP连接建立、认证等操作；后续循环中的会话大概率复用了连接池中的现有连接，省去了连接建立的开销。
• pandas 类型映射初始化：首次调用pd.read_sql时，需要初始化数据库类型到Python类型的映射逻辑（对应你代码里的column_types），后续调用会复用这些已初始化的映射规则，减少了初始化时间。

结合你的数据验证 #

从你给出的执行时间数据来看：

[1.3190752999999988,
 0.2215163999999999,
 0.25437130000000036,
 0.19252480000000013,
 0.1886178,
 0.22220109999999996,
 0.21765510000000007,
 0.2034394999999999,
 0.19447940000000002,
 0.20421450000000013]

首次执行耗时是后续的6倍左右，完全符合"首次执行包含磁盘IO、计划编译、连接初始化等冷启动开销，后续复用缓存进入热态"的特征。

验证方法（可选） #

• 提前在SQL Server客户端（比如SSMS）执行一次相同的查询，再运行你的测试代码，此时首次执行时间会和后续接近，证明缓存的作用。
• 通过SQL Server系统视图确认缓存状态：
  • 查询sys.dm_exec_cached_plans查看是否存在该SQL的缓存执行计划；
  • 查询sys.dm_os_buffer_descriptors查看Orders表的数据页是否已加载到缓冲池。

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