分创建时和查询时这两个阶段的优化展开。
创建时优化
Schema和数据类型优化
- 尽量使用对应的数据类型。比如，不要用字符串类型保存时间，用整型保存IP。
- 选择更小的数据类型。能用TinyInt不用Int。
- 标识列（identifier column），建议使用整型，不推荐字符串类型，占用更多空间，而且计算速度比整型慢。
- 真实场景混用范式和反范式。冗余高查询效率高，插入更新效率低；冗余低插入更新效率高，查询效率低。
- 创建完全的独立的汇总表\缓存表，定时生成数据，用于用户耗时时间长的操作。对于精确度要求高的汇总操作，可以采用 历史结果+最新记录的结果 来达到快速查询的目的。
索引
- 索引的列如果是表达式的一部分或者是函数的参数，则失效。
- 针对特别长的字符串，可以使用前缀索引，根据索引的选择性选择合适的前缀长度。
- 使用多列索引的时候，可以通过 AND 和 OR 语法连接。
- 重复索引没必要，如（A，B）和（A）重复。
- 索引在where条件查询和group by语法查询的时候特别有效。
- 将范围查询放在条件查询的最后，防止范围查询导致的右边索引失效的问题。
- 索引最好不要选择过长的字符串，而且索引列也不宜为null。
查询时优化
- 避免查询无关的列，如使用Select * 返回所有的列。
- 避免查询无关的行
- 切分查询。将一个对服务器压力较大的任务，分解到一个较长的时间中，并分多次执行。如要删除一万条数据，可以分10次执行，每次执行完成后暂停一段时间，再继续执行。过程中可以释放服务器资源给其他任务。
- 分解关联查询。将多表关联查询的一次查询，分解成对单表的多次查询。可以减少锁竞争，查询本身的查询效率也比较高。因为MySql的连接和断开都是轻量级的操作，不会由于查询拆分为多次，造成效率问题。
- 注意count的操作只能统计不为null的列，所以统计总的行数使用count（*）。
- group by 按照标识列分组效率高，分组结果不宜出行分组列之外的列。
- 关联查询延迟关联，可以根据查询条件先缩小各自要查询的范围，再关联。
- Limit分页优化。可以根据索引覆盖扫描，再根据索引列关联自身查询其他列
- Union查询默认去重，如果不是业务必须，建议使用效率更高的Union All
|
参考： |
标签：数据库,SQL,数据类型,查询,索引,MySQL,关联,优化 From： https://www.cnblogs.com/xfeiyun/p/17231553.html