如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，而且将会影响系统实际运行的性能。所以，在一个系统开始实施之前，完备的数据库模型的设计是必须的。一般前期系统设计初衷，数据量较小只针对功能的实现，运行一段时间后，发现系统的性能在降低，然后在进行补丁的修复，理应前期就应该考虑到数据量大的时候。
一.性能分析
1、拿MySQL 自身瓶颈来
MySQL自身参见的性能问题有磁盘空间不足，磁盘I/O太大，服务器硬件性能低。
（1）CPU：CPU 在饱和的时候一般发生在数据装入内存或从磁盘上读取数据时候；
（2）IO：磁盘I/O 瓶颈发生在装入数据远大于内存容量的时候；
（3）服务器硬件的性能瓶颈：top,free,iostat 和 vmstat来查看系统的性能状态。
2、从程序员的角度
（1）查询语句写的不好；
（2）没建索引，索引建的不合理或索引失效；
（3）关联查询有太多的join；
（4）从服务器的角度；
（5）服务器磁盘空间不足；
（6）服务器调优配置参数设置不合理。
二.数据库结构设计
1、保证数据的一致性和完整性
在逻辑设计的时候往往会设计很多的表间关联，尽可能的降低数据冗余，但是对于多表之间的关联查询，尤其是大数据表，其性能将会降低，同时客户端的编程难度也随之提高，为了提高系统的响应时间，合理的数据冗余也是必要的，设计人员在系统设计阶段应根据系统操作的类型、频率加以均衡考虑。
集群：主从同步(日志)，读写分离，主备切换
2、查询的优化
在保证功能实现的前提下，尽量减少对数据库的访问次数。
3、海量数据的高效率读写
当表中数据量太大,每次的读写速率都将非常缓慢(解决方案:分表.分库)
1）分表：水平分割(行)和垂直分割（列）
（1）水平分表
表中数据量巨大时，我们要经常查询。则可以按照合适的策略拆分为多张小表。尽量在单张表中查询，减少扫描次数
（2）垂直分表
表记录数并不多，但是字段却很长，表占用空间很大，检索表时需要执行大量I/O，严重降低了性能。这个时候需要把大的字段拆分到另一个表，并且该表与原表是一对一的关系（外键）。 (JOIN)
2）分区：将数据分段划分在多个位置存放，可以是同一块磁盘也可以在不同的机器
MySQL 5.1 中新增了分区(Partition)功能，优势也越来越明显了：
（1）与单个磁盘或文件系统分区相比，可以存储更多的数据；
（2）很容易删除不用或者过时的数据；
（3）一些查询可以得到极大的优化可以并发查询；
（4）涉及到 SUM()/COUNT()等聚合函数时，可以并发进行；
（5）IO吞吐量更大。
三.数据库表设计