MySQL性能优化

SQL语句优化-explain分析问题      

Explanin select * from user

会产生如下信息：

id:查询的序列号
select_type:表示查询的类型。
table:输出结果集的表
type:表示表的连接类型
possible_keys:表示查询时，可能使用的索引
key:表示实际使用的索引
key_len:索引字段的长度
ref: 哪个字段或常数与 key 一起被使用
rows:扫描出的行数
Extra:执行情况的描述和说明

select_type列说明

SIMPLE, 表示此查询不包含 UNION 查询或子查询

PRIMARY, 表示此查询是最外层的查询

UNION, 表示此查询是 UNION 的第二或随后的查询

DEPENDENT UNION, UNION 中的第二个或后面的查询语句, 取决于外面的查询

UNION RESULT, UNION 的结果

SUBQUERY, 子查询中的第一个 SELECT

DEPENDENT SUBQUERY: 子查询中的第一个 SELECT, 取决于外面的查询. 即子查询依赖于外层查询的结果.

type列说明

通常来说, 不同的 type 类型的性能关系如下:

ALL < index < range~index_merge < ref < eq_ref < const < system

MySQL性能优化之慢查询

介绍

数据库查询快慢是影响项目性能的一大因素，对于数据库，我们除了要优化 SQL，更重要的是得先找到需要优化的 SQL。

MySQL 数据库有一个“慢查询日志”功能，用来记录查询时间超过某个设定值的SQL，这将极大程度帮助我们快速定位到症结所在，以便对症下药。

MySQL的慢查询日志功能，默认是关闭的，需要手动开启。

性能优化思路

1. 首先需要使用慢查询功能，去获取所有查询时间比较长的SQL语句
2. 其次使用explain命令去查看有问题的SQL的执行计划
3. 最后使用show profile [s] 查看有问题的SQL的性能使用情况

开启慢查询功能

查看是否开启慢查询功能

 临时开启慢查询功能

在 MySQL 执行 SQL 语句设置，但是如果重启 MySQL 的话将失效

set global slow_query_log = ON;

set global long_query_time = 1;

永久开启慢查询功能

修改/etc/my.cnf配置文件，重启 MySQL, 这种永久生效.

[mysqld]

slow_query_log = ON

slow_query_log_file = /var/log/mysql/slow.log

long_query_time = 1

SQL语句优化-show参数 

MySQL客户端连接成功后，通过使用show [session|global] status 命令可以提供服务器状态信息。其中的session来表示当前的连接的统计结果，global来表示自数据库上次启动至今的统计结果。默认是session级别的。默认的情况下，MYSQL的该功能没有打开，需要自己手动启动。

语句使用

show profile 和 show profiles 语句可以展示当前会话中执行语句的资源使用情况.

show profiles :以列表形式显示最近发送到服务器上执行的语句的资源使用情况.显示的记录数由变量:profiling_history_size 控制,默认15条

show profile: 展示最近一条语句执行的详细资源占用信息,默认显示 Status和Duration两列

开启Profile功能

Profile 功能由MySQL会话变量 : profiling控制,默认是OFF关闭状态。

查看是否开启了Profile功能:

select @@profiling;

show variables like ‘%profil%’;

 开启profile功能

set profiling=1; --1是开启、0是关闭

MySQL性能优化细节

1. 合理的创建及使用索引（考虑数据的增删情况）
2. 合理的冗余字段（尽量建一些大表，考虑数据库的三范式和业务设计的取舍）
3. 使用SQL要注意一些细节：select语句中尽量不要使用*、count(*)，WHERE语句中尽量不要使用1=1、in语句（建议使用exists）、注意组合索引的创建顺序按照顺序组着查询条件、尽量查询粒度大的SQL放到最左边、尽量建立组合索引
4. 合理利用慢查询日志、explain执行计划查询、show profile查看SQL执行时的资源使用情况。

MySQL锁 

锁介绍

数据库锁定机制简单来说就是数据库为了保证数据的一致性而使各种共享资源在被并发访问访问变得有序所设计的一种规则。

对于任何一种数据库来说都需要有相应的锁定机制，所以MySQL自然也不能例外。

MySQL数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别。

MySQL各存储引擎使用了三种类型（级别）的锁定机制：行级锁定，页级锁定和表级锁定。

按照锁的粒度来分：行级锁和表级锁

按照锁的功能来分：共享读锁和排他写锁

行级锁定（row-level）

行级锁定最大的特点就是锁定对象的颗粒度很小，也是目前各大数据库管理软件所实现的锁定颗粒度最小的。由于锁定颗粒度很小，所以发生锁定资源争用的概率也最小，能够给予应用程序尽可能大的并发处理能力而提高一些需要高并发应用系统的整体性能。

虽然能够在并发处理能力上面有较大的优势，但是行级锁定也因此带来了不少弊端。由于锁定资源的颗粒度很小，所以每次获取锁和释放锁需要做的事情也更多，带来的消耗自然也就更大了。此外，行级锁定也最容易发生死锁。

表级锁定（table-level）

和行级锁定相反，表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。

当然，锁定颗粒度大所带来最大的负面影响就是出现锁定资源争用的概率也会最高，致使并大度大打折扣。

页级锁定（page-level）

页级锁定是MySQL中比较独特的一种锁定级别，在其他数据库管理软件中也并不是太常见。页级锁定的特点是锁定颗粒度介于行级锁定与表级锁之间，所以获取锁定所需要的资源开销，以及所能提供的并发处理能力也同样是介于上面二者之间。另外，页级锁定和行级锁定一样，会发生死锁。

MySQL这3种锁的特性可大致归纳如下

• 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低；
• 行级锁：开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高；
• 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。