MySQL数据库的优化

MySQL优化

mysql为何要进行优化：

系统的吞吐量瓶颈往往出现在数据库的访问速度上
随着应用程序的运行，数据库的中的数据会越来越多，处理时间会相应变慢
为了避免慢查询的出现

mysql优化是一个综合性的技术，主要包括：

表的是设计合理化(符合 3范式)
添加适当的索引(index)[四种：普通索引，主键索引，唯一索引，unique，全文索引]
分表技术(水平分割，垂直分割)
读写：[update/delete/add]分离
存储过程[模块化编程，可以提高速度]
对mysql配置优化[配置最大并发数，my.ini调整缓存大小]
Mysql服务器引荐升级
定时的清理不需要的数据，定时进行碎片整理

要保证数据库的效率，要做好以下四个方面的工作

数据库设计
sql语句优化
数据库参数配置
恰当的硬件资源和操作系统
此外，使用适当的存储过程，也能提升性能，这个顺序也表现了这四个工作对性能影响的大小

数据库的表设计

通俗地理解三个范式第一范式： 1NF是对属性的原子性约束，要求属性(列)具有原子性，不可再分解；(只要是关系型数据库都满足1NF)第二范式： 2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；第三范式： 3NF是对字段冗余性的约束，它要求字段没有冗余。 没有冗余的数据库设计可以做到。第一范式（1NF）1. 即表的列的具有原子性,不可再分解，即列的信息，不能分解, 只要数据库是关系型数据库(mysql/oracle/db2/informix/sysbase/sql server)，就自动的满足1NF。2. 数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。3. 如果实体中的某个属性有多个值时，必须拆分为不同的属性 。通俗理解即一个字段只存储一项信息。第二范式（2NF）1、要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要我们设计一个主键来实现(这里的主键不包含业务逻辑)。第三范式（3NF）1、要求一个数据库表中不包含已在其它表中已包含的非主键字段。2、如果能够被推导出来，就不应该单独的设计一个字段来存放(能尽量外键join就用外键join)。3、很多时候，我们为了满足第三范式往往会把一张表分成多张表。

MySQL优化的一般步骤：

通过show status命令了解各种SQL的执行频率
定位执行效率较低的SQL语句-（重点select）
通过explain分析低效率的SQL语句的执行情况

explain关键字作用

使用 EXPLAIN 关键字可以让你知道MySQL是如何处理你的SQL语句的。这可以帮你分析你的查询语句或是表结构的性能瓶颈
EXPLAIN 的查询结果还会告诉你你的索引主键被如何利用的，你的数据表是如何被搜索和排序的……等等，等等

explain使用举例

　　Explain select * from emp where ename=“wsrcla”会产生如下信息：select_type: 表示查询的类型。table:  输出结果集的表type:  表示表的连接类型possible_keys:   表示查询时，可能使用的索引key:   表示实际使用的索引key_len:   索引字段的长度rows:   扫描出的行数(估算的行数)Extra:   执行情况的描述和说明

EXPLAIN信息详解

1. id   SELECT识别符。这是SELECT的查询序列号2. select_type　PRIMARY :   子查询中最外层查询SUBQUERY :    子查询内层第一个SELECT，结果不依赖于外部查询DEPENDENT SUBQUERY:   子查询内层第一个SELECT，依赖于外部查询UNION :   UNION语句中第二个SELECT开始后面所有SELECT，SIMPLE：  简单的 select 查询,不使用 union 及子查询UNION ：  UNION 中的第二个或随后的 select 查询,不依赖于外部查询的结果集3. Table ： 显示这一步所访问数据库中表名称4. Type ： 对表访问方式ALL：  SELECT * FROM emp \G 完整的表扫描 通常不好SELECT * FROM (SELECT * FROM emp WHERE empno = 1) a ;system：  表仅有一行(=系统表)。这是const联接类型的一个特const：  表最多有一个匹配行5. Possible_keys ： 该查询可以利用的索引，如果没有任何索引显示  null6. Key ： Mysql 从 Possible_keys 所选择使用索引7. Rows ：  估算出结果集行数8. Extra查询细节信息No tables ：  Query语句中使用FROM DUAL 或不含任何FROM子句Using filesort ：  当Query中包含 ORDER BY 操作，而且无法利用索引完成排序，Impossible WHERE noticed after reading const tables: MYSQL Query Optimizer　通过收集统计信息不可能存在结果Using temporary：  某些操作必须使用临时表，常见 GROUP BY ; ORDER BYUsing where：  不用读取表中所有信息，仅通过索引就可以获取所需数据;

