当客户数据量极大时如何设计表

一个简单的SQL语句：select count(1) from tableName with(nolock) where columnA=A and columnB=B and columnC=C，被一个关键页面调用，虽然加了Memcache缓存，但由于数据结构设计问题，造成了数据库服务器CPU负载高达100%，关键页面响应超时，造成极其不好的影响。

      究其原因，缺少索引，数据结构设计之初，没有为该表建立索引，而后又忽略了该表仅测试数据就达到五六百万级别，以每天25万左右的速度增长。测试时，由于没有访问量，性能问题没被发现；而上线前的压力测试，由于测试帐号只有有限的几个，而系统根据帐号增加了Memcache缓存，因此该问题又被忽略了；直到系统上线第二天，真实的用户访问量上来了，该问题才暴露无遗，客服电话很快被打爆。

      为了彻底解决该问题，花费了几个工作日，血淋淋的教训。如果开发之前设计好数据结构建好索引、如果开发测试的时候关注下数据量、如果把写好的SQL语句放到查询分析器分析下性能...做设计写程序，意识不能少，开发前的设计要做到位，开发流程要把握好，否则发生杯具只能自己埋单了。

上文摘自http://www.cnblogs.com/freshman0216/archive/2010/11/02/1866788.html

 

这里结合自己最近的工作说明一下自己的体会。

正如上文所言。在数据库设计之初建表之时的前提对业务流进行了很好的理解规划，然后进行数据库设计。

在需求的基础上利用面向对象的概念和面向接口的概念提炼出相应的属性对应的表及其字段。

其实对于这个阶段把数据库设计好后应该在结合第一阶段的业务利用TDD思考

这个表的这个字段真的这么有必要吗？这个表是不是应该预留出一到2个字段以备扩展用

这个表在整个业务中使用是否频繁，频繁的话是否应该进行加锁控制，或者说在读取上效率如何保证

主键是否真的有必要，索引是否建立的及时和到位。因为开发人员或者说测试人员尤其是对于我们的公司而言能够造就100条数据就不错了。但是客户呢 有没有换位思考呢？