mysql高级特性篇,可以多看看,应付面试

最新推荐文章于 2024-01-25 09:29:53 发布

梵高的猪v

最新推荐文章于 2024-01-25 09:29:53 发布

阅读量278

点赞数

分类专栏：数据库文章标签： mysql mysql优化

本文链接：https://blog.csdn.net/weixin_47303191/article/details/124963614

版权

数据库专栏收录该内容

1 篇文章 0 订阅

订阅专栏

Linux下安装Mysql

1.安装wget

yum -y install wget //安装wget

2.在线安装rpm

[root@dboop1 opt]# wget http://dev.mysql.com/get/mysql57-community-release-el7-10.noarch.rpm

[root@dboop1 opt]# yum -y install mysql57-community-release-el7-10.noarch.rpm

[root@dboop1 opt]# yum -y install mysql-community-server

5.启动mysql服务

[root@dboop1 opt]# systemctl start mysqld

6.检查mysql服务

[root@dboop1 opt]# systemctl status mysqld

7.查询生成的临时密码

[root@dboop1 opt]# cat /var/log/mysqld.log | grep password

8.登录mysql

[root@dboop1 opt]# mysql -uroot -p

9.设置新密码

mysql> set password for root@localhost=password(‘你的密码，要求字母大小写，数字，特殊字符’);

10.退出测试

exit

11.登录，重复8
或者

mysql> mysql -uroot -p登录密码

12.查看数据库用
可以看到，该数据库包含一些基本数据库，我们要用mysql数据库

mysql> show databases;

mysql> use mysql;

mysql> show tables; //可以在mysql数据库中，查看有哪些表

13.设置远程登录权限(注意，在>mysql中任何一条语句都要写上分号结束)
测试，打开Navicat 测试连接，用客户端ip地址连接。

mysql> update user set host = ‘%’ where user=‘root’;

mysql> flush privileges;

14.检查防火墙机制。

[root@dboop1 /]# systemctl status firewalld //若是出现acitve字样，且是绿色的，要将其关闭

systemctl stop firewalld //关闭防火墙 stop改为start变为启动

自行选择一些爱命令

systemctl enable mysqld.server //开机自启动

systemctl disable mysqld.server //开机不启动

SQL优化过程

慢查询的开启并捕获，开启sql一天，查看慢查询日志。
explain+sql语句分析。
show profile，查看执行细节和生命周期情况。
运维和dba进行sql优化。

索引

简介

在一张连续表中，如果我们要查询表中最后一条数据，肯定要从前面一直遍历到后面，效率不高。
但是如果将这张表的数据放在二叉树里，规定左子树比根节点小，右子树比根节点大，查询效率会大大提高。
数据库的索引便应用了这个原理，查询数据的时候从这张表的二叉树结构去查，一旦查到该数据，便通过索引映射出表中的数据。
但是索引也有劣势：因为索引也需要空间，而我们又希望不利用内存，所以我们会存在磁盘中，但是磁盘的空间也会因为索引而增大。其次，降低更新表的速率，每次我们更新表的数据的时候，对应的二叉树结构也要更新，所以就会造成速率降低。

B+Tree

为了继续增大查询效率，引入了B+树，该结构不规定根节点的子节点的个数。

场合

主键自动建立索引
频繁查找某个字段建立索引。
查询与其他表关联的字段，外键建立索引。
频繁更新的字段不适合建立索引，这样反而会降低检索速度。
Where条件里用不到的字段不建立索引。
查询排序的字段，建立索引可以大大提高访问速度。
查询中统计和分组的字段。
表的记录太少，数据差异不大的字段也不适合建立索引。

MysqlQueryOptimizer

mysql自带的性能优化器，该优化器会根据用户发过来的语句进行解析，比如是select，性能优化器将会将这条语句的一些常量表达式进行转化成常量，并对一些查询条件进行简化，然后分析该语句里是否有性能优化的提示（hint），比如索引，如果有，再确定是否可以完全执行该sql语句。反之，会用读取原查询语句的信息，进行查询。

性能瓶颈

cpu饱和，数据装入内存和读出。
IO 装入数据大小远大于内存容量。
硬件设施问题。

explain

