使用 LIKE 运算符搜索 SQL Server

发布于 2024-10-09 15:02:16 字数 1701 浏览 5 评论 0原文

当我尝试从 C# 代码中读取 SQL Server 2005 中的行时遇到问题

想法:

在我的数据库 (SQL Server 2005 Express) 中,有一个表,其中有一列(数据类型为 ntext),其中包含HTML 代码。

在我的 C# 应用程序中,用户可以输入一个句子(HTML 代码)并搜索包含该句子的行。

从我的应用程序生成的查询是:

USE test   
SELECT   
 al.aal_Id As ID,   
 al.aal_Description As Opis,   
 au.au_Title As Tytul_szablonu,   
 au.au_Note As Nazwa_szablonu   
FROM dbo.au_Allegro al   
LEFT OUTER JOIN dbo.au__Auction au ON (al.aal_AuctionId = au.au_Id)   
WHERE  
 au.au_Type = 11   
 AND al.aal_Description COLLATE SQL_Latin1_General_CP1_CS_AS LIKE '%%' ESCAPE '\'  

在我的应用程序中,我正在转换特殊字符(例如',)并添加转义字符。

用户尝试搜索很长的句子(大约 7000 多个字符),当他尝试执行此操作时,sqlserver.exe 进程会消耗他所有的 RAM 内存,并且搜索时间大约为 30 多分钟(他有该表中大约有 1000 多行)。

查询返回 0 行。

当他尝试在 SQL Server Management Studio 中运行(相同的)查询时,数据库会在几秒钟内显示结果(包含行)。

在我的应用程序中,我使用 SqlDataAdapter

System.Data.DataTable dt = new System.Data.DataTable();  
System.Data.SqlClient.SqlCommand cmd = new System.Data.SqlClient.SqlCommand();  
cmd.CommandTimeout = 0;  
cmd.Connection = conn;  
System.Data.SqlClient.SqlDataAdapter da = new System.Data.SqlClient.SqlDataAdapter(kwerenda, conn);  
try  
{
  da.Fill(dt);
}

我尝试了 SqlDataReader

dr = cmd.ExecuteReader();  
while (dr.Read())  
{  
  string id = dr["ID"].ToString();  
  string opis = dr["Opis"].ToString();  
  string tytul = dr["Tytul_szablonu"].ToString();  
  string nazwa = dr["Nazwa_szablonu"].ToString();  
  dt.Rows.Add(id, opis, tytul, nazwa);  
}

当我尝试在测试数据库中模拟它时,我对搜索(相同)句子没有任何问题。

你有什么建议给我吗?

我无法对用户数据表进行任何更改,我无法去找他并检查发生了什么。

I have a problem when I try to read rows from SQL Server 2005 from code in C#

The idea:

In my database (SQL Server 2005 Express) there is a table with a column (of datatype ntext) containing HTML code.

In my C# application user can enter a sentence (HTML code) and search the rows with contains this sentence.

The query generated from my app is:

USE test   
SELECT   
 al.aal_Id As ID,   
 al.aal_Description As Opis,   
 au.au_Title As Tytul_szablonu,   
 au.au_Note As Nazwa_szablonu   
FROM dbo.au_Allegro al   
LEFT OUTER JOIN dbo.au__Auction au ON (al.aal_AuctionId = au.au_Id)   
WHERE  
 au.au_Type = 11   
 AND al.aal_Description COLLATE SQL_Latin1_General_CP1_CS_AS LIKE '%%' ESCAPE '\'  

In my App I'm converting special characters (e.g. ',) and adding escape character.

User tries to search for very long sentence (about 7000+ chars), when he tries to do this the sqlserver.exe process consumes all of his RAM memory and search time is about 30+ minutes (he has about 1000+ rows in this table).

The query returns 0 rows.

When he tries to run (this same) query in SQL Server Management Studio the database shows results in few seconds (with rows).

In my app I use SqlDataAdapter:

System.Data.DataTable dt = new System.Data.DataTable();  
System.Data.SqlClient.SqlCommand cmd = new System.Data.SqlClient.SqlCommand();  
cmd.CommandTimeout = 0;  
cmd.Connection = conn;  
System.Data.SqlClient.SqlDataAdapter da = new System.Data.SqlClient.SqlDataAdapter(kwerenda, conn);  
try  
{
  da.Fill(dt);
}

