基于主题和之前的经验做了一个导图，分享于此
1.1 数据库引擎及字符集的选择
1.2 索引优化
1.2.1 需要join的表字段建立索引
1.2.2 基于业务分析在常用查询条件上创建索引 ，where 、group、order by
1.2.3 根据数据离散程度创建索引：无重复数据字段创建唯一索引，否则创建普通索引
1.2.4 经常使用的字段创建索引，减少查询时的表扫描
1.2.5 创建联合索引时，注意索引创建的顺序，需要排序的用在前面
1.3 sql语句优化
1.3.1 写数据优化
1.3.1.1 可以同步提交尽量同步提交，减少数据库的连接数
1.3.1.2 拆分大的事务，主线程只处理主逻辑，附属逻辑放到MQ中，通过服务处理
1.3.1.3 insert ，update 可能的情况尽量集合操作
1.3.2 查询
1.3.2.1 避免复杂的join
1.3.2.2 select 仅需要的列
1.3.2.3 基于索引进行查询，或者补充索引
1.3.2.4 基于查询分析器，分析语句执行过程，优化索引
1.3.2.5 oracle 可以使用hint优化器
1.3.2.6 不要使用无法命中索引的写法，如果!=,<>,or 等
1.4 系统层面
1.4.1 调整数据内存的占用率，让数据库热数据尽量存储在内存中
1.5 数据库架构层面
1.5.1 读/写分离
1.5.2 高可用集群
1.5.3 分片存储
1.6 业务层面
1.6.1 限制访问数量-比如秒杀:超过数量直接返回失败。成功请求进入队列处理，然后用户在订单中心查看秒杀结果进行并付块
1.6.2 将热点数据预热到缓存中
1.7 数据结构调整
1.7.1 设计优化：适度冗余，减少join
1.7.2 垂直拆分，将访问频率低大字段拆分到新表中
1.7.3 水平拆分
1.7.3.1 存在大量历史数据：可以基于时间讲历史数据归档
1.7.3.2 新系统：可以基于离散算法拆分，比如id%
1.7.4 数据类型选择
1.7.4.1 mysql下优先级：数值类型 > 日期 > 二进制 > 字符
1.7.4.2 长度(相对)固定用char，否则用varchar
1.7.4.3 精确度：decimal > float，存储开销则相反
1.7.4.4 留意char varchar nvarchar的区别
1.8 优化中的问题
1.8.1 优化后逻辑处理的复杂程度
1.8.2 数据库维护复杂度增加
1.8.3 数据平滑迁移的复杂度
1.8.4 程序功能的修改量
附导图：
