其实项目应用的瓶颈还是在db端，在只有少量数据及极少并发的情况下，并不需要多少的技巧就可以得到我们想要的结果，但是当数据量达到一定量级的时候，程序的每一个细节，数据库的设计都会影响到系统的性能。这里就数据库开发及优化的话题和大家做个讨论和分析，也请大家完善，这里就以下几个话题，我先发表自己的见解。

　　1.存储引擎的选择

　　2.索引的设计及使用

　　3.大批量插入时SQL语句的优化

　　存储引擎的选择

　　声明：本文所针对的数据库版本都是MYSQL 5这里我主要针对两种存储引擎进行简单比较分别是MyISAM和InnoDB，首先比较下区别：

　　1. MyISAM不支持事务，不支持外键，优点是访问速度高，批量插入速度快。假设大量的操作是select、insert，建议采用该存储引擎。但是在我的实际应用中，出现过批量插入过于频繁的时候，当数据量到达一定级别，出现表损坏的情况。

　　2. InnoDB支持事务处理，但是相对于前者，处理效率低一些，并且其索引及数据也更占用磁盘空间。在存储一些关键数据，并需要对其进行事务操作的时候，我们可以选择innodb，当然，我认为他不应该是访问量太大的。

　　索引的设计及使用

　　没有索引的表是恐怖的，除非里头没多少数据，但是怎么设计索引是合理的？恐怕不是所有人都明白，这里简要分析下索引的设计及使用。

　　1. 索引通常是设置where字句中的列，如果你设置select后的列，这是没有任何意义的。当然你需要对某列进行排序，order by后的列也是可以建成索引的。

　　2. 使用唯一索引，主键就是最好的例子，假设你建的索引列，大量都是重复的，例如：性别，那么这样的索引并不会加快搜索速度。至于为什么，请大家自行了解索引的工作原理。

　　3. 只要有可能，就要尽量限定索引的长度，例如索引列为 char(100)，在其前10个字符大部分都是唯一的，请设置索引的长度为10，使用短索引可以加快查询速度，并节省硬盘空间。

　　4. 索引的左前缀特性，联合索引实质上也是建立了多个的索引，那么是建立联合索引好还是分别建多个索引好呢？显然前者更好，利用左前缀特性，只要联合索引的最左的列被用到，那么索引都会被使用。

　　5. 当然，最后要说的是，不要过度使用索引，索引越多，插入的速度越慢，尤其到数据量庞大时，同时，大量的索引将耗费很多硬盘空间，造成不必要的浪费。

　　下面举几个列子来说明索引的使用：

　　1.联合索引的左前缀

　　先看索引结构:

　　代码:

mysql>　show　index　from　user;
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
|　Table　|　Non_unique　|　Key_name　|　Seq_in_index　|　Column_name　|　Collation　|　Cardinality　|　Sub_part　|　Packed　|　Null　|　Index_type　|　Comment　|
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
|　user　　|　　　　0　|　PRIMARY　　|1　|　user_id　　　　　|　A　　　|　　　　　2　|　　　　　NULL　|　NULL　　　||　BTREE|　　　|
|　user　　|　　　　1　|　user　　　　　|1　|　username　　　　|　A　　　|　　NULL　|　　　　　NULL　|　NULL　　　||　BTREE|　　　|
|　user　　|　　　　1　|　user　　　　　|2　|　order　|　A　　　|　　NULL　|　　　　　NULL　|　NULL　　　||　BTREE|　　　|
|　user　　|　　　　1　|　user　　　　　|3　|　email　|　A　　　|　　NULL　|　　　　　NULL　|　NULL　　　|　YES　　|　BTREE|　　　|
+-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
4　rows　in　set　(0.00　sec)