1、模糊匹配
关于2个表模糊搜索匹配的问题,现已找到较快的解决方法,速度提升到每秒5条记录左右,而且不占CPU,不占内存,方法如下:
-------------------------------------------------------------------------
环境:
有2个表,
表1:MainTable (现有记录数在10万条左右)
字段:
id bigint自动编号
Title nvarchar(30)
SubId nvarchar(max)
表MainTable:
Id Title SubId
1 A 0
2 B 0
3 C 0
4 D 0
5 E 0
6 F 0
表2:SubTable (现有记录数在300万条左右)
字段:
id bigint自动编号
Description nvarchar(100)
Fl int '默认值为0,当进行模糊匹配后,值改为1
表SubTable:
Id Description Fl
1 ABC 0
2 AB 0
3 CD 0
4 EA 0
二、需要实现的结果为:
表MainTable:
Id Title SubId
1 A 0,1,2,4
2 B 0,1,2
3 C 0,1,3
4 D 0,3
5 E 0,4
6 F Null
第6条记录由于没有匹配的值,所以改为Null
-------------------------------------------------------------------------
1、由于记录数太多,通过内部存储搜索速度太慢,中途不能暂停,平均每分钟才能处理5条记录左右;
2、原先通过外部循环的方法处理,速度1秒1条左右,会比方法1速度快,但非常占CPU;
现在的办法:
用VBS编写,定义2个数组,IDArray()和DescriptionArray()分别用于存储在SubTable表检索到的ID集和Description集
1、MainTable用循环的方式,按字段Title升序的方式得取Title字段的值,
先取得第一条记录的Title字段的第一个字符,根据这个字符模糊匹配SubTable的Description字段,并将检索到的结果存放在数组IDArray和DescriptionArray()中。
2、通过循环方式,将MainTable表的当前记录的Title字段的完整值与DescriptionArray()的值进行匹配处理,并update。
3、获取MainTable的下一条记录,判断该条记录Title字段的第一个字符是否与上一条记录的Title的第一个字符相同,如果相同,则从第2步开始处理;如果不同,则从第1步开始处理。
------------------------------------------------------------------------------
这种方法减少了每次去SubTable模糊搜索的次数,如果Title字段的第一个字符相同的记录非常多的情况下,速度还可能会提高很多。
总结一下,这个问题的解决不是通过sql server,而是在vbs,通过运用数据本身的特性,也就是:Title字段的第一个字符相同的记录非常多,减少了重复的劳动,少做了很多的无用功,最后,大幅提升性能。
真的是好办法,其实,从这个例子中可以看出,优化,更重要的是强调思维,而不简单的是某个技术,注重细节,仔细分析,楼主就解决了这个优化问题。
2、分页查询
http://bbs.csdn.net/topics/390702739
有个日志表,测试数据200万条,用的分页查询,每次查询50条记录,表里创建了非聚集索引,查询前几页会很快,基本在1秒内,如果突然查询表的最后的数据,也就是最后一页,则需要花费半分钟的时候,请问这是为什么呢?有没有办法优化一下呢?
表结构如下:
-
CREATE NONCLUSTERED
INDEX [_dta_index_loga_11_69575286__K1_2_3_4_5]
ON [dbo].[loga]
-
(
-
[DateTime]
ASC
-
)
-
INCLUDE ( [ServerName],
-
[ApplicationName],
-
[InfoLevel],
-
[msg])
WITH (PAD_INDEX =
OFF, STATISTICS_NORECOMPUTE =
OFF, SORT_IN_TEMPDB =
OFF, IGNORE_DUP_KEY =
OFF, DROP_EXISTING =
OFF,
ONLINE =
OFF, ALLOW_ROW_LOCKS =
ON, ALLOW_PAGE_LOCKS =
ON)
ON [PRIMARY]
-
GO
-
-
-
ALTER
TABLE [dbo].[loga]
ADD
CONSTRAINT [PK_loga] PRIMARY
KEY CLUSTERED
-
(
-
[ServerName]
ASC,
-
[ApplicationName]
ASC,
-
[DateTime]
ASC
-
)
WITH (PAD_INDEX =
OFF, STATISTICS_NORECOMPUTE =
OFF, SORT_IN_TEMPDB =
OFF, IGNORE_DUP_KEY =
OFF,
ONLINE =
OFF, ALLOW_ROW_LOCKS =
ON, ALLOW_PAGE_LOCKS =
ON)
ON [PRIMARY]
-
GO
查询语句:
-
With info
-
AS
-
(
-
SELECT [datetime],servername,applicationname,
-
infolevel,msg,
-
ROW_NUMBER()
OVER (
order
by [datetime])
as RowNumber
-
FROM loga
-
)
-
-
select *
-
from info
-
Where RowNumber
between
500
and
1000
select count(*) from loga
以上两个语句,第一个语句,运行速度不稳定,在查询最后一个分页时需要30秒左右,而查询前几页的时候,基本上是0秒。
而第二个语句的运行速度非常慢。
下面是执行计划,分别是count(*) 、查询前两页、查询最后一页的:
仔细查看发现,执行计划中使用了索引扫描,那么既然是扫描,那为什么前两页那么快,而最后一页那么慢呢?
我觉得是这样的,扫描就像是翻书一样,从第一页开始,由于第一个是只需要看第二页,也就是500-1000的500条数据,也就是第二页,那么当sql server 翻到第二页的时候,取到了需要的数据,就停止了继续查看后面的数据了,于是查询结束了,这就是只需要0秒的原因。
而后一个,是最后一页,也就相当于一本书的最后一页,当然啦,sql server并不知道最后的500条数据,到底是准确的处于哪些数据页中(这个并不像书那么简单),于是只能从第一页开始查看,直到最后一页,取出最后的500行数据,那么就会需要消耗30多秒了,那么怎么优化呢?
我的想法是,把语句修改一下,先计算表中总的条数,然后看要取的条数,位于整个表中的前半部分,还是后半部分,如果是后半部分,那么把语句改成这样:
-
With info
-
AS
-
(
-
SELECT [datetime],servername,applicationname,
-
infolevel,msg,
-
ROW_NUMBER()
OVER (
order
by [datetime]
desc )
as RowNumber
-
FROM loga
-
)
-
-
select *
-
from info
-
Where RowNumber
between
1
and
500
-
order
by datetime
修改后,取最后一页,只需要0秒。
而count(*) 可以通过再建一个索引,来加快速度,通过建立如下的索引,count(*)只需要0秒就出来了:
create index idx_loga_datetime on loga(datetime)