找到 MySQL 的瓶颈_MySQL
瓶颈
对于项目的最终瓶颈是什么，我想大多数程序员已经达成了共识，是数据库。
不论你使用哪种数据库，问题似乎最终都会回到这里。
首先，我们来分析一下导致瓶颈的主要原因：
- 查询次数太多；
- 返回的结果集太大；
- 查询太复杂；
- 数据更新表锁，导致查询堵塞；
- 软硬件环境限制，如最大连接数限制、IO限制、硬件资源限制；
针对这些问题，又有那些应对方法呢？
- 减少和合并查询；
- 减少查询字段，使用 LIMIT 拆分为多次查询；
- 简化和拆分查询，优化索引；
- 优化数据库软件配置；
- 分布和缓存；
表结构
数据库表的结构，不仅仅能够决定数据表所占用的空间，对查询效率有着显著的影响。
选择精确合理的字段类型
选择合适的字段类型，是表设计的最基本要求。合适的类型，不仅能够减少表占用的空间，而且能增加查询效率。
举个例子，存储时间（0000-00-00 00:00:00），你会使用 Char(19) 还是 DATETIME 呢？
你应该并必须选择后者，因为 DATETIME 在 MySQL 中几乎等同于数字，可以方便的运算、比较大小、被索引，以及比字符型占用更小的空间，查询效率甩出使用字符型几条街。
在数据库的其他条件已经决定的条件下，表的尺寸越小，查询越快，这几乎是一条定理。
所以，在设计表的时候，应该吝啬的使用更精确的字段类型。
考虑扩展性
这涉及到了程序设计的范畴，但同样也是表设计重要的一方面。
如果你设计一个用户表，表中涉及到权限的管理，目前只有发帖、回帖、删帖三类权限，你会怎么设计？
你是会使用canPost、canReply、canDelete三个字段来标识权限，还是使用位运算方式用一个权限字段？
实际上没有谁对谁错，但是我认为第二种方式扩展性更好一点，如果需求更改，又增加3种权限，第一种方式需要修改程序和数据表，第二种方式只需要程序调整。
扩展性是表设计的一个重要考量，一定要留有余地，但也要避免过度设计。
选择合适的字段类型，是表设计的最基本要求。合适的类型，不仅能够减少表占用的空间，而且能增加查询效率。
两个表分别用
对于项目的最终瓶颈是什么，我想大多数程序员已经达成了共识，是数据库。
不论你使用哪种数据库，问题似乎最终都会回到这里。