Sql server 如何优化SQL Server全文搜索

我想使用fulltextsearch来实现自动完成服务，这意味着我需要它快速工作！最多两秒

搜索结果来自不同的表，因此我创建了一个视图将它们连接在一起。 我使用的SQL函数是FREETEXTTABLE（）

查询运行非常缓慢，有时长达40秒

为了优化查询执行时间，我确保基表有一个整型数据类型（而不是GUID）的聚集索引列

我有两个问题： 首先，关于如何使全文搜索更快，还有什么其他想法吗？（不包括升级硬件…） 第二，为什么每次重建全文目录后，搜索查询都会运行得非常快（不到1秒），但只运行第一次。我第二次运行查询时，需要几秒钟的时间，从那里开始，一切都很顺利。。。。知道为什么会发生这种情况吗？

查看。然而，如果你真的想提高性能，你必须考虑升级你的硬件。（通过将数据和全文索引文件移动到单独的读优化磁盘，以及将日志和tempdb移动到单独的写优化磁盘，我看到了显著的性能提高——总共增加了4个磁盘，另外还有1个用于OS和SQL Server二进制文件。）

我推荐一些其他非硬件解决方案：

自定义内置的停止词列表以定义更多的停止词，从而减小全文索引的大小

更改tempdb的文件结构。见和

如果您的视图执行了多于1次的调用FruteExtCt，那么考虑更改您的数据结构，以便视图只需调用1次。

---

然而，这些本身都不可能是您正在寻找的加快速度的银弹解决方案。我怀疑这里可能还有其他因素（可能是服务器性能差、网络延迟、服务器上的资源争用……）尤其是因为您说过，每次执行全文搜索都会变慢，这与我的经验相反。

重建目录后第一次查询速度非常快的原因可能很简单：

删除目录并重建它时，必须重建索引，这需要一些时间。如果您在重建完成之前进行查询，他们的查询速度会更快，原因很简单，因为数据更少。您还应该注意，查询结果包含的行更少

因此，只有在索引重建完成后，测试查询速度才有意义

下面的选择可能有助于检查索引的大小（以及碎片）。当大小停止增长时，索引的重建完成；）

---

你能为你的视图发布代码吗？全文索引是零碎的吗？也许这会有帮助：

-- Compute fragmentation information for all full-text indexes on the database
SELECT c.fulltext_catalog_id, c.name AS fulltext_catalog_name, i.change_tracking_state,
    i.object_id, OBJECT_SCHEMA_NAME(i.object_id) + '.' + OBJECT_NAME(i.object_id) AS object_name,
    f.num_fragments, f.fulltext_mb, f.largest_fragment_mb,
    100.0 * (f.fulltext_mb - f.largest_fragment_mb) / NULLIF(f.fulltext_mb, 0)  AS fulltext_fragmentation_in_percent
FROM sys.fulltext_catalogs c
JOIN sys.fulltext_indexes i
    ON i.fulltext_catalog_id = c.fulltext_catalog_id
JOIN (
    -- Compute fragment data for each table with a full-text index
    SELECT table_id,
        COUNT(*) AS num_fragments,
        CONVERT(DECIMAL(9,2), SUM(data_size/(1024.*1024.))) AS fulltext_mb,
        CONVERT(DECIMAL(9,2), MAX(data_size/(1024.*1024.))) AS largest_fragment_mb
    FROM sys.fulltext_index_fragments
    GROUP BY table_id
) f
    ON f.table_id = i.object_id