案例分析总结连载：第三章

案例分析总结

 

第2章结尾我提到了一次重大的系统事故中，“PAT树”初露锋芒。整理思绪，对引起此次事故的起因——不合理的数据库基础设计，我在下文进行了回顾。

2010年4月28日 笔记整理                                地点：上海外滩 

在黄浦江畔的观景走廊上，我和小白正聊着刚发出来的系统性能优化报告。“这次性能调试的问题真不少，包括costly SQL被挖出来，表设计的漏洞也表明当初他们在逻辑设计时，业务支持的力度不够。”我说，“你看，数据既然以页为单位存储，如果字符串太大，一页就放不下了。业务量不大时，可能看不出来，一旦业务量激增，多程序并发处理，这种页很快就会被填满，当插入或更新数据时，就会发生溢出。这就当然会影响其他SQL语句以及整体的性能。”

“那该怎么办呢？”小白一头雾水。

我接着说，“这个业务的数据量太大，每天都有类似的大量信息存入。为了方便管理并提高查询性能，现在以月为单位间隔，建立分区表，根据实际的SQL情况选择MDC，目前看来，效果不错。这个系统的表设计还有其他隐患，比如太注重规范化，所有的设计完全按照第三范式进行，导致系统中出现了大量小表，访问数据时要进行大量的连接操作，影响性能。你知道的，连接操作可能会消耗大量的资源和时间。”

“还有，由于他们业务的灵活性，很多时候，需要对表结构进行修改。比如给业务增加一个特性，需要修改几十张表，这样操作的风险很大。这种情况非常适合使用XML来进行，将关系设计的复杂性全都交给XML来负责，每次修改只需要改动schema，整个表设计就不会受到影响。”

“原来如此啊”，小白又问道：“那为什么前几天你又带去两个DBA忙活了一阵子？”

“事故之后的三天，我仔细分析了现场的记录，感觉这个数据库在设计时考虑很不周全，里面还有隐患，只是还未暴露。”我找了把藤椅挨着太阳桌坐下来，接着说，“你还记得吗？ 从监控数据中分析出的那几张大表，操作那么频繁，我有个想法做分区，可是上面光索引就十几个，你说那晚还来得及吗？这表分区本是在设计阶段就要把性能因素考虑进去的。后来又查了查数据库配置，发现表空间和I/O存储也有问题，这也是个定时炸弹哪。”我说得口干舌燥，从太阳桌上拿起杯子呷了一口Burgundy，视线落在江面的游轮上。

    其实这个问题两三句话不太容易说清楚。回到酒店，我给大家发封信，记录了解决方法。在下一章的“案例分析总结”中，我们就会看到物理设计的缺陷造成的隐患是如何解决的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25714482/viewspace-700374/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25714482/viewspace-700374/