表結構:
NUMREPORTREALSENDGUID NUMBER not null,
NUMMMSID NUMBER(15),
VC2SERVICECODE VARCHAR2(24),
VC2CAMPAIGNID VARCHAR2(24),
VC2CALLEDNUM VARCHAR2(64),
DATCREATE DATE,
VC2REPORTSTATUS VARCHAR2(1),
VC2STATUS VARCHAR2(1),
VC2USERID VARCHAR2(128)
SQL：
select
vc2servicecode,vc2campaignid,datcreate,vc2reportstatus,vc2status
from imms_report_realsend
where datcreate between YYYY-MM-DD and yyyy-mm-dd
and vc2userid=?
order by datcreate
目前數據庫里已有1000多萬筆數據。查一下其中的200W大概需要2分鐘，太長
了。（不知道是不是分頁有問題，用的是extremetable）
最終數據量可能會有5400W
1.表分区(問題: 如果建表分區的話只能按日期建,每月一個分區，但是如果
做跨月查詢的話，速度會不會提升? 還是更可能還會變慢？)
2.索引 已經在DATCREATE上建了索引(datcreate有order by操作)，但是效果
并不明顯!
請做過這樣的大數據量查詢的XDJM指教一下！
謝謝！
------解决方案--------------------
分区,索引都是有必要的.还有适当调整相关参数.
我现在的数据库,超个3亿条记录(大小40G左右)的大表有三个,主要索引用得当没感觉出有太慢的.
------解决方案--------------------
索引,分区表都有了,数据量这么大查询需要2分钟我觉得是在正常范围内
------解决方案--------------------
200W的数据select出来,想在1分钟以内查询出来,那也只能提高服务器的硬件配置了
------解决方案--------------------
------解决方案--------------------
study
------解决方案--------------------
太大没用过,索引还是索引!!!
------解决方案--------------------
你可以看看执行计划才知道查询时有没有用到索引
------解决方案--------------------
可以适当的建立视图（如物化视图），提高检索效率
------解决方案--------------------
1000W， 查200W, 有20%的数据了，建了索引估计也用不上的。
分区对这个情况的查询，也应该没什么大的改善。
从应用着手，少查点数据
------解决方案--------------------
一下查出来200w数据，怎么看，是不是需求有问题阿？
建分区，然后在分区上建立local索引，再看下select的速度，看响应速度
------解决方案--------------------
帮顶
------解决方案--------------------
这个问题需要考虑并行，充分利用多CPU的优势，仅仅分区并不能很大的提高速度。
------解决方案--------------------
学习中～～～
------解决方案--------------------
学习中了~~
------解决方案--------------------
学习中了~~
------解决方案--------------------
感觉速度差不多了修改下select 语句 看是否可以把条件简化
看否把datcreate 改成 smalldate
use +--数据库名
select * from +--表名
where (datcreate between YYYY-MM-DD and yyyy-mm-dd )
and (vc2userid=? )
order by datcreate
GO
------解决方案--------------------
------解决方案--------------------
普通用户需要一次取这么多数据？没有实际意义