高频率的执行一条语法错误的sql,会影响数据库性能么

itcoco 2020-01-09 09:41:02

最近后台程序查询数据库的一个表经常出现查询超时，且数据库服务器内存使用率非常高，排查原因，发现有个高频率执行的sql 参数没传，类似这样的 select count(id) from tb where 条件 and gtime>'' 时间参数没传。这个sql执行频率很高，这会影响到这个表无法其他正常业务执行查询语句么会影响这个表的插入么。

...全文

139 6 打赏收藏转发到动态举报

写回复

用AI写文章

6 条回复

切换为时间正序

请发表友善的回复…

发表回复

唐诗三百首 2020-01-09

打赏
举报

高频率执行语法错误的sql会影响数据库性能. 即使语法修改正确了, 建议分析一下高频率执行这个语句是否真有必要, 或是否可以优化.

itcoco 2020-01-09

打赏
举报

时间是根据session 读的，代码没判断 session 当 session 失效的时候，读不到时间，所以执行的时候时间参数是空。现在补了这个漏洞，加上了session 失效的判断，感觉数据库服务器cpu使用率就下来了

卖水果的net 版主 2020-01-09

打赏
举报

参数没传，不一定会有语法错误。比如你写了 where 日期 > '' ，这个可能存在一个隐性转化，实际上SQL 是执行了，并且效率很差，就会对数据库有影响。如果确实有了语法错误，对数据库没有影响，语法都检查不过去，也就是说根本没有执行它。

吉普赛的歌版主 2020-01-09

打赏
举报

1. sql是错的，那对数据库基本上没有影响。 2. 内存使用高是正常的。你换个思路吧，直接查哪个sql 占用的cpu比较大：注，要在服务器上直接执行

SELECT TOP 10 OBJECT_NAME(qt.objectid, qt.dbId)  AS procName,
       DB_NAME(qt.dbId)                   AS [db_name],
       qt.text                            AS SQL_Full,
       SUBSTRING(
           qt.text,
           (qs.statement_start_offset / 2) + 1,
           (
               (
                   CASE statement_end_offset
                        WHEN -1 THEN DATALENGTH(qt.text)
                        ELSE qs.statement_end_offset
                   END 
                   - qs.statement_start_offset
               ) / 2
           ) + 1
       )                                  AS SQL_Part --统计对应的部分语句
       ,
       qs.creation_time,
       qs.last_execution_time,
       qs.execution_count,
       qs.last_elapsed_time / 1000000     AS lastElapsedSeconds,
       qs.last_worker_time / 1000000      AS lastCpuSeconds,
       CAST(
           qs.total_elapsed_time / 1000000.0 / (
               CASE 
                    WHEN qs.execution_count = 0 THEN -1
                    ELSE qs.execution_count
               END
           ) AS DECIMAL(28, 2)
       )                                  AS avgDurationSeconds,
       CAST(qs.last_logical_reads AS BIGINT) * 1.0 / (1024 * 1024) * 8060 AS 
       lastLogicReadsMB,
       qs.last_logical_reads,
       qs.plan_handle
FROM   sys.dm_exec_query_stats qs
       CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS p
WHERE  qs.last_execution_time >= CONVERT(CHAR(10),GETDATE(),120)+' 08:00'	--今天8点之后的慢SQL
       AND qs.last_elapsed_time >= 3 * 1000 * 1000							--只取执行时间大于 3 秒的记录
       AND qt.[text] NOT LIKE '%Proc_DBA%'
ORDER BY
       qs.last_worker_time DESC

吉普赛的歌版主 2020-01-09

打赏
举报

你有点误导我了，你这个 sql 在逻辑上是错的，但语法上是正确的：下面是测试结果：

USE tempdb
GO
IF OBJECT_ID('t') IS NOT NULL
	DROP TABLE t
GO
CREATE TABLE t(
	id INT IDENTITY(1,1) PRIMARY KEY,
	d DATETIME NOT NULL	
)
GO
SET NOCOUNT ON
INSERT INTO t(d) VALUES('1900-01-01')
INSERT INTO t(d) VALUES('2010-01-01')
GO

SELECT * FROM t WHERE d>''
/*
id	d
2	2010-01-01 00:00:00.000
*/

DECLARE @d DATETIME
SET @d=''
SELECT @d AS r
/*
r
1900-01-01 00:00:00.000
*/

因为绝大多数的日期都会>'1900-01-01', 所以消耗必然是很大的。不过，你早点用我 #1 的语句，是可以查到的。现在可能被冲掉了。