一、优化知识点

• 尽量使用对应的数据类型。比如，不要用字符串类型保存时间。
• 选择更小的数据类型。能用TinyInt不用Int。
• 标识列（identifier column），建议使用整型，不推荐字符串类型，占用更多空间，而且计算速度比整型慢。
• 不推荐ORM系统自动生成的Schema，通常具有不注重数据类型，使用很大的VarChar类型，索引利用不合理等问题。
• 真实场景混用范式和反范式。冗余高查询效率高，插入更新效率低；冗余低插入更新效率高，查询效率低。
• 创建完全的独立的汇总表缓存表，定时生成数据，用于用户耗时时间长的操作。对于精确度要求高的汇总操作，可以采用 历史结果+最新记录的结果 来达到快速查询的目的。
• 数据迁移，表升级的过程中可以使用影子表的方式，通过修改原表的表名，达到保存历史数据，同时不影响新表使用的目的。

二、索引的优化：

• 注意每种索引的适用范围和适用限制。
• 索引的列如果是表达式的一部分或者是函数的参数，则失效。
• 针对特别长的字符串，可以使用前缀索引，根据索引的选择性选择合适的前缀长度。
• 使用多列索引的时候，可以通过 AND 和 OR 语法连接。
• 重复索引没必要，如（A，B）和（A）重复。
• 索引在where条件查询和group by语法查询的时候特别有效。
• 将范围查询放在条件查询的最后，防止范围查询导致的右边索引失效的问题。
• 索引最好不要选择过长的字符串，而且索引列也不宜为null。

三、查询优化：

• 避免查询无关的列，如使用Select * 返回所有的列。
• 避免查询无关的行
• 切分查询。将一个对服务器压力较大的任务，分解到一个较长的时间中，并分多次执行。如要删除一万条数据，可以分10次执行，每次执行完成后暂停一段时间，再继续执行。过程中可以释放服务器资源给其他任务。
• 分解关联查询。将多表关联查询的一次查询，分解成对单表的多次查询。可以减少锁竞争，查询本身的查询效率也比较高。因为MySql的连接和断开都是轻量级的操作，不会由于查询拆分为多次，造成效率问题。
• 注意count的操作只能统计不为null的列，所以统计总的行数使用count（*）。
• group by 按照标识列分组效率高，分组结果不宜出行分组列之外的列。
• 关联查询延迟关联，可以根据查询条件先缩小各自要查询的范围，再关联。
• Limit分页优化。可以根据索引覆盖扫描，再根据索引列关联自身查询其他列。如
• SELECTid,NAME,ageWHEREstudent s1INNER JOIN (SELECT idFROM studentORDER BY ageLIMIT 50,5) AS s2 ON s1.id = s2.id
• Union查询默认去重，如果不是业务必须，建议使用效率更高的Union All
• SELECT a, b FROM t WHERE c = 2 AND d > 200 GROUP BY e DESC
• mysql会默认对group by子句中的字段，从小到大排序，在后面添加order by null可以禁止排序，提高效率