FreeScout性能优化：解决大表查询超时问题

问题背景

在使用FreeScout邮件客服系统时，当数据量达到约750万条线程记录时，系统搜索功能会出现性能问题。特别是在安装Faster Search模块后，访问设置页面(app-settings/meilisearch)时会出现504超时错误。

问题分析

经过排查发现，性能瓶颈源于MySQL数据库中的一个特定查询：

select count(*) as aggregate from threads where id < '7888888' and type in (1,2,3);

这个查询在InnoDB引擎下执行非常缓慢，耗时可达5分钟之久。主要原因在于：

1. 表数据量庞大（约750万条记录）
2. 查询条件使用了id和type字段，但没有合适的复合索引
3. InnoDB引擎在全表扫描时的性能问题

解决方案

针对这一问题，最有效的解决方案是为threads表添加复合索引：

ALTER TABLE threads ADD INDEX threads_meilisearch_id_type_index (id, type), ALGORITHM=INPLACE, LOCK=NONE;

这个索引的特点：

1. 包含了查询条件中使用的两个字段(id和type)
2. 使用INPLACE算法，避免表重建带来的长时间锁表
3. 采用NONE锁级别，最小化对生产环境的影响

添加索引后，查询时间从5分钟降至仅2秒，性能提升显著。

官方修复

FreeScout开发团队在Faster Search Module v1.0.14版本中已将此索引纳入官方更新，用户升级后无需手动添加索引。

技术建议

对于处理大规模数据的MySQL数据库，建议：

1. 定期分析慢查询日志
2. 为常用查询条件创建合适的复合索引
3. 避免全表扫描操作
4. 考虑使用EXPLAIN分析查询执行计划
5. 对于超大规模数据，可考虑分表或使用专业搜索引擎

此案例展示了数据库索引对系统性能的关键影响，特别是在处理海量数据时，合理的索引设计可以带来数量级的性能提升。