热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

sqlserver建索引建议,提高查询效率

如下有一个操作记录表,主要是记录用戶的操作记录。但表中数据越拉越多(已有上百万数据),查询越来越慢。现怎样建立索引提高查询效率,请大家给出建议。CREATETABLE[dbo].[T
如下有一个操作记录表,主要是记录用戶的操作记录。但表中数据越拉越多(已有上百万数据),查询越来越慢。
现怎样建立索引提高查询效率,请大家给出建议。

CREATE TABLE [dbo].[TRACK_LOG](
[T_SEQ] [bigint] IDENTITY(1,1) NOT NULL,
[O_ACCOUNT] [varchar](10) NOT NULL,--所属账号
[O_NAME] [varchar](30) NOT NULL,--所属名称 
[A_DATE] [date] NOT NULL,--发生日期  
[P_NAME] [varchar](128) NOT NULL,--項目名称  
[PIA_OWNER] [varchar](30) NULL,--个人账号
      ......................
)
 
現需要根據條件進行查看操作記錄,
查詢條件 可以有:
[PIA_OWNER] 个人账号,模糊查詢
[O_ACCOUNT] 所属账号,模糊查詢
[O_NAME]  所属名称 ,模糊查詢
[P_NAME] 項目名称,模糊查詢
[A_DATE] 发生日期,范围查詢

15 个解决方案

#1


模糊查询本来就不是一个高效的查询

#2


你说项目名称啥的模糊查询我好理解,帐号, 日期也要模糊查询?这个什么系统阿

如果是项目名称模糊查询,可以很简单结局。看你数据库怎么设计

#3


模糊查询好像不走索引,若表不是只读的,索引加多了也不好。
建议将非键列包含在非聚集索引中
CREATE NONCLUSTERED INDEX IX_Address_PostalCode
ON Person.Address (PostalCode)
INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);
GO

#4


kevinjay567
引用
模糊查询好像不走索引,若表不是只读的,索引加多了也不好。
建议将非键列包含在非聚集索引中
CREATE NONCLUSTERED INDEX IX_Address_PostalCode
ON Person.Address (PostalCode)
INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);
GO
 

如果我建立這樣一個非聚集索引,在如下的查詢中,我的索引能起作用嗎 

CREATE NONCLUSTERED INDEX IX_1
ON TRACK_LOG (A_DATE)
INCLUDE (O_ACCOUNT, O_NAME,P_NAME, PIA_OWNER);
GO



select * from TRACK_LOG  where  PIA_OWNER like '%@PIA_OWNER%‘  and  P_NAME like '%@P_NAME%'   and 
A_DATE>= '2015-01-01' AND A_DATE<= '2015-05-31'

#5


 like 条件是不走索引的.

#6


yangb0803 

那如果我不用like查詢呢, 但是條件的組合是不一定,根據用戶的輸入情況來,可能用其中的一兩個條件也可能全用。
這樣的話,我應該怎麼建索引,建幾個索引?
查詢條件 可以 有:
[PIA_OWNER] 个人账号, 精確查詢
[O_ACCOUNT] 所属账号, 精確查詢
[O_NAME]  所属名称 , 精確查詢
[P_NAME] 項目名称, 精確查詢
[A_DATE] 发生日期,范围查詢

#7


账号 不应该模糊查询吧??

如果条件组合不一定,那写个存储过程(或者在应用程序中),对每个传递过来的参数判断,有就拼接到查询中。

#8


要根据查询语句来建索引

#9


@xiaoxiangqing  怎能按照查詢語句來建呢 
查詢語句的 where 條件組合不一定,是用戶操作來定的。但是索引是要提前建好的啊 

#10


模糊查询 索引是没用的

#11


@yooq_csdn  那就取消模糊查詢呢
該怎樣建索引?

#12


建议 1
[O_NAME]  所属名称 ,精確查詢
[P_NAME] 項目名称,精確查詢
还是模糊查询,慢就满吧。
其他的精确查询
建议2 
百万就满了估计服务器配置不咋样,如果针对每个精确查询都单独做索引硬盘开销太大,我觉得布置得。
根据之前情况判断一下这几个选项选择的概率(或者直接找常用的人调查一下),做成聚集索引。
建议3
我们搞技术的人,总是想找到完美的解决方案在解决问题,可是完美不是那么容易做到的。记住“解决一点是一点,持续改进”

#13


按日期分区,见分区表,
LIKE做单向匹配,例如 PIA_OWNER like @PIA_OWNER+‘%‘  and  P_NAME like @P_NAME+’%'
迁移历史数据。

#14


@hery2002  
謝謝hery2002 。
按日期建分區表的確是個好建議。
ps:我覺得索引挺奇怪得,以下两个索引,用非聚集索引比聚集索引速度更快。

--非聚集索引
CREATE NONCLUSTERED INDEX IX_1
ON TRACK_LOG (A_DATE)
INCLUDE (O_ACCOUNT, O_NAME,P_NAME, PIA_OWNER);
GO
--聚集索引
CREATE  CLUSTERED INDEX IX_2
ON TRACK_LOG (A_DATE)
 GO
--查询SQL
select    A_DATE,O_ACCOUNT, O_NAME,P_NAME, PIA_OWNER  from TRACK_LOG where A_DATE>'2015-5-25'

#15


因为聚集索引的和非聚集索引的存储方式不一样,所以扫描方式不一样。B-Tree扫描次数更少。

推荐阅读
author-avatar
曾让我心碎的你俺_275
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有