使用该关键字可以模拟优化器执行sql语句，从而指导mysql是如何处理的sql语句的，分析你的查询语句或表结构的性能瓶颈。
我们先建立一个数据库叫hyb，然后添加一个表叫t_emp,之后我们用客户端打开，连接mysql，然后输入命令use hyb；使用该数据库，之后explain select * from t_emp 执行，可以看出下列表格。
1.id 代表优化器执行sql语句的优先级，id越高，优先级越高，mysql越先执行，若id相同，从罗列的数据从上往下执行。比如有一条嵌套查询（sql语句里，有括号的先执行，优先级越高），优化器输出的id从上往下为 1 1 2 代表2 的sql先被执行，优先级越高，而1 和 1，则是从最上面的1往下执行。
2.select_type 代表查询语句的类型。查询类型分为：

| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |

simple：简单查询，查询中不包含子查询和联合查询。比如select * from table 便表示一个简单查询。
primary：当有多个子查询的语句时，最外层的查询会被优化器标记为primary。比如select _ from t1 where id=(select id from where …)该复合查询中，最外层的select _ from …会被优化器标记为primary。可以简单的理解为，优化器解析该sql语句中，优先级最低的语句会被标记为primary。
subquery：当有多个子查询的语句时，子查询会被标记为subquery
derived：如select * from id=(select id from …) s1 当存在该子查询，并将标记为s1的临时表，该子查询就会被标记为derived。
union：若第二个select查询语句出现再union之后，会被标记为union。
union result：union后的查询被标记为union result

2.table表示该查询来源那张表。
3.type：system>const>eq_ref>ref>range>index>all 基本这几种类型，从最好到最次排列。all 代表全表扫描。

system：代表表只有一行记录，速度很快，可以忽略不计，在sql优化的工作中，很难达到次效果。
const：表示索引一次就找到了，const长表示unique和primary key的查询。例如，在where字句中有一个id=1的条件，该条件就代表id=1便可以找到了，就需要索引一次，所以会返回type类型为const。
eq_ref：唯一索引扫描，例如：where t1.id=t2.id 如果来自t2这张表只有一条数据与t1的id匹配，该t1就会被表示为eq_ref
ref：非唯一索引扫描，例如where t1.id=t2.id t2的一条id对应t1有多行对应。
range：在where条件里在一定范围的扫描。
index：全索引扫描，比all全局扫描要快，但是该扫描是遍历索引树，all全局是全部遍历。

4.possible_keys：理论上mysql应该使用哪些索引。
5.key：实际上mysql用了哪些索引。查询中若使用到了覆盖索引（覆盖多个字段），则该索引仅出现在key中，possible_keys不会出现。
6.key_len：索引的长度，越短越好，但该长度是最大可能长度，是根据表的定义得到的，而不是实际查询出来的。
7.ref：查找的时候哪些表的哪些列被引用了，有可能是个常量，例如 where t1.id=t2.id and t1.id=1 如果查询t1，ref的值为t2.id const 代表我查询t1的时候要用到t2表里的id，且还有一个const常量的条件。
8.rows：每张表有多少行被优化过。比如我们没建索引之前执行查询所有的查询语句，rows会代表全部行，而建立的索引后，rows只会显示被优化的行。
9.extra：额外信息，可以显示使用了哪些关键字，使用了哪些排序。

Using filesort：原给的排序过程不完美，系统自身建立了一个排序，出现该字样说明我们该优化sql语句了。
Using temporary：原给的sql语句不完美，出现了临时表，该结果比Using filesort更严重。
Using index：表明sql语句用了覆盖索引，性能不错。如果还存在Using Where表明进行查找和读取，反之只用来读取。覆盖索引：例如你为两列建立了复合索引，而你的查询语句刚好也只是查询这两列。
Using join buffer：使用了连接缓存，jion关键字过多。
impossible where：不可能的where的子句，比如where id = 1 and id=2
selecte tables optimized away ：在没有group by关键字的条件下，对一些max min count等函数进行优化，不必等到执行时候进行计算。
distinct ：优化区分操作，表示查询第一个数据后，不再查询其相同的。

优化案例规则

单表查询，加复合索引的时候不应该加在变化的量上，如我们要求where字句里有age大于某个值的时候，这个age最好不要加索引。因为根据b树的原理，age大于某个值就会一直往下找去，没有确定真实值。
两表查询，若是左连接最好将索引加在右表，又连接最好将索引加在左表上。
join语句总结：尽量避免嵌套查询，永远用小表驱动大表，左连接将索引加在右表，右连接加在坐标，若有多个连接，可以多次添加索引。

案例一

