Performance 提高SQLServer2005查询性能

我有一个课程搜索引擎，当我尝试进行搜索时，显示搜索结果的时间太长。您可以尝试在此处进行搜索

在该页面上，您还可以看到数据库表和索引（如果有的话）

我没有使用存储过程-查询是使用Coldfusion内联的

我想我需要创建一些索引，但我不确定是什么类型的聚集索引、非聚集索引以及在什么列上

---

谢谢

您需要为WHERE子句中出现的列创建索引。该规则有一些例外情况：

如果列只有一个或两个唯一的值，那么典型的例子就是性别-可能的值只有男性和女性，这里没有索引。通常，您需要一个能够将需要处理的行限制为有效数字的索引。例如，一个只将搜索空间减少50%的索引是不值得的，但是一个将搜索空间减少99%的索引是值得的。 如果要搜索像“%something”这样的x，则索引没有意义。如果您认为索引指定了行的特定顺序，那么如果您正在搜索%s，则按x排序是没有用的：您将不得不扫描所有行。

让我们来看看你正在搜索关键词“会计”的情况。根据结果页，生成的SQL为：

SELECT
  *
FROM (
  SELECT TOP 10
    ROW_NUMBER() OVER (ORDER BY sq.name) AS Row,
    sq.*
  FROM (
    SELECT
      c.*,
      p.providername,
      p.school,
      p.website,
      p.type
    FROM
      cpd_COURSES c, cpd_PROVIDERS p
    WHERE
      c.providerid = p.providerid AND
      c.activatedYN = 'Y' AND
      (
        c.name like '%accounting%' OR
        c.title like '%accounting%' OR
        c.keywords like '%accounting%'
      )
  ) sq
) AS temp
WHERE
  Row >= 1 AND Row <= 10 

在本例中，我将假设cpd_COURSES.providerid是cpd_PROVIDERS.providerid的外键，在这种情况下，您不需要索引，因为它已经有了索引

此外，activatedYN列是一个T/F列，根据我上面关于将可能的值限制为50%的规则，T/F列也不应该被索引

最后，由于使用类似于“%accounting%”的x查询进行搜索，您也不需要名称、标题或关键字的索引，因为它永远不会被使用

因此，在这种情况下，您需要做的主要事情是确保cpd_COURSES.providerid实际上是cpd_PROVIDERS.providerid的外键

特定于SQL Server的 因为您使用的是SQL Server，所以Management Studio有许多工具可帮助您确定需要将索引放置在何处。如果您使用索引优化向导，它通常会很好地告诉您什么将给您带来良好的性能改进。您只需将您的查询剪切粘贴到其中，它就会返回要添加索引的建议

---

您仍然需要对添加的索引稍微小心一点，因为索引越多，插入和更新就会越慢。因此，有时您需要合并索引，或者如果它们不能提供足够的性能优势，就完全忽略它们。需要一些判断。

这是真实的实时数据库数据吗？52000条记录相对来说是一个非常小的表，SQL 2005可以处理这个表

我想知道为SQL server分配了多少RAM，或者数据库位于什么类型的磁盘上。IDE甚至SATA硬盘无法提供与15K RPM SAS磁盘相同的性能，如果有足够的RAM来缓存大量频繁访问的数据就更好了

说到这里，我觉得像“%accounting%”这样的c.name或像“%accounting%”这样的c.title或像“%accounting%”这样的c.keywords子句是有问题的

您是否可以创建一个单独的Course_关键字表，其中包含两列courseid和keyword varchar24，对于最长的关键字？应该足够了，courseid+keyword上有一个复合聚集索引

---

然后，为了使UI更加友好，使用AJAX应用关键字验证&当人们在关键字输入字段中键入单词时自动完成。这给了您一个幕后的好处，即有一个精确的关键字可供搜索，无需使用LIKE运算符进行模式匹配…

使用CF9？尝试使用Solr全文搜索而不是%xxx%？

您需要在搜索的字段上创建索引。索引是由索引字段预先排序的记录的辅助列表

---

想想老式的打印黄页——如果你想通过姓氏查找某人，电话簿已经按照这种方式排序了——姓氏是聚集索引字段。如果你想找到名为Jennifer或电话号码为867-5309的人的电话号码，你必须搜索每个条目，这需要很长时间。如果在后面有一个索引，上面按顺序列出了所有的电话号码或名字以及电话簿中列出的人的页面，那么速度会快得多。这些将是未聚集的索引。

我将尝试将IN语句更改为EXISTS查询，以查看您在邮政编码查找方面是否获得更好的性能。我的经验是IN语句对于小列表非常有效，但它们越大，查询引擎将停止搜索f，因此从EXISTS中获得更好的性能 或者它运行到的第一个实例的特定值

<CFIF zipcodes is not "">
    EXISTS (
        SELECT zipcode
        FROM cpd_CODES_ZIPCODES
        WHERE zipcode = p.zipcode
            AND 3963 * (ACOS((SIN(#getzipcodeinfo.latitude#/57.2958) * SIN(latitude/57.2958)) +
            (COS(#getzipcodeinfo.latitude#/57.2958) * COS(latitude/57.2958) *
            COS(longitude/57.2958 - #getzipcodeinfo.longitude#/57.2958)))) <= #radius#
    )
</CFIF>

---

参考页面显示他使用的是CF8——我相信只有Verity——对我们来说从来都不起作用。如果这对我们有很大帮助的话，我可以将应用程序移到CF9。索尔看起来很有趣。我去看看。希望整合起来不会太难。回答得好。执行查询后的执行计划选项为索引提供建议。不是很聪明，但起点很好。在那之后，你只需要耐心和时间来测试。数据库在一个共享服务器上/在一个便宜的网络托管提供商上共享数据库。我确信这是性能不佳的原因之一，但我希望至少在数据库中尽可能多地优化，因为这是免费的。很有趣。我试试看。谢谢