一. 数据库索引
规则8：业务需要的相关索引是根据实际的设计所构造sql语句的where条件确定的，业务不需要的不要建索引，不允许在联合索引（或主键）中存在多余的字段，特别是该字段根本不会在条件语句中出现。
规则9：唯一确定一条记录的一个字段或多个字段要建立主键或者唯一索引，不能唯一确定一条记录，为了提高查询效率建普通索引
规则10：业务使用的表，有些记录数很少，甚至只有一个条记录，为了约束的需要，也要建立索引或者设置主键。
规则11：对于取值不能重复，经常作为查询条件的字段，应该建唯一索引(主键默认唯一索引),并且将查询条件中给字段的条件置于一个位置，没有必要在建立与该字段有关的联合索引。
规则12：对于经常查询的字段，其值不唯一，也应该考虑建立普通索引，查询语句中该字段条件置于第一个位置，对联合索引处理的方法同样。
规则13：业务通过不唯一索引访问数据时，需要考虑通过该索引值返回的记录抽密度，原则上可能的抽密度最大不能高于0.2 如果稠密大太大，则不合适建立索引了。
当通过这个索引查找得到的数据量占到表内所有数据的20%以上时，则需要考虑建立该索引的代价，同时由于索引扫描产生的都是随机I/O，其效率比全表顺序扫描的顺序I/O 低很多，数据库系统优化query的时候有可能不会用到这个索引。
规则14：需要联合索引(或联合主键)的数据库要注意索引的顺序，SQL语句中的匹配条件也要跟索引的顺序保持一致。
注意：索引的顺势不正确也可能导致严重的后果。
规则17：重要的业务访问数据表时，但不能通过索引访问数据时，应该确保顺序访问的记录数目是有限的，原则上不得对于10
二 Query语句与应用系统优化
规则18：合理构造Query语句
1 Insert语句中，根据测试，批量一次插入1000条时效率最高，对于1000条时，要拆分，多次进行同样的插入，应该合并批量进行。注意query语句的长度要小于mysqld的参数 max_allowed_packet
2 查询条件中各种逻辑操作符性能顺序是 and or in 因此在查询条件中应该尽量避免使用在大集合中使用 in
3. 永远用小结果集驱动大记录集，因为在mysql中，只有Nested Join 一种Join方式，就是说mysql的join是通过嵌套循环来实现的。通过小结果集驱动大记录集这个原则来减少嵌套循环的循环次数，以减少IO总量及CPU运算次数
4.尽量优化Nested Join内层循环。
5.只取需要的columns,尽量不要使用 select *
6. 仅仅使用最有效的过滤字段，where字句中的过滤条件少为好
7.尽量避免复杂的Join和子查询
Mysql在并发这方面做的不是很好，当并发量太高的时候，整体性能会急剧下降，这主要与Mysql内部资源的争用锁定控制有关，Myisam用表锁，innodb用行锁
规则19： 应用系统的优化
1.合理使用cache,对于变化较少的部分活跃数据通过应用层的cache缓存到内存中，对性能的提升是数据级的。
2. 对重复执行相同的query进行合并，减少IO次数。
3. 事务相关性最小原则