做大流量访问级别的web应用开发的项目的时候，我们不得不经常要对应用中的各项功能不断的进行检测，优化以防止应用在关键时刻挂掉。下面作者就如何定位，排除以及避免MySQL数据库性能问题上面发表一些看法。期望能够帮助到同行们能够打造更坚固，更稳定的web应用。
（1）设计表时尽量使用 innodb数据库引擎
建表时,显式指定使用innodb数据库引擎，而不是myisam引擎，myisam引擎的锁是表锁,读锁和写锁是互斥的，读写操作是串行的，锁冲突会严重影响并发.而innodb提供行级锁，能提供较好的并发表现，在我们的业务场景里，也不会引起死锁。
（2）善用数据库索引
对SQL语句中where条件里使用到的字段，合理建立索引。虽然对表建立索引一定程度上会影响写入效率，但在表数据规模不大，写入压力不是特别高的情况下，索引带来的好处是更多的。
（3）合理的分库分表
对数据应合理分库分表，由应用层去动态的选择库和表。MySQL 的 innodb 引擎表虽然理论上可以存储海量的数据，但在我们的业务场景下，数据控制在500w以下会比较合理，追求性能的话，最好控制在200w以下，合理索引。
（4）合理使用缓存
将不常修改的，数据量有限的,又是被密集查询的信息，加载到 cache 里，可以有效的降低数据库压力。在一般的业务场景里，推荐使用开源 memcache，简单而且高效。
（5）善用 explain 命令
项目开发完后，应经常使用 explain 命令检查SQL语句，看是否使用到索引，是否存在 filesort 问题（即没有将 order by 列 设置为索引）,以及检查数据检索的行数（rows）是否太大。一般情况下，rows<1000，是在可接受的范围内的。rows在1000~1w之间，在密集并发访问的情况下可能会导致性能问题，但如果不是太频繁的访问（频率低于1分钟一 次），又难再优化的话，可以接受，但需要注意观察rows大于1万时，应慎重考虑SQL的设计，优化SQL，优化db，一般来说不允许频繁运行（频率低于1小时一次）。rows达到10w级别时，坚决不能做为实时运行的SQL。但导数据场合除外，但导数据必须控制好时间， 频度。
explain SQL语句应该是日常开发中的习惯动作，有时explain出来的结果，可能会出于偏离设计的意料之外,所以强烈建议在设计SQL语句时，尤其是稍微复杂的SQL时，一定要在测试环境甚至是实际环境上预先进行 explain 检测。
（6）开启 MySQL 慢查询日志
一般应打开MySQL的慢查询日志(在my.cnf中加入log_slow_queries和long_query_time两个参数),会记录所有查询持续时间超过long_query_time的SQL语句，把这些语句log下来之后，再一一运行 explain 命令进行分析优化。
（7）监视MySQL数据库进程列表
登陆MySQL客户端,使用show processlist查看当前正在运行的SQL语句，如果正在运行的语句太多，且运行时间太长的话，表示MySQL效率有问题。必要的时候可以将对应的进程kill掉。
（8）监视MySQL所占用的系统进程
使用 top，vmstat 等系统命令来检查MySQL进程占用的cpu,内存,以及磁盘IO量来对数据库进行进一步优化。