我正在编写一个程序，将用户提交的查询与关键字列表进行匹配。该列表大约有2000个单词，性能最重要。
旧
将此列表存储在a中是否更快 它在SQL表或硬代码中 源代码？该列表不需要 经常更新。
如果SQL表的哪个数据更快 类型会是最好的？ （智力， nvarchar的？）
如果硬编码列表的数据更快 类型会是最好的？ （列表？）
有什么建议吗？
快速查找的最佳内存数据结构是什么？
答案 0 :(得分：5)
存储此数据的性能无关紧要。
如果您启动程序，则从您存储的数据存储区加载字符串数组 一次 。然后你可以一直使用这个数组，直到你退出程序。
答案 1 :(得分：5)
IMO，如果列表没有经常更新，请将其存储在文件（text / xml）上，然后将其缓存在您的应用程序中，以便下次请求更快。
答案 2 :(得分：2)
好的，回复你的编辑（并基本上将我的评论提到答案中）：
事先指定您期望的表现。
针对排序数组对应用程序进行编码，并使用二进制搜索在数组中搜索关键字。这很容易实现，并提供了不错的性能。然后进行配置以查看它是否与您要求的性能相匹配。如果此表现可以接受，请继续。这里最糟糕的表现是O(m log n)，其中n是关键字的数量，m是关键字的最大长度。
如果第二步中的性能不可接受，请使用trie（也称为前缀树）。此处的预期效果为m，其中m是关键字的最大长度。查看是否符合您的预期效果的配置文件。如果没有，请重新审视您的绩效标准;他们可能是不合理的。
如果您仍未达到性能规格，请考虑使用散列表（在.NET中，您将使用HashSet<string>。虽然散列表的最坏情况会更差，但它可能会有更好的平均值大小写性能（如果没有冲突，哈希表查找为O(1)，而哈希计算功能为O(m)，其中m是关键字的最大长度。。这可能更快（平均而言） ）但可能并不明显。
您甚至可以考虑直接跳到最后一步（因为它不如前者复杂）。这一切都取决于您的需求。尝试具有以下优点：您可以轻松地吐出最接近的匹配关键字，例如。
这里重要的是要对您的性能要求进行规范并进行分析！使用最简单的实现来满足您的性能要求（可维护性，可读性和可实现性（如果不是，现在就是一个词！）
答案 3 :(得分：0)
该列表不需要经常更新
我说如果它需要更新它不属于源代码。
答案 4 :(得分：0)
硬编码列表更快。检索列表的数据库命中无疑比从内存中对象中拉出列表要慢。
对于存储值的数据类型，数组可能比List更快，占用的内存更少，但是很简单。
答案 5 :(得分：0)
如果列表基本上是静态的，并且你可以花费一些时间准备（即在应用程序启动时），你可能最好将关键字列表存储在文本文件中，然后使用例如B *树在内部存储关键字（假设您只关心完全匹配而不是部分匹配或Levenshtein距离）。