一般数据库优化分sql语句优化和数据库服务器参数优化，数据库服务器参数优化是DBA可以独立完成的，但是sql语句优化就必须和开发人员协同完成。
现在我们先不谈优化的实施，我们先研究下如何优化，优化哪里，我们要找准数据库性能的瓶颈，有的放矢，这样才能让优化立竿见影。
如何找到mysql数据库得瓶颈呢？如何提前发现mysql数据库可能出现的瓶颈呢？这里又分两大方面。
一方面是架构的设计和业务的类型，另一方面是通过观察mysql数据库的状态，好似中医的望闻问切。
现在我们先不谈优化的实施，我们先研究下如何优化，优化哪里，我们要找准数据库性能的瓶颈，有的放矢，这样才能让优化立竿见影。
如何找到mysql数据库得瓶颈呢？如何提前发现mysql数据库可能出现的瓶颈呢？这里又分两大方面。
一方面是架构的设计和业务的类型，另一方面是通过观察mysql数据库的状态，好似中医的望闻问切。
关于第一个大的方面，需要注意的是。在业务前期，一定要确定业务的类型，是OLAP系统还是OLTP系统，数据量到底有多大，并发量到底有多大，查询居多，还是修改插入居多，需不需要支持事务和外键约束等信息。
因为这些信息可以帮助我们在设计数据库架构，选取数据库引擎的时候有很大帮助。还有就是硬件层面的需求，到底多大业务，需要多少的硬件资源，硬件支援才压力承受范围内，可以得到很好的性能，如果超过了压力承受范围，那么性能会下降的很厉害，并且硬件的各个组成部分要匹配，不要出现某个部分太差，原因大家都应该知道的。
因为这些信息可以帮助我们在设计数据库架构，选取数据库引擎的时候有很大帮助。还有就是硬件层面的需求，到底多大业务，需要多少的硬件资源，硬件支援才压力承受范围内，可以得到很好的性能，如果超过了压力承受范围，那么性能会下降的很厉害，并且硬件的各个组成部分要匹配，不要出现某个部分太差，原因大家都应该知道的。
下面举两个简单的案例
案例一、一个公司的数据库出现这样一个问题，一个myisam引擎的表，只有几百行的数据，但是table.myd文件却占了数十个G的空间，每次操作这个表的时候，速度就奇慢。
通过explain查看，又是正常的，这个问题在很多数据库上都存在，用oracle的话来说，就是高水位和块回收的问题。如果找到原因 optimize table tablename，优化一下表就可以了。
由于那个表操作很频繁，需要经常优化，这样就增加了DBA或者运维的工作量，这种问题其实在当初设计的时候，选用memcache引擎就比较合适，但是web应用的话还是比较适合memcached。
案例一、一个公司的数据库出现这样一个问题，一个myisam引擎的表，只有几百行的数据，但是table.myd文件却占了数十个G的空间，每次操作这个表的时候，速度就奇慢。
通过explain查看，又是正常的，这个问题在很多数据库上都存在，用oracle的话来说，就是高水位和块回收的问题。如果找到原因 optimize table tablename，优化一下表就可以了。
由于那个表操作很频繁，需要经常优化，这样就增加了DBA或者运维的工作量，这种问题其实在当初设计的时候，选用memcache引擎就比较合适，但是web应用的话还是比较适合memcached。
案例二、一个考试系统，当考试完成的时候，大家一交卷，服务器垮掉了，这是为什么呢？
因为大家都想要同时往一个表里写数据，但是等待表锁很严重，最后服务器挂掉了，所有数据未保存，这种情况在业务设计之初，就应该考虑到，使用innodb引擎，就可以解决这个问题。
应为innodb引擎室行锁对这种大并发的写入操作承受力很强。现在的考试系统已经比较完善，大部分是边做题，边提交数据库，就算这样，innodb引擎在这种应用还是很有优势的。
因为大家都想要同时往一个表里写数据，但是等待表锁很严重，最后服务器挂掉了，所有数据未保存，这种情况在业务设计之初，就应该考虑到，使用innodb引擎，就可以解决这个问题。
应为innodb引擎室行锁对这种大并发的写入操作承受力很强。现在的考试系统已经比较完善，大部分是边做题，边提交数据库，就算这样，innodb引擎在这种应用还是很有优势的。
这些情况都还好，能够修复，不会对业务造成的影响一般，如果一个架构前期没有设计好，等到开发完成，投入使用了，发现有问题，再返回修改，修改量和测试的工作量是相当庞大的，结果就是浪费资金，浪费时间。
本文转自 fenghao.cn 51CTO博客，原文链接：http://blog.51cto.com/linuxguest/455251，如需转载请自行联系原作者
