22,302
社区成员
发帖
与我相关
我的任务
分享数据库越来越大，越来越慢
不到一年，数据库容量已经到6G了，查询速度越来越慢，
到底怎样设计好，能不能设计成这样，超过一年的时候自动换一个文件保存，查询的时候可以指定日期，
例：
2011的数据保存到 2011文件里
2012的时候自动换到2012文件里
查询的时候可以指定文件，比如我想查2011年的数据，可以直接在2011文件里查，这样速度就好一些
到底怎样设计好，能不能设计成这样，超过一年的时候自动换一个文件保存，查询的时候可以指定日期，
例：
2011的数据保存到 2011文件里
2012的时候自动换到2012文件里
查询的时候可以指定文件，比如我想查2011年的数据，可以直接在2011文件里查，这样速度就好一些
...全文
请发表友善的回复…
发表回复
hjd2357 2012-08-16
- 打赏
- 举报
meerio 2012-08-09
- 打赏
- 举报
[Quote=引用 15 楼 的回复:]
一年是6G 2年呢，3呢，所有必须找到解决办法de
[/Quote]
我见过一数据库SQL 2000，数据库60G(8年数据)，感觉速度也很快，主要还是数据库优化方面多下点功夫
一年是6G 2年呢，3呢，所有必须找到解决办法de
[/Quote]
我见过一数据库SQL 2000，数据库60G(8年数据)，感觉速度也很快，主要还是数据库优化方面多下点功夫
xiaoxiangqing 2012-08-09
- 打赏
- 举报
1.升级硬件
2.优化SQL
2.优化SQL
hjd2357 2012-08-09
- 打赏
- 举报
大家的意见都很好
.NET快速开发框架 2012-08-07
- 打赏
- 举报
建议进行表分区处理，建立相关索引。整理索引碎片，优化程序。
哥只是一个传说 2012-08-07
- 打赏
- 举报
压缩成文件,移到别的硬盘备用...;.
ccc_0048 2012-08-07
- 打赏
- 举报
6G不算大，应该是数据表设计问题。分年保存也一种办法；分区处理你的数据又太小了。
lwglucky 2012-08-06
- 打赏
- 举报
sql server 有查询分析器。。。学着用一下分析以下情况
KevinLiu 2012-08-04
- 打赏
- 举报
先看看到底慢在哪里再来调优
luckings 2012-08-03
- 打赏
- 举报
可以先把数据库版本升级到2008，效率会有一定的提升。
对于你这个库来说，6g并不大，你可以分析下，究竟是那块或者哪个表慢，慢问题细化，如果是某一个表数据量
特别大，可以按照年尽力表，这种需要对应用做修改，也可以对表做分区（按照月或者年来进行），这样查询速
度就大大提高，不需要修改应用。还有你业务允许，可以把一段时间以前的历史数据转移到备库，查历史数据就
到备库查询。另外时间长了要对索引进行重建，整理表碎片
对于你这个库来说，6g并不大，你可以分析下，究竟是那块或者哪个表慢，慢问题细化，如果是某一个表数据量
特别大，可以按照年尽力表，这种需要对应用做修改，也可以对表做分区（按照月或者年来进行），这样查询速
度就大大提高，不需要修改应用。还有你业务允许，可以把一段时间以前的历史数据转移到备库，查历史数据就
到备库查询。另外时间长了要对索引进行重建，整理表碎片
sql2015 2012-08-03
- 打赏
- 举报
不能光看数据库的大小，要看数据库表结构，关系，索引，记录行数等。
howesen 2012-08-03
- 打赏
- 举报
6G数据量只有我们一天的量，不过我们用的是ORACLE，大量单表1TB以上的数据量，经过优化，100人并发办公效率还是很快的。
菩提树下小沙弥 2012-08-03
- 打赏
- 举报
这个就是一个“分”字，分库/表/区。数据库级别的优化，抛开不谈。
数据文件，最好单独放一个物理硬盘，条件不允许也至少要单独分区（硬盘分区，非数据库）。盘符可以同一个，可以通过mklink或linkd之类命令，符号链接连到你要的盘。Windows的文件系统，作为服务器系统来说，是有天生缺陷的——太容易产生碎片。所以，为了避免碎片，尽量让数据独享一片空间，避免其他碎片插队影响对写速度。
当然，这个不是决定性的优化。最重要的，还是数据库设计本身的设计。
数据文件，最好单独放一个物理硬盘，条件不允许也至少要单独分区（硬盘分区，非数据库）。盘符可以同一个，可以通过mklink或linkd之类命令，符号链接连到你要的盘。Windows的文件系统，作为服务器系统来说，是有天生缺陷的——太容易产生碎片。所以，为了避免碎片，尽量让数据独享一片空间，避免其他碎片插队影响对写速度。
当然，这个不是决定性的优化。最重要的，还是数据库设计本身的设计。
huaxianz 2012-08-03
- 打赏
- 举报
6G is just a small baby. I got many tables (not db) bigger than 100G! It's very common in a OLAP enviroment.
shine333 2012-08-02
- 打赏
- 举报
这个就是一个“分”字，分库/表/区。数据库级别的优化，抛开不谈。
数据文件，最好单独放一个物理硬盘，条件不允许也至少要单独分区（硬盘分区，非数据库）。盘符可以同一个，可以通过mklink或linkd之类命令，符号链接连到你要的盘。Windows的文件系统，作为服务器系统来说，是有天生缺陷的——太容易产生碎片。所以，为了避免碎片，尽量让数据独享一片空间，避免其他碎片插队影响对写速度。
当然，这个不是决定性的优化。最重要的，还是数据库设计本身的设计。
数据文件，最好单独放一个物理硬盘，条件不允许也至少要单独分区（硬盘分区，非数据库）。盘符可以同一个，可以通过mklink或linkd之类命令，符号链接连到你要的盘。Windows的文件系统，作为服务器系统来说，是有天生缺陷的——太容易产生碎片。所以，为了避免碎片，尽量让数据独享一片空间，避免其他碎片插队影响对写速度。
当然，这个不是决定性的优化。最重要的，还是数据库设计本身的设计。
芦行者 2012-08-02
- 打赏
- 举报
6G挺小的，我这6T都不只
lyq79074765 2012-08-02
- 打赏
- 举报
升级到更高版本的sql吧 我开发库就已经40g了 一点都不慢,让你们DBA找找瓶颈在什么地方,只在网上说作用不大的,还要在现场看过才能知道
kimcom 2012-08-02
- 打赏
- 举报
添加硬盘，添加文件组。
有时候增长是因为日志增加太快，数据并没有多少增加的，这个时候，需要备份数据库，或者备份日志，就可以大大减小数据库的体积。
有时候增长是因为日志增加太快，数据并没有多少增加的，这个时候，需要备份数据库，或者备份日志，就可以大大减小数据库的体积。
吃饱饱吖 2012-08-02
- 打赏
- 举报
[Quote=引用 36 楼 的回复:]
引用 34 楼 的回复:
升级到更高版本的sql吧 我开发库就已经40g了 一点都不慢,让你们DBA找找瓶颈在什么地方,只在网上说作用不大的,还要在现场看过才能知道
支持
[/Quote]
支持
引用 34 楼 的回复:
升级到更高版本的sql吧 我开发库就已经40g了 一点都不慢,让你们DBA找找瓶颈在什么地方,只在网上说作用不大的,还要在现场看过才能知道
支持
[/Quote]
支持
q156375764 2012-08-02
- 打赏
- 举报
[Quote=引用 34 楼 的回复:]
升级到更高版本的sql吧 我开发库就已经40g了 一点都不慢,让你们DBA找找瓶颈在什么地方,只在网上说作用不大的,还要在现场看过才能知道
[/Quote]
支持
升级到更高版本的sql吧 我开发库就已经40g了 一点都不慢,让你们DBA找找瓶颈在什么地方,只在网上说作用不大的,还要在现场看过才能知道
[/Quote]
支持
加载更多回复（30）
