关于SQL数据库 数据量太大引起的性能有关问题

关于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,     --扫描 
 
       s.user_lookups,   --书签查找或键查找
       s.user_updates    --索引更新次数     
   
from sys.dm_db_index_usage_stats s
inner join sys.objects o
        on s.object_id = o.object_id

inner join sys.indexes i
        on i.index_id = s.index_id
           and i.object_id = s.object_id
           
where database_id= db_id()
      and o.name in ('报表中涉及到的表1','报表中涉及到的表2')

如果user_updates挺大，user_scans也很大，而其他的数很小，那么说明你的索引都没有用到，那就可能是索引有问题。

3.查看一下报表中引用到的表，是否碎片率太大。

dbcc showcontig('表',索引id)

如果碎片率太大，可用过下面的语句重建索引：

alter table 表
rebuild

[解决办法]
查询慢估计索引都不够优化甚至缺失
也许索引优化就能解决，也许索引优化+分区就能解决，前提是原有的应用程序不作修改。

[解决办法]
单位数据库帐套中的数量量太大

呃……是个财务系统……？
碰到过比较多的财务系统，MSSQL和MYSQL都有。
应该是索引建立不好的问题，而且软件启用时间距离现在的时间越远，性能就越差——因为那时候挺多小企业招人自主开发或者是破解版，功能不完善，索引优化不足。

把数据库整回家慢慢调试……

查看更多 下一篇