找到 MySQL 的瓶颈_MySQL

瓶颈

对于项目的最终瓶颈是什么，我想大多数程序员已经达成了共识，是数据库。

不论你使用哪种数据库，问题似乎最终都会回到这里。

首先，我们来分析一下导致瓶颈的主要原因：

1. 查询次数太多；
2. 返回的结果集太大；
3. 查询太复杂；
4. 数据更新表锁，导致查询堵塞；
5. 软硬件环境限制，如最大连接数限制、IO限制、硬件资源限制；

针对这些问题，又有那些应对方法呢？

1. 减少和合并查询；
2. 减少查询字段，使用 LIMIT 拆分为多次查询；
3. 简化和拆分查询，优化索引；
4. 优化数据库软件配置；
5. 分布和缓存；

表结构

数据库表的结构，不仅仅能够决定数据表所占用的空间，对查询效率有着显著的影响。

选择精确合理的字段类型

选择合适的字段类型，是表设计的最基本要求。合适的类型，不仅能够减少表占用的空间，而且能增加查询效率。

举个例子，存储时间（0000-00-00 00:00:00），你会使用 Char(19) 还是 DATETIME 呢？

你应该并必须选择后者，因为 DATETIME 在 MySQL 中几乎等同于数字，可以方便的运算、比较大小、被索引，以及比字符型占用更小的空间，查询效率甩出使用字符型几条街。

在数据库的其他条件已经决定的条件下，表的尺寸越小，查询越快，这几乎是一条定理。

所以，在设计表的时候，应该吝啬的使用更精确的字段类型。

考虑扩展性

这涉及到了程序设计的范畴，但同样也是表设计重要的一方面。

如果你设计一个用户表，表中涉及到权限的管理，目前只有发帖、回帖、删帖三类权限，你会怎么设计？

你是会使用canPost、canReply、canDelete三个字段来标识权限，还是使用位运算方式用一个权限字段？

实际上没有谁对谁错，但是我认为第二种方式扩展性更好一点，如果需求更改，又增加3种权限，第一种方式需要修改程序和数据表，第二种方式只需要程序调整。

扩展性是表设计的一个重要考量，一定要留有余地，但也要避免过度设计。

选择合适的字段类型，是表设计的最基本要求。合适的类型，不仅能够减少表占用的空间，而且能增加查询效率。

两个表分别用

对于项目的最终瓶颈是什么，我想大多数程序员已经达成了共识，是数据库。

不论你使用哪种数据库，问题似乎最终都会回到这里。