TiDB 游标查询中的临时文件清理问题分析

问题背景

在 TiDB 数据库系统中，当执行大结果集查询时，如果结果数据量超过了内存配额限制，系统会将部分数据溢出到临时文件中。这种机制称为"spilling"，它允许处理超出内存限制的大型查询。然而，在某些特定场景下，特别是使用游标(Cursor)查询时，当查询因超出临时存储配额而失败时，这些临时文件可能无法被正确清理。

问题复现与现象

通过以下步骤可以复现该问题：

1. 创建一个包含大量数据的表
2. 设置较小的内存配额和临时存储配额
3. 使用 JDBC 驱动以游标方式执行查询
4. 当查询因超出配额失败时，检查临时文件目录

正常情况下，查询失败后系统应该清理所有临时文件。但实际观察到的现象是，部分临时文件仍然保留在磁盘上，没有被删除。

技术原理分析

TiDB 在处理游标查询时，会使用一个名为rowContainer的结构来管理结果集数据。当内存不足时，rowContainer会将数据溢出到磁盘临时文件中。问题出现在错误处理路径上：

1. 当rowContainer.Add()方法因超出配额而panic时
2. 系统没有进入正常的清理流程
3. 导致临时文件句柄未被释放，文件未被删除

相比之下，正常流程中当所有数据被成功获取后，rowContainer会在游标关闭时被正确清理。

影响范围

该问题会影响以下使用场景：

• 使用游标方式获取大量数据的应用
• 查询结果集大小接近或超过内存/临时存储配额限制
• 使用JDBC等客户端驱动进行查询

长期未清理的临时文件可能导致磁盘空间被逐渐占用，最终影响系统正常运行。

解决方案

修复该问题的核心思路是确保在所有错误路径上都正确清理临时资源。具体措施包括：

1. 在rowContainer操作中添加错误处理逻辑
2. 确保panic被捕获并转换为适当的错误返回
3. 在错误处理路径中显式调用清理方法
4. 添加资源泄漏检测机制

最佳实践建议

对于TiDB用户，在使用游标查询时建议：

1. 合理设置内存和临时存储配额
2. 监控临时文件目录的使用情况
3. 对于关键应用，考虑实现应用层的清理机制
4. 定期检查并清理遗留的临时文件

总结

TiDB在处理大结果集查询时提供的spilling机制是一个重要特性，但在错误处理路径上存在资源清理不彻底的问题。通过深入分析问题根源并实施相应修复，可以确保系统在各种异常情况下都能正确释放资源，维护系统的稳定性和可靠性。