Blockscout项目中地址交易列表加载性能优化分析

在区块链浏览器Blockscout的使用过程中，我们发现当查询某些智能合约地址的交易历史时，页面加载速度异常缓慢。经过深入分析，这个问题源于PostgreSQL数据库查询优化器选择了不合适的索引策略，导致查询效率低下。

问题背景

Blockscout作为区块链生态中广泛使用的区块链浏览器，需要高效地处理大量交易数据的查询请求。特别是在查询具有以下特征的地址时，性能问题尤为突出：

1. 目标地址是智能合约地址
2. 该地址有大量历史交易记录
3. 这些交易都发生在较早的区块高度

技术分析

通过执行计划分析，我们发现当前查询语句使用了以下执行路径：

EXPLAIN SELECT * FROM transactions 
WHERE to_address_hash='\xa45b42a4855ac5cfefc64fd7079da6416511ec22'
ORDER BY block_number DESC limit 51;

查询优化器选择了transactions_block_number_index索引进行反向扫描，然后对结果进行过滤。这种执行计划对于具有大量历史交易的地址效率极低，因为：

1. 需要扫描大量不相关的区块数据
2. 然后对每条记录进行地址匹配过滤
3. 整个过程可能需要超过1分钟才能完成

优化方案

实际上，数据库中已经存在一个更适合此类查询的复合索引：

"transactions_to_address_hash_with_pending_index_asc" 
btree (to_address_hash, block_number, index, inserted_at, hash DESC)

这个索引的结构完全匹配我们的查询条件：

1. 首先按地址哈希过滤
2. 然后按区块号排序
3. 其他字段确保索引的唯一性

如果查询优化器能够选择这个索引，查询效率将大幅提升，因为：

1. 直接定位到目标地址的所有交易
2. 按区块号降序排列
3. 只需读取前51条记录即可返回结果

解决方案建议

针对这个问题，我们建议采取以下优化措施：

1. 查询重写：修改API端点中的查询语句，使用更明确的语法提示优化器选择正确的索引

2. 索引提示：在PostgreSQL中通过设置enable_indexscan等参数强制使用特定索引

3. 统计信息更新：确保数据库的统计信息是最新的，帮助优化器做出更好的决策

4. 复合索引优化：考虑调整现有复合索引的字段顺序，使其更符合常见查询模式

性能影响

实施优化后，预期性能提升将非常显著：

• 查询响应时间从分钟级降低到毫秒级
• 数据库服务器负载降低
• 用户体验大幅改善

结论

数据库索引选择是影响区块链浏览器性能的关键因素。通过深入分析查询模式和索引结构，我们可以显著提升Blockscout在处理大量历史交易查询时的性能。这种优化不仅解决了当前报告的具体问题，也为处理类似场景提供了参考方案。