如何处理耗时的 SQL？

Question

我们有一个包含 600 万条记录的表，然后我们有一个 SQL 需要大约 7 分钟来查询结果。我认为 SQL 不能再优化了。

查询时间导致我们的weblogic抛出最大阻塞线程异常。

有什么建议可以让我处理这个问题吗？

以下是查询，但我很难更改它，

SELECT * FROM  table1 
WHERE trim(StudentID) IN ('354354','0') 
AND concat(concat(substr(table1.LogDate,7,10),'/'),substr(table1.LogDate,1,5)) 
       BETWEEN '2009/02/02' AND '2009/03/02' 
AND TerminalType='1' 
AND RecStatus='0' ORDER BY StudentID, LogDate DESC, LogTime

但是，我知道使用字符串来比较日期很耗时，但是在我无法更改表结构之前有人写道...

LogDate被定义为一个字符串，格式是mm/dd/yyyy，所以我们需要在...和...之间进行substring和concat，我觉得这里很难优化。

Answer 1

这个查询很有可能正在执行全文件扫描，因为您的 WHERE 条件不太可能利用任何索引。

LogDate 是日期字段还是文本字段？如果是日期字段，则不要执行 substr 和 concat。只需说“'2009-02-02' 和 '2009-02-03' 之间的 LogDate 或任何日期范围。如果它被定义为文本字段，您应该认真考虑将其重新定义为日期字段。（如果您的日期真的是文本并且写成 mm/dd/yyyy 那么如果日期跨度超过一年，那么您的 ORDER BY ... LOGDATE DESC 将不会给出有用的结果。）

StudentID 是否需要修整？在将数据放入数据库之前清理数据要好得多，然后每次检索时都尝试清理它。

如果将 LogDate 定义为日期，并且您可以在输入时修剪 studentid，然后在一个或两个字段上创建索引，查询时间应该会大幅下降。

或者，如果您想要一个快速而肮脏的解决方案，请在“trim(studentid)”上创建一个索引。

如果这没有帮助，请向我们提供有关您的表格布局和索引的更多信息。

Answer 2

SELECT * ... WHERE trim(StudentID) IN ('354354','0')

如果这是正常构造，那么您需要一个function based index。因为没有它你会强制数据库服务器执行全表扫描。

根据经验，您应该尽可能避免在WHERE 子句中使用函数。 trim(StundentID)、substr(table1.LogDate,7,10) 阻止数据库服务器使用任何索引或对查询应用任何优化。尝试尽可能多地使用本机数据类型，例如DATE 而不是 VARCHAR 用于 LogDate。 StudentID 也应该在客户端软件中正确管理，例如修剪INSERT/UPDATE之前的数据。

Answer 3

如果你的数据库支持它，你可能想试试materialized view。

如果没有，可能值得考虑自己实现类似的东西，通过安排一个运行查询的计划作业，该查询执行昂贵的修剪和连接并使用结果刷新表，以便您可以针对更好的查询运行表，避免昂贵的东西。或者使用触发器来维护这样的表。

Answer 4

但是查询时间导致我们的weblogic抛出最大阻塞线程异常。

如果查询需要 7 分钟且无法加快，您必须停止实时运行此查询。您可以更改您的应用程序以查询您定期刷新的缓存结果表吗？

作为在此之前的紧急权宜之计，您可以实现一个闩锁（在 Java 中），它一次只允许一个线程执行此查询。第二个线程将立即因错误而失败（而不是使整个系统停机）。这可能不会让这个查询的用户满意，但至少它保护了其他所有人。

我更新了查询，你能给我一些建议吗？

这些字符串操作使索引几乎不可能。你确定你至少不能摆脱“修剪”吗？实际数据中真的有多余的空格吗？如果是这样，您可以将范围缩小到一个 student_id，这应该会加快速度。

您希望在 (student_id, log_date) 上有一个复合索引，希望复杂的 log_date 条件仍然可以使用索引范围扫描来解决（对于给定的学生 id）。

Answer 5

如果没有关于您正在执行哪种查询以及是否使用索引的任何进一步信息，很难提供任何具体信息。

但这里有一些一般提示。

1. 确保对经常过滤/排序的列使用索引。
2. 如果只是某个查询太慢，也许您可​​以通过在数据库更改时自动生成结果来阻止自己执行该查询。例如，您通常可以将计数存储在某处，而不是 count()。

尝试通过在将数据插入表之前/同时自动调用trim() 来从查询中删除trim()。这样您就可以简单地使用索引来查找StudentID。

此外，date 过滤器应该可以在您的数据库中本地使用。在不知道哪个数据库可能更困难的情况下，但这样的事情应该可以工作：LogDate BETWEEN '2009-02-02' AND '2009-02-02'

如果您还在所有这些列上添加索引（即StudentID、LogDate、TerminalType、RecStatus 和 EmployeeID，那么它应该是闪电般的速度。

Answer 6

在不知道您使用的是什么数据库以及您的表结构是什么的情况下，很难提出任何改进建议，但可以通过使用索引、提示等来改进查询。

在您的查询中，以下部分 concat(concat(substr(table1.LogDate,7,10),'/'), substr(table1.LogDate,1,5)) BETWEEN '2009/02/02' AND '2009/02/02'

太搞笑了。 在“2009/02/02”和“2009/02/02”之间 ??伙计，你想做什么？

你能把你的表结构贴在这里吗？

无论如何，600 万条记录并不是什么大事。

Answer 7

很多人告诉你，你的问题出在日期字段上。您肯定需要将日期从字符串字段更改为本机日期类型。如果它是以这种确切方式在您的应用程序中使用的遗留字段 - 您仍然可以创建一个基于函数的to_date(logdate, 'DD/MM/YYYY') 索引，将您的“字符串”日期转换为“日期”日期，并允许快速已经提到的@ 987654322@搜索而不修改你的表数据。

这应该会加快速度。

Answer 8

根据您提供的少量信息，我的预感是以下子句为我们提供了线索：

     ... WHERE trim(StudentID) IN ('354354','0') 

如果您有大量学生身份不明的记录（即 studentID=0），studentID 上的索引将非常不平衡。

在 600 万条记录中，有多少条 studentId=0？

Answer 9

您的主要问题是您的查询将所有内容都视为字符串。

如果 LogDate 是没有时间组件的日期，您需要类似以下的内容

SELECT * FROM  table1 
WHERE  StudentID  IN (:SearchStudentId,0) 
AND  table1.LogDate = :SearchDate
AND TerminalType='1' 
AND RecStatus='0' 
ORDER BY EmployeeID, LogDate DESC, LogTime

如果 LogDate 有时间组件，而 SearchDate 没有时间组件，那么类似这样。 （.99999 会将时间设置为午夜前 1 秒）

SELECT * FROM  table1 
WHERE  StudentID  IN (:SearchStudentId,:StudentId0) 
AND  table1.LogDate BETWEEN :SearchDate AND :SearchDate+0.99999 
AND TerminalType='1' 
AND RecStatus='0' 
ORDER BY EmployeeID, LogDate DESC, LogTime

注意在调用之间更改的参数使用绑定变量。它不会使查询更快，但它是“最佳实践”。

根据您的调用语言，您可能需要添加 TO_DATE 等，以将传入的绑定变量转换为 Date 类型。

Answer 10

如果 StudentID 是 char（通常是使用 trim() 的原因），您可以通过填充变量而不是修剪字段来获得更好的性能，如下所示（假设 StudentID 是 char(10)）：

StudentID IN (lpad('354354',10),lpad('0',10))

这将允许使用 StudentID 上的索引（如果存在）。