select * from t1 where id=1 and name=‘a’ and age=10;此句sql语句，我们为其添加索引在id，name，age列上，即复合索引。该sql遵循左前缀法则，即当我们为where字句后的属性建立了复合索引后，不能删除使用任何一个索引的属性的前一个条件。比如：不能删除id=1的条件而保留后者，如果是这样，任何索引都会失效。同样的，如果删除name=‘a’的条件，该条件的后面所有条件使用的索引都会失效，而该条件的前者索引不会失效。
不要在索引列上做任何的计算，类型转换，or等操作。
- 例如：select _ form where name=‘hyb’;和select _ from where left(name,3)=‘hyb’;两者的结果都是一样的，但是后者加上了计算，就会导致全表扫描。
在有范围条件后面的列建立索引会失效，但范围条件本身的索引不失效。例如：select * from where name=‘hyb’ and age>10 and id=1 在这里id=1的索引会失效。
尽量不适用_来检索。例如：select _ from where name=‘hyb’ and age>10 and id=1 这里的id=1的索引会失效，效率低，而如果我们将*替换成name,age,id…等其表中包含的所有字段，extra会比原来多增加了一个using index性能大大提高。
mysql在使用不等于（!=或者<>）的时候，会导致索引失效。select * from where id!=1;
mysql在使用null 或者is null的时候也无法使用索引。
like关键字使用注意：使用%的时候如果只出现在右边（name%），效率最高，索引不会失效，其他位置会失效；但是在工作中，有时候%一定要用在左边或者左右两边都有，这个时候可以通过覆盖索引去解决这个问题。比如：select name,age where like name=‘%h%’ ,我们只需要在name和age字段上同时建立索引（覆盖索引）就可以解决该索引失效的问题，但值得注意的是：如果select关键字后你用的字段不是覆盖索引的字段或者字段数量超过覆盖索引中字段的数量，该查询的索引会失效。例如:select * from where like=…,select name,age,email where like … 都会使得覆盖索引失效，而select name where like …使用到覆盖索引的字段小于覆盖索引总字段数量，该查询索引不失效。
字符串不加引号索引会失效。例如:select * from where name=‘2000’，在MySQL中name=2000，也是可以通过编译的，但我们原类型就是字符串类型，如果直接name=2000，会造成索引失效。
少用or，用or会导致索引失效。

注意点

select _ from t1 where c1=‘j’ and c2=‘a’ and c4>10 and c3=‘o’;该语句中任何一个索引都不会失效，使用到四个索引，虽然说范围以后的索引都会失效，但是在mysql底层中，会进行性能优化，其会将语句排序为：select _ from t1 where c1=‘j’ and c2=‘a’ and c3=‘o’ and c4>10 即使范围后索引全失效，但是c4>10后面就没有条件了，索引该语句使用的索引还是四个。
select _ from t1 where c1=‘j’ and c2=‘a’ and c4=‘p’ order by c3;sql底层为select _ from t1 where c1=‘j’ and c2=‘a’ order by c3 and c4=‘p’ ;order by不失效，但在表格中不显示，c4索引失效，因为order by的出现。
select * from t1 where c1=‘j’ and c2=‘a’ order by c4;出先断层，extra 里出现using filesort，MySQL内部产生文件排序，效率降低。
select _ from t1 where c1=‘j’ and c2=‘a’ order by c3,c2；理论上，mysql内部会有filesort，但实际上不会出现filesort，因为order by里的字段c2，在c2=‘a’ 已经被定义为常量，排序失效，所以sql表面的排序相当于1，2，3;但如果select _ from t1 where c1=‘j’ order by c3,c2；则会出现using filesort。关键group by和order by的排序和索引优化原则一致，但要注意group by关键字后还有having关键字，而且其在排序的过程中会出现临时表。
select * from t1 where c1=‘j’ and c2 like=‘a%’ and c3=‘g’ and c4 like=‘k%kk%’;该c2索引不会失效，c3索引也不会失效，c4索引也不会失效，同c2原理一样，因为a或k作为开头已经给定。但如果c2 like=‘%a’或者c2 like=’%a%’ c2本身索引会失效，c3索引也会失效。

小表驱动大表

select * from A where id in(select id from B) 当B的数据集小于A表时，用in比exists更优。
当B的数据集大于A表时，用exists更优，可更改为select * from where exists (select 1 from B where B.id=A.id)，该语句中select 1会被系统忽略。exists：将主查询的数据放在子查询中做验证，判断是否满足，返回true或者false。所以，select 1中的1可以修改为其他值。

