一、数据库优化
一般来说，要保证数据库的效率，要做好以下四个方面的工作：数据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统，这个顺序也表现了这四个工作对性能影响的大小。
选择合适的引擎：Mysql提供了很多种引擎，我们用的最多的是myisam，innodb，memory这三类。其中 myisam 和 innodb 比较，在测试中 myisam 的表现还不及 innodb。至于memory，哈哈，还是比较好用的。在批处理种作临时表是个不错的选择(如果内存够大)，速度比近乎1：10。
慢SQL采集：在mysql的配置参数中添加以下两句，就能自动采集查询时间超过两秒的SQL语句。但是采集的SQL会很大，可以用 mysql 自带的工具 mysqldumpslow 来分析。
slow_query_log=d:/slow.txt
long_query_time = 2
二、建表规约
我们在开发应用程序时，设计的数据库要最大程度的遵守三范式，特别是对于OLTP型的系统，三范式是必须遵守的规则。当然，三范式最大的问题在于查询时通常需要join很多表，导致查询效率很低。所以有时候基于性能考虑，我们需要有意的违反三范式，适度的做冗余，以达到提高查询效率的目的。
1、表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsigned tinyint（1 表示是， 0 表示否） 。
2、表名、字段名必须使用小写字母或数字， 禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。
3、表名不使用复数名词。
4、主键索引名为 pk_字段名； 唯一索引名为 uk_字段名； 普通索引名则为 idx_字段名。
5、小数类型为 decimal，禁止使用 float 和 double(存在精度损失的问题)
6、如果存储的字符串长度几乎相等，使用 char 定长字符串类型。
7、表必备三字段： id, gmt_create, gmt_modified。
说明： 其中 id 必为主键，类型为 unsigned bigint、单表时自增、步长为 1。 gmt_create,gmt_modified 的类型均为 date_time 类型。
8、字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循：
1） 不是频繁修改的字段。
2） 不是 varchar 超长字段，更不能是 text 字段。
正例： 商品类目名称使用频率高， 字段长度短，名称基本一成不变， 可在相关联的表中冗余存储类目名称，避免关联查询
9、强烈建议用自增类型，不用uuid。按4个字节和按32个字节定位一条记录，谁快谁慢太明显了。涉及到几个表做join时，效果就更明显了。除占用大量存储空间外，最主要的问题是在索引上，在建立索引和基于索引进行查询时都存在性能问题。
10、文章、图片大文件用文件存储系统，不用数据库。
11、单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
12、水平分表：一个表的记录数太多了，依照某个字段的逻辑关系（比如时间段，某个字段的多个类型）来把一个表拆分成多个。
13、垂直分表：一个表的记录数不多，但是字段却很长，表占用的空间很大。这个时候需要把大的字段拆分到另一个表，并且该表与原表是一对一关系。
三、索引规约
建立索引而导致的查询速度的提高是以插入、更新、删除的速度为代价的。一般我们建立索引需要遵循这样的规则：
-- 索引的字段必须是经常作为查询的字段。
-- 多个字段建立的组合索引。如果只有第二个字段作为查询条件，这个索引不会起作用。
-- 索引的字段必须有足够的区分度。
-- Mysql 对长字段支持前缀索引。
1、业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。
2、超过三个表禁止 join。需要 join 的字段，数据类型必须绝对一致； 多表关联查询时，保证被关联的字段需要有索引。
3、在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。
说明：
1）索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会高达 90%以上，可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度来确定。
2）一般区别度能达到0.1，索引的性能就可以接受。
3）CREATE INDEX index_name ON table_name(column_name(length), clolumn_name(length)…)
4、页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。
说明： 索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。
5、利用延迟关联或者子查询优化超多分页场景。
说明： MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回N 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行 SQL改写。
正例： 先快速定位需要获取的 id 段，然后再关联：
SELECT a.* FROM 表 1 a, (select id from 表 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id
6、SQL 性能优化的目标：至少要达到 range 级别， 要求是 ref 级别， 如果可以是 consts最好。
说明：
1） consts 单表中最多只有一个匹配行（主键或者唯一索引） ，在优化阶段即可读取到数据。
2） ref 指的是使用普通的索引（normal index） 。ref 可以用于使用 = 或 <=> 操作符的带索引的列。
3） range 对索引进行范围检索。当使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符，用常量比较关键字列时，可以使用range。
4） index 当查询只使用作为单索引一部分的列时，Mysql 可以使用该连接类型。
5) ALL 查询进行完整的表扫描，应该尽量避免。
7、建组合索引的时候，区分度最高的在最左边。
正例： 如果 where a=? and b=? ， a 列的几乎接近于唯一值，那么只需要单建 idx_a 索引即可
8、如果有 order by 的场景，请注意利用索引的有序性。 order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。
正例： where a=? and b=? order by c; 索引： a_b_c
反例： 索引中有范围查找，那么索引有序性无法利用，如： WHERE a>10 ORDER BY b; 索引a_b 无法排序
9、利用覆盖索引来进行查询操作， 避免回表。
说明： 如果一本书需要知道第 11 章是什么标题，会翻开第 11 章对应的那一页吗？目录浏览一下就好，这个目录就是起到覆盖索引的作用。
正例： 能够建立索引的种类：主键索引、唯一索引、普通索引，而覆盖索引是一种查询的一种效果，用 explain 的结果， extra 列会出现： using index。
正例： 能够建立索引的种类：主键索引、唯一索引、普通索引，而覆盖索引是一种查询的一种效果，用 explain 的结果， extra 列会出现： using index。
四、SQL语句
1、不要使用 count(列名)或 count(常量)来替代 count(*)， count(*)是 SQL92 定义的标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关
2、count(distinct col) 计算该列除 NULL 之外的不重复行数， 注意 count(distinct col1, col2) 如果其中一列全为 NULL，那么即使另一列有不同的值，也返回为 0。
3、当某一列的值全是 NULL 时， count(col)的返回结果为 0，但 sum(col)的返回结果为NULL，因此使用 sum()时需注意 NPE 问题。
正例： 可以使用如下方式来避免 sum 的 NPE 问题： SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;
4、在代码中写分页查询逻辑时，若 count 为 0 应直接返回，避免执行后面的分页语句。
5、禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。