首先要根据需求写出结构良好的SQL,然后根据SQL 在表中建立有效的索引。但是如果索引太多,不但会影响写入的效率,对查询也有一定的影响。
这是最常用,每一个技术人员都应该掌握基本的SQL调优手段(包括方法、工具、辅助系统等)。这里以MySQL为例,最常见的方式是,由自带的慢查询日志或者开源的慢查询系统定位到具体的出问题的SQL,然后使用explain。profile等工具来逐步调优,最后经过测试达到效果后上线。
explain + sql语句查询sql执行过程, 通过执行计划,我们能得到哪些信息:
A:哪些步骤花费的成本比较高
B:哪些步骤产生的数据量多,数据量的多少用线条的粗细表示,很直观
C:每一步执行了什么动作
(1)索引列务必重复度低, where条件字段上需要建立索引
(2)使用索引就不能用OR查询,否则索引不起作用
(3)使用索引,like模糊查询不能以%开头
(4)查询条件务必以索引列开头,否则索引失效
(5)复合索引遵守最左原则。
A:尽量不要在where 子句中对字段进行null 值判断,否则将导致引擎放弃使用索引而进行全表扫描
B:应尽量避免在where 子句中使用!=或<> 操作符,否则将引擎放弃使用索引而进行全表扫描。
C:应尽量避免在where 子句中使用or 来连接条件,如果一个字段有索引,一个字段没有索引,将导致引擎放弃使用索引而进行全表扫描
D:不做列运算where age + 1=10,任何对列的操作都将导致表扫描,它包括数据库教程函数。计算表达式等, 都会是索引失效。
E:查询like,如果是‘%aaa’ 也会造成索引失效。
·根据业务场景建立覆盖索引只查询业务需要的字段,如果这些字段被索引覆盖,将极大的提高查询效率。
· 多表连接的字段上需要建立索引,这样可以极大提高表连接的效率。
· where 条件字段上需要建立索引, 但Where 条件上不要使用运算函数,以免索引失效。
· 排序字段上, 分组字段上需要建立索引。
· 优化insert 语句: 批量列插入数据要比单个列插入数据效率高。
· 优化order by 语句: 在使用order by 语句时, 不要使用select *,select 后面要查有索引的列, 如果一条sql 语句中对多个列进行排序, 在业务允许情况下, 尽量同时用升序或同时用降序。
· 优化group by 语句: 在我们对某一个字段进行分组的时候, Mysql默认就进行了排序, 但是排序并不是我们业务所需的, 额外的排序会降低效率。所以在用的时候可以禁止排序, 使用order by null禁用。
select age, count(*) from emp group by age order by null
· 尽量避免子查询, 可以将子查询优化为join 多表连接查询。
根据数据库三范式来进行表结构的设计。设计表结构时,就需要考虑如何设计才能更有效的查询, 遵循数据库三范式:
i. 第一范式:数据表中每个字段都必须是不可拆分的最小单元,也就是确保每一列的原子性;
ii. 第二范式:满足一范式后,表中每一列必须有唯一性,都必须依赖于主键;
iii. 第三范式:满足二范式后,表中的每一列只与主键直接相关而不是间接相关(外键也是直接相关),字段没有冗余。
注意:没有最好的设计,只有最合适的设计,所以不要过分注重理论。三范式可以作为一个基本依据,不要生搬硬套。
有时候可以根据场景合理地反规范化:
A:分割表。
B:保留冗余字段。当两个或多个表在查询中经常需要连接时,可以在其中一个表上增加若干冗余的字段,以避免表之间的连接过于频繁,一般在冗余列的数据不经常变动的情况下使用。
C:增加派生列。派生列是由表中的其它多个列的计算所得,增加派生列可以减少统计运算,在数据汇总时可以大大缩短运算时间, 前提是这个列经常被用到, 这也就是反第三范式。
水平分割(按行),垂直分割(按列)
分表场景
A:根据经验,MySQL 表数据一般达到百万级别,查询效率就会很低。
B:一张表的某些字段值比较大并且很少使用。可以将这些字段隔离成单独一张表,通过外键关联,例如考试成绩,我们通常关注分数,不关注考试详情。
水平分表策略
C:按时间分表:当数据有很强的实效性,例如微博的数据,可以按月分割。
按区间分表:例如用户表1 到一百万用一张表,一百万到两百万用一张表。
hash分表:通过一个原始目标id 或者是名称按照一定的hash 算法计算出数据存储的表名。