order by关键字性能分析

假设表中有两个字段age，birth。那么如果出现order by birth，order by birth,age则会出现using filesort排序。如果出现order by age asc birth desc 也会出现using filesort因为order by默认是升序排序的,而你突然升序排序和降序排序，就会导致效率变差。如果同时升序，或者同时降序则不会出现using filesort。
所以order by关键字要提升效率，必须遵循左前缀法则。
下面总结索引失效的几种order by情况
- order by a asc ，b desc //出现升降排序
- where g=const orde by b,c //丢失索引a
- where a=const orde by c //丢失索引b
- where a=const order by a,d //d本身不是索引的一部分，该索引失效，但是a索引失效
- where a in(…) order by b,c //丢失索引a
如果where 中使用最左前缀索引，则order by能使用索引
- where a=const order by b,c
- where a=const and b>const order by b,c

慢查询日志

配置

慢查询日志是一种查看sql语句效率慢的手段。它用来记录哪一条sql语句超出了阙值long_query_time（默认值10秒）。
mysql默认没有开启慢查询日志，除非需要调优的时候。
show variables like ‘%slow_query_log%’; 语句可查询是否开启慢日志查询，默认OFF不开启，ON表示为开启。

±--------------------±-------------------------------+
| Variable_name | Value |
±--------------------±-------------------------------+
| slow_query_log | OFF |
| slow_query_log_file | /var/lib/mysql/dboop1-slow.log |
±--------------------±-------------------------------+

set global slow_query_log=1;可开启慢日志查询。只对当前mysql有效，如果重启后会无效。
如果非得要永久生效，修改my.cnf配置文件
该文件系统默认给主机名.log

slow_query_log=1

slow_query_log_file=/var/lib/mysql/文件名.log

log_query_time=value

log_output=FILE

修改默认阙值：set global long_query_time = value;
修改完毕后，如果用show variables like ‘%long_query_time%’;查询，会查询不到修改后的值，只能重启mysql。而使用show global variables like ‘%long_query_time%’;则可以直接查询，不用重启mysql。
使用select sleep(时间);可查询超过阙值的sql语句，注意，该时间参数一定要超出阙值才可以查询出。然后到相应文件就可以查找出相应的sql语句。

mysqldumpslow

这是mysql官方提供的一款慢查询sql工具。
mysqldumpslow --help 可查看该工具的帮助信息。cd /var/lib/mysql 进入该mysql目录下输入该命令便有效。
mysqldumpslow -s r -t 10 /var/lib/mysql/dboop1-slow.log 表示得到返回记录集最多的10个sql

Usage: mysqldumpslow [ OPTS… ] [ LOGS… ]

Parse and summarize the MySQL slow query log. Options are

–verbose verbose
–debug debug
–help write this text to standard output

-v verbose
-d debug
-s ORDER what to sort by (al, at, ar, c, l, r, t), ‘at’ is default
al: average lock time
ar: average rows sent
at: average query time
c: count
l: lock time
r: rows sent
t: query time
-r reverse the sort order (largest last instead of first)
-t NUM just show the top n queries
-a don’t abstract all numbers to N and strings to ‘S’
-n NUM abstract numbers with at least n digits within names
-g PATTERN grep: only consider stmts that include this string
-h HOSTNAME hostname of db server for -slow.log filename (can be wildcard),
default is '', i.e. match all
-i NAME name of server instance (if using mysql.server startup script)
-l don’t subtract lock time from total time

s 表示按照何种方式排序

c：访问次数

l：锁定时间

r：返回记录

t：查询时间

al：平均锁定时间

ar：平均返回记录数

at：平均查询时间

t ：返回前面多少条记录数，搭配数量

g：后面搭配一个正则匹配模式，大小写不敏感。

Profile

是mysql官方提供了可以分析当前会话语句的资源消耗情况，可以用于sql语句的调优测量。
默认不开启，输入命令show variables like ‘profiling’;可查看profile的状态：

±--------------±------+
| Variable_name | Value |
±--------------±------+
| profiling | OFF |
±--------------±------+

输入set profiling=on;可对该功能进行开启。
show profiles;可查看刚才执行过sql语句情况。

