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

2020-01-09 09:41:02 223 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

DataMind：Apache Doris 4.0 一站式融合数据引擎，用SQL实现AI原生能力这次我们来看一个来自字节跳动的技术项目：DataMind。它不是一个新的AI模型，而是一个将AI能力深度集成到OLAP数据库Apache Doris中的一站式融合数据引擎。简单来说，它让数据库不仅能处理传统的结构化数据，还能直接处理文本、音视频等非结构化数据，并调用大模型进行分析和检索，实现“数据+AI”的闭环。对于数据工程师、算法工程师和应用开发者而言，DataMind的核心价值在于：用SQL就能完成AI任务。你不再需要将数据导出到Python脚本或专门的AI服务中处理，可以直接在数据库里进行向量检阅读详情

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

...全文

Nginx+PHP-FPM多Pool隔离优化实战：老旧系统性能提升核心方案 PHP-FPM进程池（PHP pools）是Web服务资源调度的基础机制，其核心原理在于通过进程管理模式（static/dynamic/ondemand）与内存占用模型的协同控制，实现请求级资源隔离与精细化分配。该技术不依赖版本升级或硬件扩容，却能显著提升并发承载力、降低502错误率，并保障关键路径稳定性，广泛适用于金融、教育、工业等领域的遗留系统运维场景。尤其在Nginx与PHP-FPM协同架构中，结合Unix socket权限匹配、slowlog阈值分层设置及pool级配置拆分，可将传统单池瓶颈转化为高阅读详情

itcoco

MS-SQL Server 34,876 成员 254,635 内容

+ 关注 + 加入社区

切换为时间正序

唐诗三百首 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 的语句，是可以查到的。现在可能被冲掉了。

Csdn技术大神 2020-01-09

打赏
举报

影响不是很大没问题的

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

相关推荐