mysql 性能调优

SQL优化主要优化的还是查询, 优化查询的话, 索引优化是最有效的方案。

首先要根据需求写出结构良好的SQL，然后根据SQL 在表中建立有效的索引。但是如果索引太多，不但会影响写入的效率，对查询也有一定的影响。

优化索引

(1)索引列务必重复度低, where条件字段上需要建立索引；

(2)使用索引就不能用OR查询，否则索引不起作用；

(3)使用索引，like模糊查询不能以%开头；

(4)查询条件务必以索引列开头，否则索引失效；

(5)复合索引遵守最左原则。

造成索引失效的情况和如何避免索引失效

(1)尽量不要在where 子句中对字段进行null 值判断，否则将导致引擎放弃使用索引而进行全表扫描

(2)应尽量避免在where 子句中使用!= 或<> 操作符，否则将引擎放弃使用索引而进行全表扫描。

(3)应尽量避免在where 子句中使用or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引
擎放弃使用索引而进行全表扫描

(4)不做列运算where age + 1 = 10，任何对列的操作都将导致表扫描，它包括数据库教程函数。计算表达式等, 都会是索引失效。

(5)查询like，如果是‘%aaa’ 也会造成索引失效。

SQL语句调优

(1) 根据业务场景建立覆盖索引只查询业务需要的字段，如果这些字段被索引覆盖，将极大的提高查询效率。

(2) 多表连接的字段上需要建立索引，这样可以极大提高表连接的效率。

(3) where 条件字段上需要建立索引, 但Where 条件上不要使用运算函数，以免索引失效。

(4) 排序字段上, 分组字段上需要建立索引。

(5) 优化insert 语句: 批量列插入数据要比单个列插入数据效率高。

(6) 优化order by 语句: 在使用order by 语句时, 不要使用select *,select 后面要查有索引的列, 如果一条SQL语句中对多个列进行排序, 在业务允许情况下, 尽量同时用升序或同时用降序。

(7) 优化group by 语句: 在我们对某一个字段进行分组的时候, MySQL默认就进行了排序, 但是排序并不是我们业务所需的, 额外的排序会降低效率。所以在用的时候可以禁止排序, 使用order by null禁用。
如：select age, count(*) from emp group by age order by null

(8) 尽量避免子查询, 可以将子查询优化为join 多表连接查询。

合理的数据库设计

根据数据库三范式来进行表结构的设计。设计表结构时，就需要考虑如何设计才能更有效的查询, 遵循数据库三范式：

1. 第一范式：数据表中每个字段都必须是不可拆分的最小单元，也就是确保每一列的原子性;

2. 第二范式：满足一范式后，表中每一列必须有唯一性，都必须依赖于主键;

3. 第三范式：满足二范式后，表中的每一列只与主键直接相关而不是间接相关(外键也是直接相关)，字段没有冗余。

注意：

没有最好的设计，只有最合适的设计，所以不要过分注重理论。三范式可以作为一个基本依据，不要生搬硬套。

有时候可以根据场景合理地反规范化：

A：分割表。

B：保留冗余字段。当两个或多个表在查询中经常需要连接时，可以在其中一个表上增加若干冗余的字段，以避免表之间的连接过于频繁，一般在冗余列的数据不经常变动的情况下使用。

C：增加派生列。派生列是由表中的其它多个列的计算所得，增加派生列可以减少统计运算，在数据汇总时可以大大缩短运算时间, 前提是这个列经常被用到, 这也就是反第三范式。

分表

水平分割(按行)，垂直分割(按列)

分表场景

A：根据经验，MySQL 表数据一般达到百万级别，查询效率就会很低。

B：一张表的某些字段值比较大并且很少使用。可以将这些字段隔离成单独一张表，通过外键关联，例如考试成绩，我们通常关注分数，不关注考试详情。

水平分表策略

C：按时间分表：当数据有很强的实效性，例如微博的数据，可以按月分割。

按区间分表：例如用户表1 到一百万用一张表，一百万到两百万用一张表。

hash分表：

通过一个原始目标id 或者是名称按照一定的hash 算法计算出数据存储的表名。