数据存储优化

大业务量数据存储


当系统中业务数据量较大时，避免业务变更的历史数据和正式的业务数据同时存储，
由于业务新增的数据及历史业务变更产生的数据，会到时存储表越来越庞大，而且历史数据会逐步增多，
一段时间后，历史数据往往会大于正式数据，而正式数据是要经常使用的，历史数据只会在个别查询时会用到，
庞大的数据存储会直接导致正式业务数据的查询性能及程序处理复杂度，同时，如果系统未来进行升级时，庞大的数据量会大大增大数据迁移割接的难度，增加数据迁移的时间；
建议将正式数据独立存储，业务修改后的历史数据采用日志存储或新建表进行存储，保证正式数据的查询处理效率。




不可变字符类型char和可变字符类型varchar 最大长度都是8000字节,char查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。
在设计字段的时候可以灵活选择，例如用户名、密码等长度变化不大的字段可以选择CHAR，对于评论等长度变化大的字段可以选择VARCHAR。


数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率.


能够用数字类型的字段尽量选择数字类型而不用字符串类型的（电话号码），这会降低查询和连接的性能，并会增加存储开销。
这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了


字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。

----------------------------------------------------------
历史数据存储


建立与正式业务表属性相同的历史记录表，同时采用定时程序或存储过程等方法将正式业务表的数据按过期规则迁移至历史记录表，在用户进行记录查询是分表查询，
一般用户比较关注近期的记录，这样直接查询正式业务表，数据量不是很大，保证的较高的查询响应效率，个别情况下用户会查询历史记录，系统会从历史记录表中查询；使用这样的方式可以保证大部分时间用户的查询效率


----------------------------
确定要执行一些异步处理，那么同步处理的任务就应该越少越好，将数据库密集的操作安排在稍后的异步处理中完成


大字段处理  
当业务表中包括用来存储附件、图片、大文本的大字段的数据类型时，在列表页面一般情况下不要获取大字段内容，如列表页面获取大字段，却不进行展现，
如数据量增大后，会大大影响页面展示速度，在查看页面加载大字段类型，可在对象实体类中增加一个钩子函数，只把基本属性传入，这样列表页面就不会获取到大字段，
当然，也可以通过Hibernate配置解决这个问题，hibernate2可以将BLOB字段与基本信息分离，生成两个PO，这样我们可以通过延迟加载特性以提高效率，字段单独拆分出来，
以提高数据库操作的性能。Hibernate3中对于POJO的属性提供了延迟加载, 只要设置属性的的lazy="true"，以后通过getXXX才能真正从数据库中读取数据，这样可以有效地提高我们读取部分表字段的性能