±---------±-----------±--------------------------------+
| Query_ID | Duration | Query |
±---------±-----------±--------------------------------+
| 1 | 0.00177275 | show variables like ‘profiling’ |
| 2 | 0.00025000 | select * from t_emp |
±---------±-----------±--------------------------------+

这样，我们就可以根据每条sql语句的id来进行更深入的分析，比如这里我们选择2，输入命令 show profile cpu,block io for query 2;
这样子，坏。

±---------------------±---------±---------±-----------±-------------±--------------+
| Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
±---------------------±---------±---------±-----------±-------------±--------------+
| starting | 0.000069 | 0.000008 | 0.000057 | 0 | 0 |
| checking permissions | 0.000014 | 0.000001 | 0.000009 | 0 | 0 |
| Opening tables | 0.000018 | 0.000003 | 0.000016 | 0 | 0 |
| init | 0.000016 | 0.000002 | 0.000013 | 0 | 0 |
| System lock | 0.000007 | 0.000000 | 0.000007 | 0 | 0 |
| optimizing | 0.000004 | 0.000001 | 0.000003 | 0 | 0 |
| statistics | 0.000011 | 0.000001 | 0.000009 | 0 | 0 |
| preparing | 0.000009 | 0.000001 | 0.000008 | 0 | 0 |
| executing | 0.000003 | 0.000001 | 0.000002 | 0 | 0 |
| Sending data | 0.000036 | 0.000004 | 0.000032 | 0 | 0 |
| end | 0.000004 | 0.000001 | 0.000003 | 0 | 0 |
| query end | 0.000006 | 0.000000 | 0.000006 | 0 | 0 |
| closing tables | 0.000006 | 0.000001 | 0.000005 | 0 | 0 |
| freeing items | 0.000036 | 0.000005 | 0.000032 | 0 | 0 |
| cleaning up | 0.000013 | 0.000001 | 0.000011 | 0 | 0 |
±---------------------±---------±---------±-----------±-------------±--------------+

上面的show profile cpu…等语句是常用的分析每条sql的语句，但除了分析cpu,block等几个选项，还可以分析其他选项

ALL --显示所有的开销信息

block io --显示块io的具体信息

context switches --上下文切换相关开销

cpu --cpu资源消耗情况

ipc --显示发送和接受的资源消耗信息

memory --显示内存的开销的信息

page faluts --显示页面错误相关开销信息

source --显示和Source_function,Source_line,Source_file 相关的开销信息

全局查询日志

该方式也是用来查询sql的运行情况，但仅限用于测试环境下使用。
1，通过配置文件设置，在my.cnf文件中配置如下

general_log=1

general_log_file=保存路径

log_output=FILE //输入格式

2，输入命令set global general_log=1;set global log_output ‘TABLE’;开启全局日志和设置全局日志的输入格式为一张表格。
3，输入命令select * from mysql.general_log;可查看全局日志情况。

锁

简介

锁是一种计算机用来协调线程和多进程并发访问的一种机制。
数据库也是一种共享的数据中心，日常开发中必须满足其高并发的需求，如何保障数据并发访问的一致性和高效性，是数据库必须解决的一个问题。

步骤

表锁

show open tables; 可查看当前数据库中哪些表有锁，主要看返回的表格中In_Use这一项，为0代表没有。
lock table table_name_1 read/write,tabel_name_2 read/write…给某张表huo多张表上锁。
unlock tables;可以将所有表中的锁去掉。
如果a表进行读锁，当前客户端对a表只能进行读操作，插入和更新等操作对a表不起作用，且当前客户端不能对其他没有锁的表进行查询操作。这时，若是另外开一个客户端，该客户端也可以查询a表的记录，但对a表进行更新和插入等操作却要一直等待，直到a表中的锁释放。
如果对a表进行了写锁，当前客户端可以对该表进行读写操作，不能对其他表进行读操作；‘如果另开一个客户端，该客户端可以读没有锁的表，如果读有锁的表，会阻塞，直到a表的锁释放。
简而言之，读锁会阻塞写，而不会阻塞读，而写锁则会将读写都阻塞。

行锁

