1. 表结构
存储引擎
MyIsam: 应用时以读和插入操作为主，只有少量的更新和删除，并且对事务的完整性，并发性要求不是很高的。（适合做只读表，如统计表等）
InnoDB: 事务处理，以及并发条件下要求数据的一致性。（适合批量操作与经常修改）
字段类型
- 选用合适的字段类型，选用最小的长度减少存储空间，尽量使用int型；
- 尽可能的使用 varchar/nvarchar 代替 char/nchar，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些；
- 不要使用null作为默认值，将导致全表扫描，使用其他（0，-1）代替；
2. 索引
索引就是为特定的mysql字段进行一些特定的算法排序，比如二叉树的算法和哈希算法，哈希算法是通过建立特征值，然后根据特征值来快速查找。而用的最多，并且是mysql默认的就是二叉树算法 BTREE，通过BTREE算法建立索引的字段，比如扫描20行就能得到未使用BTREE前扫描了2^20行的结果。
实际上，索引也是一张表，该表保存了主键与索引字段，并指向实体表的记录。
（https://www.cnblogs.com/shijingxiang/articles/4743324.html）
聚簇索引、非聚簇索引（二级索引）
https://www.cnblogs.com/crazylqy/p/7615393.html
https://blog.csdn.net/u013132035/article/details/82193763
https://blog.csdn.net/GitChat/article/details/78787837
http://www.imooc.com/article/267890
- 主键索引，外键索引；
- 在where条件中经常使用查询的列加索引（根据实际场景分析）；
- 使用复合索引（确定是多个列同时查询才使用）；
- 创建索引要选择维度高（不重复值出现的个数大）的列；
优点：加快查询速度
缺点：索引会降低写的速度（因为要动态维护索引），随着数据量的增加，索引文件也会越来越大
3. 查询优化
- 开启查询缓存
缓存条件：查询缓存可以看做是SQL文本和查询结果的映射。如果第二次查询的SQL和第一次查询的SQL完全相同（注意必须是完全相同，即使多一个空格或者大小写不同都认为不同）且开启了查询缓存，那么第二次查询就直接从查询缓存中取结果；
缓存失效机制：在表的结构或数据发生改变时，查询缓存中的数据不再有效。
- 开启慢查询日志，定期检查SQL语句；
- 使用Explain分心SQL语句的性能；https://www.runoob.com/w3cnote/mysql-index.html
SQL语句优化
- 避免使用 select *，要什么查什么；
- 避免使用 <>，MySQL只对以下操作符使用索引：<，<=，=，>，>=，BETWEEN，IN；
- 避免使用 or，将导致全表扫描，可以使用 union 代替；
- in和not in在某些情况也会导致全表扫描；（一般情况下，当你IN中的条件太多，或是无法估计时，优化器倾向于全表扫描。当IN的条件少时，如果优化器认为，INDEX SEEK可以带来好处时，照样会走索引的。）
- 避免对字段进行函数操作，导致全表扫描；
- 多个表连接查询（join）的时候请使用别名，可以减少解析的时间并减少那些由Column歧义引起的语法错误；
4. 主从配置、读写分离
在实际的生产环境中，由单台Mysql作为独立的数据库是完全不能满足实际需求的，无论是在安全性，高可用性以及高并发等各个方面。因此，一般来说都是通过 主从复制（Master-Slave）的方式来同步数据，再通过读写分离（MySQL-Proxy）来提升数据库的并发负载能力 这样的方案来进行部署与实施的。
主从复制原理：
主库(Master)开启二进制日志(binlog，记录所有数据库操作的日志)；主库授权一个账号给从库(Slave)，从库作为主库的一个客户端访问主库的二进制日志，记录到自己的中继日志（Relay Log）中；从库的SQL线程会检测自己的中继日志，并执行；
具体执行过程：
（1）在Slave服务器上执行start slave命令开启主从复制开关，开始进行主从复制。
（2）此时，Slave服务器的IO线程会通过在master上已经授权的复制用户权限请求连接Master服务器，并请求从执行binlog日志文件中的指定位置（日志文件名和位置就是在配置主从复制服务时执行change master命令指定的）之后开始发送binlog日志内容。
（3）Master服务器接收来自Slave服务器的IO线程的请求后，其上负责复制的IO线程会根据Slave服务器的IO线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给Slave端的IO线程。
（4）当Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到Slave端自身的Relay Log（即中继日志）文件（Mysql-relay-bin.xxx）的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master端新binlog日志时能告诉Master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容
（5）Slave服务器端的SQL线程会实时检测本地Relay Log 中IO线程新增的日志内容，然后及时把Relay LOG 文件中的内容解析成sql语句，并在自身Slave服务器上按解析SQL语句的位置顺序执行应用这样sql语句，并在relay-log.info中记录当前应用中继日志的文件名和位置点
读写分离（主写从读）
从服务器只负责读，主服务器负责写操作、
实现方式：
1. 程序上判断（开发者自己写）
2. 使用中间件，MySQL- Proxy是实现"读写分离(Read/Write Splitting)"的一个软件。基本的原理是让主数据库处理写操作（insert、update、delete），而从数据库处理查询操作（select）。而数据库的一致性则通过主从复制来实现。所以说主从复制是读写分离的基础。
5、分库、分区、分表
https://blog.csdn.net/u011665991/article/details/90038768
分区：https://blog.csdn.net/vbirdbest/article/details/82461109
分区原理：
分区表是由多个相关的底层表实现，这些底层表也是由句柄对象表示，所以我们也可以直接访问各个分区，存储引擎管理分区和一个普通表没有任何不同，存储引擎也无须知道这是一个普通表是分区表的一部分。
在分区表上的操作是按照下面的操作逻辑进行：
- select 查询：分区层先打开并锁住所有的底层表，优化器判断是否可以过滤部分分区，然后再调 用对应的存储接口访问各个分区。
- insert操作：分区层打开并锁住所有底层表，然后确定那个分区接受这条记录，再将这条记录写入对应的底层表 。
- delete操作：分区层先打开并锁住所有底层表，mysql先确定对象分区，最后对相应的底层表进行删除操作。
- update操作：分区层先打开并锁住所有的底层表，mysql先确定更新的记录再哪个分区，然后取出数据并更新，在判断更新后的数据应该放在哪个分区，然后对底层表进行写入操作，并对原数据的底层表进行删除操作。