大数据量下的数据库查询与插入如何优化？ （整理）

数据库经常要做一些查询与插入，但是如果查询和插入的数据量过大的时候就会引发数据库性能问题，降低数据库工作效率。因此性能调优是大家在工作中都能够预见的问题，大到世界五百强的核心系统，小到超市的库存系统，几乎都会有要调优的时候。面对形形色色的系统，林林总总的需求，调优的手段也是丰富多彩。

1.尽量使语句符合查询优化器的规则避免全表扫描而使用索引查询
2.避免频繁创建和删除临时表，以减少系统表资源的消耗。
3.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
4.建立高效的索引

SQL语句的Select部分只写必要的列；尽量将In子查询重写为Exists子查询；
去除在谓词列上编写的任何数学运算；尽可能不用Distinct；
由于优化工具处理“或”逻辑可能有问题，所以尽量采用其他方式重写；
确保所处理的表中数据分布和其他统计信息正确，并反映当前状况；尽可能用UNION ALL取代UNION；
尽可能减少DB2的SQL请求；尽量将区间谓词重写为Between谓词；不要只是为了排序而选择某一列；

我目前所在的系统就是这么一个有实时插入又需要大数据的查询的一个系统。
采用了如下手段：
1，当天的记录会放在一个独立的表中.主要是针对实时的插入的记录，记录不要太多以免插入的时候维护索引的开销稳定在一个范围内。
2，历史的记录会按天分区的形式保存在历史表中。这个表一天只会批量的插入一次数据(用的是分区交换的方法)。
3，分区的索引对我的业务性能不好，因为要跨天 查询。历史查询最长时间段是一个月的时间，如果按照一个月一个分区的话，一个分区差不多是一个亿的记录，
就算是按月分区的话，再创建分区的本地索引，如果是时间段跨了月份的话估计分区的本地索引性能估计也不行。
4，后来采用一个方案，DB层上面再放了一个缓冲层，就是我最近在测试的Timesten关系型内存数据库，按照时间的老化策略缓冲一个月的数据。具体不展开说了。涉及的内容很多。

只是对于这个系统，我总结一下有以下需要注意的地方:
1,对于一个系统来说，如果查询性能反应不好的话，第一个调整的地方是思考业务的需求是否是合理的？
一个查询既要分页获取前面一页或者几页的数据，又要根据条件获取总的记录数，如果符合的记录总数是上亿条的话，感觉就是一个不合理的要求。
2，市场需求调研人员业务水平根本不合格。
3，前台开发人员写的SQL差，根本没有调优的基本概念,术业有专攻啊。
4，如果业务需求合理，SQL的调整无非是从执行计划开始，如果是ORACLE10g,开了cbo，可以用 SQL优化器 (SQL Tuning Advisor :STA)
分析你的sql。
5，最近的nosq和海量分布式的数据库概念很热。公司也在考虑HBASE了。

分区，
读写分离。

细节的优化手段大家都说了很多，我说些几个粗略的方面：
1.使用分区表
2.并行查询
3.定期的数据信息采集
4.可以考虑使用sql hint（生产库上我个人认为还是少指定 HINT，可以考虑用 SQL_PROFILE固定执行计划）

1 数据量上亿时我都会使用分区，具体的分区方案看业务需求，如果查询数据是按时间来的且时间跨度小，那么我会按天分
2 读写分离，说实话这个对我来说只是理想方案࿰