大数据量高并发的数据库优化 - [技术研究 ]
2009 年 03 月 17 日
一、数据库结构的设计
如果不能设计一个合理的数据库模型, 不仅会增加客户端和服务器段程序的编程和维护
的难度,而且将会影响系统实际运行的性能。 所以,在一个系统开始实施之前,完备的数据
库模型的设计是必须的。
在一个系统分析、设计阶段,因为数据量较小,负荷较低。我们往往只注意到功能的实
现,而很难注意到性能的薄弱之处, 等到系统投入实际运行一段时间后, 才发现系统的性能
在降低, 这时再来考虑提高系统性能则要花费更多的人力物力, 而整个系统也不可避免的形
成了一个打补丁工程。
所以在考虑整个系统的流程的时候, 我们必须要考虑, 在高并发大数据量的访问情况下,
我们的系统会不会出现极端的情况。 (例如: 对外统计系统在 7 月 16 日出现的数据异常的情
况,并发大数据量的的访问造成, 数据库的响应时间不能跟上数据刷新的速度造成。 具体情
况是:在日期临界时( 00:00:00),判断数据库中是否有当前日期的记录,没有则插入一
条当前日期的记录。 在低并发访问的情况下, 不会发生问题, 但是当日期临界时的访问量相
当大的时候, 在做这一判断的时候, 会出现多次条件成立, 则数据库里会被插入多条当前日
期的记录, 从而造成数据错误。 ),数据库的模型确定下来之后, 我们有必要做一个系统内数
据流向图,分析可能出现的瓶颈。
为了保证数据库的一致性和完整性, 在逻辑设计的时候往往会设计过多的表间关联, 尽
可能的降低数据的冗余。 (例如用户表的地区,我们可以把地区另外存放到一个地区表中)
如果数据冗余低, 数据的完整性容易得到保证, 提高了数据吞吐速度, 保证了数据的完整性,
清楚地表达数据元素之间的关系。而对于多表之间的关联查询 (尤其是大数据表) 时,其性
能将会降低,同时也提高了客户端程序的编程难度,因此,物理设计需折衷考虑, 根据业务
规则, 确定对关联表的数据量大小、 数据项的访问频度, 对此类数据表频繁的关联查询应适
当提高数据冗余设计但增加了表间连接查询的操作, 也使得程序的变得复杂, 为了提高系统
的响应时间, 合理的数据冗余也是必要的。 设计人员在设计阶段应根据系统操作的类型、 频
度加以均衡考虑。
另外,最好不要用自增属性字段作为主键与子表关联。不便于系统的迁移和数据恢复。
对外统计系统映射关系丢失( ****************** )。
原来的表格必须可以通过由它分离出去的表格重新构建。 使用这个规定的好处是, 你可
以确保不会在分离的表格中引入多余的列, 所有你创建的表格结构都与它们的实际需要一样
大。应用这条规定是一个好习惯, 不过除非你要处理一个非常大型的数据, 否则你将不需要
用到它。(例如一个通行证系统,我可以将 USERID ,USERNAME ,USERPASSWORD ,单
独出来作个表,再把 USERID 作为其他表的外键)
表的设计具体注意的问题:
1、数据行的长度不要超过 8020 字节, 如果超过这个长度的话在物理页中这条数据会占
用两行从而造成存储碎片,降低查询效率。