I tried SqlDataReader:

dr = cmd.ExecuteReader();  
while (dr.Read())  
{  
  string id = dr["ID"].ToString();  
  string opis = dr["Opis"].ToString();  
  string tytul = dr["Tytul_szablonu"].ToString();  
  string nazwa = dr["Nazwa_szablonu"].ToString();  
  dt.Rows.Add(id, opis, tytul, nazwa);  
}

When I tried to simulate this in my test database I don't have any problems with search (this same) sentences.

Have you got any tips for me ?

I can't do any changes in user datatable, i can't go to him and check what happens.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

玉环 2024-10-16 15:02:16

SQL 命令是否执行存储过程?如果是这样,您可能会得到不同的查询计划,这可能解释了应用程序之间的时间差异。您的 ADO.Net 调用可能会受到 参数嗅探,这可能会导致完全不同的查询执行时间。

您可以采取一些措施来避免此问题并产生一致的结果

  1. 将参数转换为存储过程内的局部变量。
  2. 完全禁用 SQL Server 上的该功能。

正如约翰指出的那样,你的语法看起来也很可疑。如果可能的话,最好对该列使用 NVARCHAR(MAX) 数据类型,因为 NTEXT 已被弃用,因此应避免使用。

在非索引列上执行类似搜索的更好替代方法是利用 SQL 的全文搜索,该搜索针对这些类型的查询进行了优化。

Is the SQL command executing a stored procedure? If so you might be getting different query plans, which may explain the timing difference between the apps. Your ADO.Net call might be affected by something known as parameter sniffing, which can cause radically different query execution times.

There are a couple of things you can do to avoid this problem and yield consistent results.

  1. Convert parameters to local variables inside of the stored procedure.
  2. Disable the feature on the SQL server altogether.

Also your syntax looks suspect as John pointed out. It would be better to use a NVARCHAR(MAX) datatype for that column if possible NTEXT should be avoided as its been deprecated.

A better alternative to doing like searches on a non-indexed column like this is to utilize the SQL's Full Text Search which is optimized for these types of queries.

全部不再 2024-10-16 15:02:16

您可能想做一些事情。

首先,不要使用 nText。 SQL 2005 有一种称为 nvarchar(max) 的数据类型。它更适合存储大量文本。此外,ntext 已被弃用,所以为了省去一些麻烦,现在就转换它。请参阅此链接关于如何成功做到这一点。

其次,您发布的查询不寻常。您有一个左外连接,但在外连接表上有一个 where 子句。由于 where 子句,它(希望)被转换为内部联接。您应该这样编写或将 au.au_type = 11 移动到连接构造的一部分。我怀疑你想要后者。

第三,当客户端第一次通过您的应用程序运行查询时,它会根据这些参数生成查询计划。此后不久在 Management Studio 中运行完全相同的查询将重用该计划和缓存的数据。因此第二次通过的速度会很快,所以这并不奇怪。

第四,我认为您没有发布运行的实际查询。我怀疑您正在比较的参数中存在一些数据,这些数据要么没有正确转义,要么正在使用保留字符之一,例如“[”、“]”、^ 等。

A couple of things you might want to do.

First, don't use nText. SQL 2005 has a datatype called nvarchar(max). It's MUCH better for storing large amounts of text. Further, ntext was deprecated so save yourself some trouble and convert it now. See this link on how to successfully do this.

Second, the query you posted is unusual. You have a left outer join, but you have a where clause on the outer joined table. Because of the where clause it's being converted (hopefully) into an inner join. You should just write it that way OR move the au.au_type = 11 to be part of the join construct. I doubt you want the latter.

Third, when the client runs the query the first time through your app it is generating a query plan based on those parameters. Running the exact same query shortly thereafter in Management Studio is going to reuse that plan and cached data. Therefore the second pass will be fast so no surprise there.

Fourth, I don't think you posted the actual query that was run. I suspect there is some data in the parameter you are comparing which either isn't escaping properly OR is using one of the reserved characters such as '[', ']', ^, etc.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文