开启两个客户端a,b，使用命令set autocommit=0；都设置成自动提交。如果a对表c进行操作，没有提交之前，再查看c表，是可以查询到操作后的数据变化的，这个时候，b来查看表c，是看不出变化的，因为a对表c的更改没有commit，只对自己可见，这就是行锁，而一旦将事务提交，b便可以查看表c的变化。
我们再来测试，如果a和b都对c表同样的数据进行操作，会发现，一旦有客户端执行过一次语句，其他客户端便不可以再执行，只有第一次执行的客户端将该操作commit之后才可以修改，这也是行锁的一个特性。
我们再来测试，a和b修改c中不同的数据，无论哪个先执行，发现都是可以修改的，这也是行锁的一个特性。
总的来说，行锁的特点如下：会出现死锁，但是细节成度更高，并发操作更加容易，发生锁的冲突比表锁低。
另外的，行锁是偏向于InnoDB存储引擎的，该引擎不仅支持事务，而且支持行锁，而表锁是基于**MyISAM** 存储引擎，开销小，加锁快，无死锁，锁定粒度大，发生锁冲突的概率最高，并发度最低，所以InnoDB多偏于写操作，而MyISAM多偏向于读操作。

查看锁

show open tables；可查看哪些表被上锁。
show status like ‘table%’;可查看锁的锁定情况。
- Table_locks_immediate；产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁加1.
- Table_locks_waited；出现表锁竞争而出现等待的次数。

索引失效

前面说过很多种索引失效的情况，下面请看该语句
无论a或b是整型还是字符串类型效果都是一样，而如果a和b都是字符串类型，你就写成了整型就会导致索引失效。

UPDATE test_innodb_lock SET a = 888 WHERE b = 8000;

我们执行上面那条sql语句。执行成功，但未提交。此刻，打开另一个客户端，随便执行一条sql语句，会发现被阻塞了，这种情况不正常，因为这是行锁级别，对其他sql操作肯定不影响。造成这种情况原因是因为，你执行了上面的sql语句之后，索引失效，行锁会变成表锁，这是一种严重的错误。

间隙锁

当我们用范围条件而不是相等条件检索数据，并请求共享或者排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁，对于键值在条件范文内但并不存在的记录，叫做"间隙(GAP)“。
InnoDB也会对这个"间隙"加锁，这种锁的机制就是所谓的"间隙锁”。
例如：在一个客户端执行一条sql语句，带有where 条件age>1 and age<6；而实际的表中没有age=2这个数据，这个时候，InnoDB也会将age=2这行数据加上行锁，而我们开启另一个客户端的为age=2这行插入一条数据的时候，会造成阻塞。只有当前面执行的sql语句commit之后，该阻塞就会被释放。

设置锁

在sql语句后面加上for update可以为某一行上锁，比如where a=8 for update 为该a=8这一行上锁，这时其他客户端修改该行只能在客户端释放锁（commit）之后才能进行。

行锁总结

SHOW STATUS LIKE ‘innodb_row_lock%’;可查看行锁分析
対各个状态量的说明如下：

mysql> SHOW STATUS LIKE ‘innodb_row_lock%’;
±------------------------------±-------+
| Variable_name | Value |
±------------------------------±-------+
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 124150 |
| Innodb_row_lock_time_avg | 31037 |
| Innodb_row_lock_time_max | 51004 |
| Innodb_row_lock_waits | 4 |
±------------------------------±-------+
5 rows in set (0.00 sec)

**Innodb_row_lock_current_waits**：当前正在等待锁定的数量
**Innodb_row_lock_time**：从系统启动到现在锁定总时间长度（重要）
**Innodb_row_lock_time_avg**：每次等待所花的平均时间（重要）
**Innodb_row_lock_time_max**：从系统启动到现在等待最长的一次所花的时间
**Innodb_row_lock_waits**：系统启动后到现在总共等待的次数（重要）

尤其是当等待次数很高，而且每次等待时长也不小的时候，我们就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手制定优化策略。

优化建议

尽可能让所有数据检索都通过索引来完成，避免五索引行锁升级为表锁
合理设计索引，计量缩小所的范围
尽可能较少检索条件，避免间隙锁
尽量控制事务大小，减少锁定资源量和时间长度
尽可能低级别事务隔离

主从复制

MySQL复制过程分为三步：

Master将改变记录到二进制日志(Binary Log)。这些记录过程叫做二进制日志事件，Binary Log Events；
Slave将Master的Binary Log Events拷贝到它的中继日志(Replay Log);
Slave重做中继日志中的事件，将改变应用到自己的数据库中。MySQL复制是异步且串行化的。
下面演示主机为windows从机linux的sql主从复制：
- 首先，用ping命令分别在linux系统和windows系统进行ping各自的ip地址，若能ping通进行下一步。