自2008 R2以来，是否有任何Sql Server全文搜索（FTS）性能改进？

Question

我们在具有260万条记录的表上使用SQL Server 2008 R2全文搜索。搜索性能通常很差，它遵循常见的模式：冷系统/首次运行~10 +秒，后续运行~1-2秒。这与2013年2月的以下文章中报告的结果一致：

So You Think You Can Search – Comparing Microsoft SQL Server FTS and Apache Lucene

本文使用Wikipedia转储数据显示以下速度比较结果：

Indexing speed, size and single query execution time using:

                        Lucene      MS SQL FTS
Indexing Speed          3 MB/sec    1 MB/sec
Index Size              10-25%      25-30%
Simple query            < 20 ms     < 20 ms
Query With Custom Score < 4 sec     > 20 sec

Parallel Query Executions (10 threads, average execution time per query in ms):

                                     MS SQL FTS  Lucene (File System)   Lucene (RAM)
Cold System:         Simple Query    56          643                    21
                     Boost Query     19669*      859                    27
Second executions:   Simple Query    14          8                      < 5
                     Boost Query     465         17                     9

*average time, the very first query could be executed up to 2 min(!)

我的问题是：

1. 自从该文章于2013年2月8日发布以来，有几个主要的SQL Server版本，当有人迁移到更新的SQL Server版本时，有人可以报告相同数据（最好是超过100万条记录）的任何FTS性能改进（2012年，2014年）和2016）？
2. 更新的SQL Server版本是否支持放在RAM中的FTS目录/索引，就像solr / lucene一样？

更新：在我们的场景中，我们很少将新数据插入到FT目录链接表中，但是经常运行只读搜索。所以，我不认为SQL不断重建FTS索引是个问题。

Answer 1

Fulltext Search Improvements in SQL Server 2012：

我们查看了整个代码库，查看了在等待正在进行的索引更新以释放共享模式锁时查询是如何阻塞的，从索引片段填充期间分配的内存量到我们如何将查询代码库重新组织为流表值函数优化TOP N搜索查询，我们如何维护密钥分发直方图以执行并行线程搜索，一直到我们如何更好地利用处理器计算指令（例如评分等级）...最终结果是我们是能够显着提高性能（在大型查询工作负载的并发索引更新的许多情况下为10倍）并且无需更改任何存储结构或现有API表面即可扩展。从SQL 2008 / R2到Denali的所有客户都将受益于这一改进。

Answer 2

我建议你深入研究一下SQL Server FTS的内部结构。这将让您了解您的查询是如何执行的，以及这是否适合您。我建议从这里开始：https://technet.microsoft.com/en-us/library/ms142505(v=sql.105).aspx和这里：https://msdn.microsoft.com/ru-ru/library/cc721269.aspx。内部FTS使用表和索引。有他们所有的好处和缺点。因此，与任何其他表一样，如果该内部表的数据不在缓冲池中，则SQL Server将从磁盘读取到RAM。一旦数据存入RAM，就会从RAM中读取。