优化措施

编写 SQL 时就需要注意与索引相关的规则：

字段类型转换导致不用索引，如字符串类型的不用引号，数字类型的用引号等，这有可能会用不到索引导致全表扫描
mysql 不支持函数转换，所以字段前面不能加函数，否则这将用不到索引
不要在字段前面加减运算
字符串比较长的可以考虑索引一部份减少索引文件大小，提高写入效率
like % 在前面用不到索引
根据联合索引的第二个及以后的字段单独查询用不到索引
.不要使用 select *；会查询全表的数据影响查询效率
排序请尽量使用升序
or 的查询尽量用 union 代替（Innodb）
复合索引高选择性的字段排在前面
order by / groupby 字段包括在索引当中减少排序，效率会更高

SQL 编写时还需要特别注意一下几点：

尽量规避大事务的 SQL，大事务的 SQL 会影响数据库的并发性能及主从同步
分页语句 limit 的问题
删除表所有记录请用 truncate，不要用 delete
不让 mysql 干多余的事情，如计算
输写 SQL 带字段，以防止后面表变更带来的问题，性能也是比较优的 ( 涉及到数据字典解析，请自行查询资料)
在 Innodb上用 select count(*)，因为 Innodb 会存储统计信息
慎用 Oder by rand()

delete和truncate的区别：

delete是DML，执行delete操作时，每次从表中删除一行，并且同时将该行的的删除操作记录在redo和undo表空间中以便进行回滚（rollback）和重做操作，但要注意表空间要足够大，需要手动提交（commit）操作才能生效，可以通过rollback撤消操作
truncate会删除表中所有记录，并且将重新设置高水线和所有的索引，缺省情况下将空间释放到minextents个extent，除非使用reuse storage，。不会记录日志，所以执行速度很快，但不能通过rollback撤消操作（如果一不小心把一个表truncate掉，也是可以恢复的，只是不能通过rollback来恢复）
drop> truncate > delete

表的分割

水平分割：

大数据量的表,我们在提供检索的时候，应该根据业务的需求，找到表的标准，并在检索页面约束用户的检索方式，而且要配合分页

垂直分割：

把某个表的某些字段，这些字段，在查询时候并不关系，但是数据量很大，我们建议将这些字段放到一个表中，从而提高效率

数据库优化方案

1. 优化索引、SQL 语句、分析慢查询

2. 设计表的时候严格根据数据库的设计范式来设计数据库

3. 使用缓存，把经常访问到的数据而且不需要经常变化的数据放在缓存中，能节约磁盘IO

4. 优化硬件；采用SSD，使用磁盘队列技术(RAID0,RAID1,RDID5)等；

5. 采用MySQL 内部自带的表分区技术，把数据分层不同的文件，能够提高磁盘的读取效率

6. 垂直分表；把一些不经常读的数据放在一张表里，节约磁盘I/O

7. 主从分离读写；采用主从复制把数据库的读操作和写入操作分离开来

8. 分库分表分机器（数据量特别大），主要的的原理就是数据路由

9. 选择合适的表引擎，参数上的优化

10. 进行架构级别的缓存，静态化和分布式

11. 不采用全文索引

数据库怎么优化查询效率

1、储存引擎选择：如果数据表需要事务处理，应该考虑使用InnoDB，因为它完全符合ACID特性。如果不需要事务处理，使用默认存储引擎MyISAM是比较明智的

2、分表分库，主从。

3、对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引

4、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描

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

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

7、Update 语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志

8、对于多张大数据量（这里几百条就算大了）的表JOIN，要先分页再JOIN，否则逻辑读会很高，性能很差。

参考原址来自于此