百万级大数据查询慢

[tongchou]

会员表 : id int ,企业名称 varchar,

产品表: ID ,产品名称,分类1,分类2,分类3 ,会员表ID
________________________________________
服务器配置: win2003 sql2000 至强8核 内存8G 网站就是B2B网站
-----------------------------------------------------------------------
数据有200多万,然后按分类3的ID 查询需要44秒
脚本

Select Top 16 a.id,a.id,a.cpmc,b.qymc as gsmc,a.cpsb,a.cpbh,a.cpcd,a.cpgg,a.cpjg,a.jysm,a.picture FROM dbo.productshow a left join corporation b on a.gsid=b.id Where 1=1 and a.typeid='55521615' And a.id Not In (Select Top 0 a.id FROM dbo.productshow a left join corporation b on a.gsid=b.id Where 1=1 and a.typeid='55521615' Order By a.id desc , a.idate desc )Order By a.id desc , a.idate desc 

也可用存储过程,麻烦那位提供下

[Tiger_Zhao]

将 NOT IN 改用 NOT EXISTS

[發糞塗牆]

CREATE INDEX IX_productshow ON productshow(gsid,typeid)	
CREATE INDEX IX_productshow_Date ON productshow(idate)

先执行这两个索引，再看看性能，2000有点麻烦，可能需要建多一点索引来覆盖查询

[tongchou]

已经执行了 ....

[發糞塗牆]

效果呢？引用一下我的回复，我都不知道你回答谁的。。

[tongchou]

引用 13 楼 DBA_Huangzj 的回复:

效果呢？引用一下我的回复，我都不知道你回答谁的。。

查询时间 18秒

[發糞塗牆]

再加两个，不过你看看里面的列，如果是那些varchar/nvarhcar/char/varchar 并且长度很长的，就先去掉吧

CREATE INDEX IX_productshow_Query ON productshow(cpmc,cpsb,cpbh,cpcd,cpgg,cpjg,jysm,picture)	
CREATE INDEX IX_corporation ON corporation(qymc)

[tongchou]

引用 15 楼 DBA_Huangzj 的回复:

再加两个，不过你看看里面的列，如果是那些varchar/nvarhcar/char/varchar 并且长度很长的，就先去掉吧

CREATE INDEX IX_productshow_Query ON productshow(cpmc,cpsb,cpbh,cpcd,cpgg,cpjg,jysm,picture)	
CREATE INDEX IX_corporation ON corporation(qymc)

==================== 执行执行0秒,正常了.如果多用户同时查询是否会增加查询时间?

[發糞塗牆]

我不清楚你的表结构、数据情况还有其他应用，所以不敢保证不会增加时间，但是如果索引算是合理的话，即使增加也不会很多

[tongchou]

引用 17 楼 DBA_Huangzj 的回复:

我不清楚你的表结构、数据情况还有其他应用，所以不敢保证不会增加时间，但是如果索引算是合理的话，即使增加也不会很多

你觉得用存储过程是否可以提高效率点,能否下个简单的存储过程给我呢 执行执行0秒,正常了.如果多用户同时查询是否会增加查询时间?

[發糞塗牆]

CREATE PROC test ( @typeid VARCHAR(10)--这里的数据类型建议和a.typeid 的类型一模一样，避免隐式转换 ) AS SELECT TOP 16 a.id , a.cpmc , b.qymc AS gsmc , a.cpsb , a.cpbh , a.cpcd , a.cpgg , a.cpjg , a.jysm , a.picture FROM dbo.productshow a LEFT JOIN corporation b ON a.gsid = b.id WHERE a.typeid =@typeid ORDER BY a.id DESC , a.idate DESC go

[發糞塗牆]

纯查询，问题不大，但是还有用户在修改数据的时候，那么响应时间就可能很久

[tongchou]

引用 20 楼 DBA_Huangzj 的回复:

纯查询，问题不大，但是还有用户在修改数据的时候，那么响应时间就可能很久

那如何避免这个问题呢?

[發糞塗牆]

暴力一点就用 select xxx from 表 with (nolock) 但是除非是一些静态系统，否则我个人不建议使用，更重要是改进设计，这部分涉及面太广，我没什么可以说的了

[發糞塗牆]

设计的东西，要懂业务、要懂技术，也要有足够的经验，不是三言两语或者看完一两本书可以做到的

[tongchou]

锁定表不可取

[tongchou]

非常感谢你的耐心解答.

[發糞塗牆]

引用 24 楼 tongchou 的回复:

锁定表不可取

nolock是不锁表。。。不是锁表。。

[shuiyuanguanshui]

Not In 里面的东西很奇怪，和外面的查询一直。 而且用了top 0 那不是恒成立吗？ 另外not in换成 not exists应该会好点吧。可以试试。 里面既然是判断为何要加上排序？没什么用处吧 然后就是查询和排序字段添加索引

[「已注销」]

针对大数据库性能优化，个人提点建议（仅代表本来观点）： 1.索引优化，为查询字段建立索引，不过占用内存大 2.尽量使用存储过程来调用，效率要高 3.使用预处理语句执行效率是否会更快？ 比如stmt 预处理语句 4.对于大数据容量的表，建议数据分表存储(水平拆分与垂直拆分)，表容量达到一定数据后动态扩充表

[「已注销」]

再就是写查询语句的时候，尽量缩小查询范围