MySQL调优

1.存储引擎选择

MyISAM：不支持事务处理，读性能处理快，表级别锁，MyISAM适用于读取繁重的应用程序。
InnoDB：支持事务处理（ACID），设计目标是为处理大容量数据发挥最大化性能，行级别锁。MySQL5.5以后版本中默认为InnoDB存储引擎引擎。

表锁：开销小，锁定粒度大，发生死锁概率高，相对并发也低。
行锁：开销大，锁定粒度小，发生死锁概率低，相对并发也高。

如果不是只读业务的话，建议选择InnoDB引擎。

2.字段

数据类型选择：

• 优先考虑数字类型
• 其次是日期、时间类型
• 最后是字符类型
• 对于相同级别的数据类型，应该选择占用空间小的数据类型

timestamp和datetime区别？

1.存储方式不同

timestamp和时区有关，datetime和时区无关；

2.存储时间范围不同

timestamp存储时间范围是 1970-01-01 00:00:01-2038-01-19 03:14:07

datetime纯属时间范围是1000-01-01 00:00:00-9999012-31 23:59:59

1.尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNED。
2.使用TINYINT代替字符串类型。
3.对于不确定字符串长度，使用varchar(n)代替 char(n)，因为变长字段存储空间小，对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

4.单表不要有太多字段，建议在30以内（一个多字段的大表按常用字段和非常用字段进行拆分）

3.索引

1.避免在插入、更新十分频繁、区分度不高的列上建立索引。
更新频繁的字段建立索引会大大降低数据库性能；“性别”这种区分度不大的属性，建立索引是没有什么意义的，不能有效过滤数据，性能与全表扫描类似。
2.考虑在WHERE和ORDER BY、group by和distinct列命令上涉及的列建立索引
3.可根据EXPLAIN来查看是否用了索引还是全表扫描。

4.SQL语句优化

1.避免使用SELECT *，不需要的列会增加CPU、IO、网络消耗；
2.禁止使用属性隐式转换，
如：SELECT uid FROM t_user WHERE phone=13812345678，当phone为varchar时会导致全表扫描，而不能命中phone索引。
3.避免负向查询条件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，会导致全表扫描.
4.获取唯一行时使用LIMIT 1，数据库引擎将在找到刚刚第一个记录之后停止扫描记录，而不是遍历整个表或索引。

5.数据库架构

1.增加缓存

把热数据缓存到内存中，如果缓存中有要请求的数据就不再去数据库中返回结果，提高读性能。缓存实现有本地缓存和分布式缓存，本地缓存是将数据缓存到本地服务器内存中或者文件中。分布式缓存可以缓存海量数据，扩展性好，主流的分布式缓存系统有memcached、redis。

2.主从复制与读写分离

因为生产环境中，数据库大多都是读操作，所以部署一主多从架构，主数据库负责写操作，并做双机热备，多台从数据库做负载均衡，负责读操作。

3.分库

为了解决单台服务器的性能问题，当单台数据库服务器无法支撑当前的数据量时，需要根据业务不同把相关的表切分到不同的数据库中，以降低单台服务器的负载。比如按用户相关业务、论坛相关业务进行分库。如果业务量很大，还可将切分后的库做主从架构，进一步避免单个库压力过大。分库一般考虑的是垂直切分，除非在垂直切分后，数据量仍然多到单台服务器无法负载，才继续水平切分。
分库的目的是降低单台服务器负载，切分原则是根据业务紧密程度拆分，缺点是跨数据库无法联表查询。

4.分表

4.1垂直拆分
把原来的一个很多字段的表拆分多个表，把不常用或业务逻辑不紧密或存储内容比较多的字段分到新的表中可使表。
原因：
减少字段可使内存加载更多行数据，有利于查询；
受限于操作系统中的文件大小限制，拆分后可降低单表文件大小
4.2水平拆分
把原来一个表拆分成多个表，每个表的结构都一样，解决单表数据量大的问题。
原因：
随着数据量的增大，表行数巨大，查询的效率越来越低。
同样受限于操作系统中的文件大小限制，数据量不能无限增加，当到达一定容量时，需要水平切分以降低单表（文件）的大小。