经验总结：SQL Server数据库对上亿表的 *** 作[2]

解决办法

针对一

避免大表 *** 作 所有的 *** 作均可以按省或者时间分开 这样无论从时间或者地域维度 基本上可以将大表拆成 张以上的小表 *** 作 甚至更多 然后再对结果进行合并 应该可以避免上述问题

针对二

无解决方案 只是建议将我们的数据库也单独分到一组磁盘上去 不要跟系统竞争

针对三

及时删除无用的临时数据 保障数据库空间 同时也可以做上空间监控 一旦数据文件空间发生增长时 给DBA一个预警邮件 我们收到邮件后可以立即做相应处理

针对四

日志文件目前已经涨得较大 我们执行一下截断日志的动作 将日志文件的空间使用保持在一个较低水平

lishixinzhi/Article/program/SQLServer/201311/22405

单表一亿？还是全库1亿？

1.首先可以考虑业务层面优化，即垂直分表。

垂直分表就是把一个数据量很大的表,可以按某个字段的属性或使用频繁程度分类,拆分为多个表。

如有多种业务类型，每种业务类型入不同的表，table1,table2,table3.

如果日常业务不需要使用所有数据，可以按时间分表，比如说月表。每个表只存一个月记录。

2.架构上的优化，即水平分表。

水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里，这里不具备业务意义。

如按照id分表，末尾是0-9的数据分别插入到10个表里面。

可能你要问，这样看起来和刚才说的垂直分表没什么区别。只不过是否具备业务意义的差异，都是按字段的值来分表。

实际上，水平分表现在最流行的实现方式，是通过水平分库来实现的。即刚才所说的10个表，分布在10个mysql数据库上。这样可以通过多个低配置主机整合起来，实现高性能。

最常见的解决方案是cobar，这个帖子介绍的比较完善，可以看看。

http://blog.csdn.net/shagoo/article/details/8191346

cobar的逻辑层次图：

不过这种分库方式也是有一定局限性的，需要应用程序做相应的配合，比如说分库的情况下，虽然可以实现跨库查询，但是不能进行相关的group by计算。

另外，之前关于水平分表的实现方式，也可以通过表分区来实现。

mysql优化的方式有很多，选择上主要还是要考虑个人的实际情况，如代码不可控的情况下，就不适合选择按字段属性分表的情况，这样可能会带来大量的重构以及很多不可预期的风险。

而架构的优化，虽然对应用是透明的，但对sql的写法有很多局限性，比如说不能使用聚合函数等等，同时也需要有充足的硬件资源，只有一台服务器的情况下是没有意义的。

相比起来，代价最低的是按时间分表或分区，这两种办法对应用来说都是透明的。

分区只需要一次本地数据迁移的 *** 作。

而通过分表把现网数据和历史数据分离，唯一的代价是定期的数据维护。

一般如果表里面有1亿数据的情况下，索引的问题应该是常识了，这方面我就不说了。

---