关于SQL数据库 数据量太大引起的性能问题
单位数据库帐套中的数量量太大了，数据文件有50G左右，部分业务表中的数量已达到2000W级别，最近导致操作比较慢(插入，查询)业务数据也不能直接删除，以后还要进行查询，请问有什么好的办法处理这种问题？
------解决方案--------------------
具体要看你的实际情况.
并发量大不?

你INSERT 是因为索引过多还是?聚集索引键没弄好?
查询的话跟踪看看..

如果业务逻辑不好处理,把历史数据转移.或者分区表看看.(2KW数据量并不算很大.)

------解决方案--------------------
算小偏大的DB吧。。如果有预算优化，欢迎联系我
------解决方案--------------------
慢的瓶颈在哪里？缺少索引？IO？CPU?内存？Blocking?先找到原因之后再对症下药，2000W的数据不算大的，可以优化的很好。 
------解决方案--------------------
2000W的数据表   索引这些应该也不少吧   插入的时候慢很正常了   查询的时候很慢的话其实是可以优化的

首先检查你的索引   是否查询的时候索引未被使用到   还有就是索引碎片是否过多  

此外  死锁  阻塞这些也可能会造成查询的时候很慢

至于是否是用分区表  我个人的想法是分区不如分表  你2000W的数据量  应该是算上历史数据吧   可否考虑把历史数据转移到另一张结构完全一样的表中   还有就是  可以把经常要查询的数据放到一个表中  不是经常用到的数据放到另外一个表中  
------解决方案--------------------
按#4楼的方法先检查。

不改变原来数据库设计结构，可以考虑分库，把历史数据放到另外一个数据库中，只保留最近三个月或者半年的业务数据。


如果光从索引角度考虑，可以参考：
<Indexing Rules of Thumb & Index Selection Decisions>
http://www.cnblogs.com/wghao/archive/2013/04/10/3013384.html


------解决方案--------------------

引用:

单位数据库帐套中的数量量太大了，数据文件有50G左右，部分业务表中的数量已达到2000W级别，最近导致操作比较慢(插入，查询)业务数据也不能直接删除，以后还要进行查询，请问有什么好的办法处理这种问题？

插入慢的事儿，上面都说的差不多了。 

就查询的事儿，建议lz，做一个复制，每天按照业务要求，比如半天做一次。大量的数据查询迁移到这个复制备份数据库上做。
前台业务继续在当前数据库执行。 也算是简单的业务查询分离吧.
------解决方案--------------------
楼主，看看我的文章。遇到跟你一样的问题。
查询慢通常是索引建的不正确，尽量少用表关联，我已经解决问题了。
http://blog.csdn.net/caoshangfei/article/details/8761301
------解决方案--------------------
外购的系统？
那很难做大的优化（如历史库和当前库分开）了
最多把表分区，增加索引。。。。按理说，他们应该更专业，这些都已经做好了才对
------解决方案--------------------
1、外购的系统也可以做很多优化或调整（已接手过好几单）
2、很多软件公司的开发质量很差，并且开发时数据可能就几十M，只要完成任务就成
3、历史库和当前库分开：在很多时候不可取，万一程序要访问到历史数据将如何？
------解决方案--------------------
2KW不算大，应该是长年累月的结果不可能一天吧~所以可以考虑表分区~~~另外有钱就整个那啥~SSD~
硬盘读取量大绝对支持~
------解决方案--------------------

引用:

单位数据库帐套中的数量量太大了，数据文件有50G左右，部分业务表中的数量已达到2000W级别，最近导致操作比较慢(插入，查询)业务数据也不能直接删除，以后还要进行查询，请问有什么好的办法处理这种问题？

2000w的数据量确实不小，

1.你可以更新一下统计信息：

update statistics 表名

2.另外，通过下面的视图，可以查看一下，你所建立的索引的使用情况：

select o.name as table_Name,

       i.name as index_name,

       

       s.user_seeks,     --索引查找

       s.user_scans,     --扫描