技术技巧---MYSQL常用命令

1、mysqldump

导出数据：mysqldump -h localhost -u root -p  -P 17538  --single-transaction --databases taoge --tables x > x1.sql
其中taoge是db名， x是table名， x1.sql是导出文件。
导入数据方式一(先创建新的db taoge1)：
mysql -h localhost -u root -p  -P 17538  --database taoge1 < x1.sql
其中taoge1是导入的目标db名， x1.sql是待导入的文件，也就是把x1.sql中的table x导入到taoge1这个db中去。        
导入数据方式二(先创建新的db taoge1):
在mysql中进行操作， use taoge1; 然后source /home/ubuntu/x1.sql

2、MYSQL存储引擎

可以根据以下的原则来选择 MySQL 存储引擎：
如果要提供提交、回滚和恢复的事务安全（ACID 兼容）能力，并要求实现并发控制，InnoDB 是一个很好的选择。
如果数据表主要用来插入和查询记录，则 MyISAM 引擎提供较高的处理效率。
如果只是临时存放数据，数据量不大，并且不需要较高的数据安全性，可以选择将数据保存在内存的 MEMORY 引擎中，MySQL 中使用该引擎作为临时表，存放查询的中间结果。
如果只有 INSERT 和 SELECT 操作，可以选择Archive 引擎，Archive 存储引擎支持高并发的插入操作，但是本身并不是事务安全的。Archive 存储引擎非常适合存储归档数据，如记录日志信息可以使用 Archive 引擎。
提示：使用哪一种引擎要根据需要灵活选择，一个数据库中多个表可以使用不同的引擎以满足各种性能和实际需求。使用合适的存储引擎将会提高整个数据库的性能。

3、MYSQL初始化

./mysqld --defaults-file=/etc/my.cnf  --datadir=/data/mysql/ --user=mysql --initialize

4、MYSQL索引

索引的使用原则和注意事项
虽然索引可以加快查询速度，提高 MySQL 的处理性能，但是过多地使用索引也会造成以下弊端：
创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。
除了数据表占数据空间之外，每一个索引还要占一定的物理空间。如果要建立聚簇索引，那么需要的空间就会更大。
当对表中的数据进行增加、删除和修改的时候，索引也要动态地维护，这样就降低了数据的维护速度。
注意：索引可以在一些情况下加速查询，但是在某些情况下，会降低效率。
索引只是提高效率的一个因素，因此在建立索引的时候应该遵循以下原则：
在经常需要搜索的列上建立索引，可以加快搜索的速度。
在作为主键的列上创建索引，强制该列的唯一性，并组织表中数据的排列结构。
在经常使用表连接的列上创建索引，这些列主要是一些外键，可以加快表连接的速度。
在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，所以其指定的范围是连续的。
在经常需要排序的列上创建索引，因为索引已经排序，所以查询时可以利用索引的排序，加快排序查询。
在经常使用 WHERE 子句的列上创建索引，加快条件的判断速度。
与此对应，在某些应用场合下建立索引不能提高 MySQL 的工作效率，甚至在一定程度上还带来负面效应，降低了数据库的工作效率，一般来说不适合创建索引的环境如下： 
对于那些在查询中很少使用或参考的列不应该创建索引。因为这些列很少使用到，所以有索引或者无索引并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度，并增大了空间要求。
对于那些只有很少数据值的列也不应该创建索引。因为这些列的取值很少，例如人事表的性别列。查询结果集的数据行占了表中数据行的很大比例，增加索引并不能明显加快检索速度。
对于那些定义为 TEXT、IMAGE 和 BIT 数据类型的列不应该创建索引。因为这些列的数据量要么相当大，要么取值很少。
当修改性能远远大于检索性能时，不应该创建索引。因为修改性能和检索性能是互相矛盾的。当创建索引时，会提高检索性能，降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能 时，不应该创建索引。

5、MYSQL表备份恢复

备份：SELECT INTO OUTFILE
mysql> SELECT * FROM test_db.tb_students_info
   -> INTO OUTFILE 'C:/ProgramData/MySQL/MySQL Server 5.7/Uploads/file.txt'
   -> FIELDS TERMINATED BY '"'
   -> LINES TERMINATED BY '?';
恢复：LOAD DATA INFILE
mysql> LOAD DATA INFILE 'C:/ProgramData/MySQL/MySQL Server 5.7/
Uploads/file.txt'
   -> INTO TABLE test_db.tb_students_copy
   -> FIELDS TERMINATED BY ','
   -> OPTIONALLY ENCLOSED BY '"'
   -> LINES TERMINATED BY '?';

6、MYSQL my.cnf文件配置

（1）查找my.cnf配置文件路径：
mysqld --verbose --help |grep -A 1 'Default options'
（2）打开my.cnf
port = 3306：指定了Mysql开放的端口；
basedir = /usr/local/mysql：指定Mysql安装的绝对路径；
datadir = /data/mysql_db_data：指定Mysql数据存放的绝对路径；
socket = /tmp/mysql.sock：套接字文件;
plugin_dir = /usr/local/mysql/lib/plugin：mysql中plugin插件所在的路径；
log-error = /data/mysql_db/data/error.log：mysql生成的错误日志存放的路径，它是一个文本文件，遇到有什么问题想查看日志时可以到这个文件里去找线索；
symbolic-links = 0：符号连接，如果设置为1，则mysql数据库和表里的数据支持储存在datadir目录之外的路径下，默认都是0（较新版本的mysql下默认是1）；
local-infile = 0：设置为0表示关闭服务器从本地load的功能，设置为1则打开；
max-connections = 320：设置Mysql的最大连接数；如果实际应用中，并发的连接数量比较大，可以适当的调高此参数，但是，也不是说越高越好，因为这牵涉到服务器的机器硬件的性能。
query_cache_limit = 4M：指定单个查询可以使用的缓冲区的大小，一般默认值是1M；
query_cache_size = 64M：查询的缓存大小设置；
query_cache_type = 1：设置缓存的类型，有以下几种设置方法：设置成0，表示禁用缓存；设置成1，表示缓存所有结果；设置成2，表示只缓存在select语句中通过SQL_CACHE指定需要缓存的查询；
max_user_connections = 320：用户连接数的最大值设置，有时候会出现：“has more than max_user_connections active connections”的错误，不一定是该参数的设置个数不够，有时候需要从代码里找原因，查看是否连接结束后及时断开；
wait_timeout = 9000：超时等待时间，单位秒，即一个connection在若干秒内无响应，则服务器切断与这个客户端的连接；
connect_timeout = 20：客户端与服务器建立连接时，服务器返回错误的握手协议前，等待数据包到来的最大时间，单位秒；
thread_cache_size = 256：用于缓存空闲的线程；
key_buffer_size = 16M：用于指定索引缓冲区的大小；
join_buffer_size = 2M：查询语句中如果较多次使用join查询时，可适当增大该参数，默认2M，如果几乎不怎么用join进行查询，可不予理会；
max_heap_table_size = 16M：指定用户可创建内存表的大小；
low_priority_updates = 1：设置服务器降低写操作的优先级，设置为1表示以读为主；
max_allowd_packet = 128M：设置一次消息传输的最大值；
max_seeks_for_key = 100：设置基于key查询允许的最大查找次数；
sort_buffer_size = 16M：通过增加该值的大小可以提高查询中使用“group by”和“order by”的性能；
read_buffer_size = 16M：设置服务器读缓冲区的大小；
max_connect_errors = 10：客户端连接服务器在没有成功时就被阻断了，累计后超过这个设置的值时，服务器将阻止该客户端后续的所有访问；
myisam_sort_buffer_size = 64M：服务器重建索引时允许建立的最大临时文件的大小；
tmp_table_size = 64M：设置临时内部堆积表（Heap）的大小；
read_rnd_buffer_size = 1M：设置服务器随机读取缓冲区的大小；
open_file_limit = 6050：控制文件打开的个数；

7、SQL 执行分析（执行时间分析）

（1）通过 show processlist 来查看系统的执行情况
（2）通过 profiling 来进行查看：
查看profiling是否开启：select @@profiling;
打开工具：set profiling=1;
查看SQL的执行时间：show profiles;
查看SQL执行耗时详细信息：show profile for query Query_ID；
以上具体的信息都是从 INFORMATION_SCHEMA.PROFILING 这张表中取得的。这张表记录了所有的各个步骤的执行时间及相关信息。语法：select * from INFORMATION_SCHEMA.PROFILING where query_id = Query_ID;
（3）慢查询日志，MySQL 的慢查询日志，顾名思义就是把执行时间超过设定值（默认为10s）的 SQL 记录到日志中。这项功能需要手动开启，但是开启后会造成一定的性能损耗。
查看慢日志是否开启：默认情况下slow_query_log的值为OFF，表示慢查询日志是禁用的，可以通过设置slow_query_log的值来开启。语法：set global slow_query_log=1
设置超时时间：设置语法：set global long_query_time=4，查看语法：show variables like ‘long_query_time’注意：修改后，需要重新连接或新开一个会话才能看到修改值。
永久生效，修改 my.cnf slow_query_log=1 long_query_time=10 slow_query_log_file=/path/mysql_slow.log
其他参数：
log_output：参数是指定日志的存储方式。log_output=‘FILE’表示将日志存入文件，默认值是’FILE’。log_output='TABLE’表示将日志存入数据库，这样日志信息就会被写入到mysql.slow_log表中。MySQL数据库支持同时两种日志存储方式，配置的时候以逗号隔开即可，如：log_output=‘FILE,TABLE’。日志记录到系统的专用日志表中，要比记录到文件耗费更多的系统资源，因此对于需要启用慢查询日志，又需要能够获得更高的系统性能，那么建议优先记录到文件。
log-queries-not-using-indexes：未使用索引的查询也被记录到慢查询日志中（可选项）。如果调优的话，建议开启这个选项。另外，开启了这个参数，其实使用full index scan的sql也会被记录到慢查询日志。
log_slow_admin_statements：表示是否将慢管理语句例如ANALYZE TABLE和ALTER TABLE等记入慢查询日志
分析工具 mysqldumpslow
MySQL 提供了慢日志分析工具 mysqldumpslow。
-s 表示按照何种方式排序；
c: 访问计数
l: 锁定时间
r: 返回记录
t: 查询时间
al:平均锁定时间
ar:平均返回记录数
at:平均查询时间
-t 是top n的意思，即为返回前面多少条的数据；
-g 后边可以写一个正则匹配模式，大小写不敏感的；

8、SQL 执行分析（执行情况分析）

explain执行计划包含的信息：其中最重要的字段为：id、type、key、rows、Extra
各字段详解：
id：select查询的序列号，包含一组数字，表示查询中执行select子句或操作表的顺序三种情况： 
1、id相同：执行顺序由上至下 
2、id不同：如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行 
3、id相同又不同（两种情况同时存在）：id如果相同，可以认为是一组，从上往下顺序执行；在所有组中，id值越大，优先级越高，越先执行 
select_type：查询的类型，主要是用于区分普通查询、联合查询、子查询等复杂的查询
1、SIMPLE：简单的select查询，查询中不包含子查询或者union 
2、PRIMARY：查询中包含任何复杂的子部分，最外层查询则被标记为primary 
3、SUBQUERY：在select 或 where列表中包含了子查询 
4、DERIVED：在from列表中包含的子查询被标记为derived（衍生），mysql或递归执行这些子查询，把结果放在零时表里 
5、UNION：若第二个select出现在union之后，则被标记为union；若union包含在from子句的子查询中，外层select将被标记为derived 
6、UNION RESULT：从union表获取结果的select 
type：访问类型，sql查询优化中一个很重要的指标，结果值从好到坏依次是：
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
一般来说，好的sql查询至少达到range级别，最好能达到ref
1、system：表只有一行记录（等于系统表），这是const类型的特例，平时不会出现，可以忽略不计
2、const：表示通过索引一次就找到了，const用于比较primary key 或者 unique索引。因为只需匹配一行数据，所有很快。如果将主键置于where列表中，mysql就能将该查询转换为一个const 
3、eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键 或 唯一索引扫描。 
注意：ALL全表扫描的表记录最少的表如t1表
4、ref：非唯一性索引扫描，返回匹配某个单独值的所有行。本质是也是一种索引访问，它返回所有匹配某个单独值的行，然而他可能会找到多个符合条件的行，所以它应该属于查找和扫描的混合体 
5、range：只检索给定范围的行，使用一个索引来选择行。key列显示使用了那个索引。一般就是在where语句中出现了bettween、<、>、in等的查询。这种索引列上的范围扫描比全索引扫描要好。只需要开始于某个点，结束于另一个点，不用扫描全部索引
6、index：Full Index Scan，index与ALL区别为index类型只遍历索引树。这通常为ALL块，应为索引文件通常比数据文件小。（Index与ALL虽然都是读全表，但index是从索引中读取，而ALL是从硬盘读取） 
7、ALL：Full Table Scan，遍历全表以找到匹配的行 
possible_keys：查询涉及到的字段上存在索引，则该索引将被列出，但不一定被查询实际使用
key：实际使用的索引，如果为NULL，则没有使用索引。 查询中如果使用了覆盖索引，则该索引仅出现在key列表中。
key_len：表示索引中使用的字节数，查询中使用的索引的长度（最大可能长度），并非实际使用长度，理论上长度越短越好。key_len是根据表定义计算而得的，不是通过表内检索出的
ref：显示索引的那一列被使用了，如果可能，是一个常量const。
rows：根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数
Extra：不适合在其他字段中显示，但是十分重要的额外信息
1、Using filesort ： mysql对数据使用一个外部的索引排序，而不是按照表内的索引进行排序读取。也就是说mysql无法利用索引完成的排序操作成为“文件排序” 
2、Using temporary： 使用临时表保存中间结果，也就是说mysql在对查询结果排序时使用了临时表，常见于order by 和 group by 
3、Using index： 表示相应的select操作中使用了覆盖索引（Covering Index），避免了访问表的数据行，效率高 
如果同时出现Using where，表明索引被用来执行索引键值的查找
如果没用同时出现Using where，表明索引用来读取数据而非执行查找动作 
覆盖索引（Covering Index）：也叫索引覆盖。就是select列表中的字段，只用从索引中就能获取，不必根据索引再次读取数据文件，换句话说查询列要被所建的索引覆盖。 
注意： 
a、如需使用覆盖索引，select列表中的字段只取出需要的列，不要使用select * 
b、如果将所有字段都建索引会导致索引文件过大，反而降低crud性能
4、Using where ： 使用了where过滤
5、Using join buffer ： 使用了链接缓存
6、Impossible WHERE： where子句的值总是false，不能用来获取任何元祖 
7、select tables optimized away： 在没有group by子句的情况下，基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT（*）操作，不必等到执行阶段在进行计算，查询执行计划生成的阶段即可完成优化
8、distinct： 优化distinct操作，在找到第一个匹配的元祖后即停止找同样值得动作

9、innobackupex

innobackupex常用参数：
--compact        创建一个不包含第二索引（除了主键之外的索引）的备份
--decompress        解压之前所有以–compress参数备份出来的带有.qp格式的备份文件，--parallel参数会允许同时解锁或解压多个文件。需要安装qpress软件。
--defaults-file=[MY.CNF] 配置文件的路径
--incremental-basedir 以上一次全量或增量备份的路径，作为增量备份的基础。指定这个参数的同时，应该同样指定--incremental参数
--incremental 创建增量备份，当指定这个参数的时候，应该指定--incremental-lsn或--incremental-basedir参数，否则将会备份到--incremental-basedir路径
--apply-log  在备份目录下，通过应用名称为xtrabackup_logfile的交易日志文件来准备备份。同时，创建新的交易日志。
--redo-only 当准备数据库的全备或合并增量备份时，需要指定这个参数。这个参数实际上执行的是xtrabackup --apply-log-only，会让xtrabackup跳过回滚节点，只做“redo”步骤。当数据库需要应用增量备份时，需要指定这个参数。
--incremental-dir=DIRECTORY 指定增量备份的目录，需要搭配--incremental参数。
--no-timestamp 这个参数会让xtrabackup在备份的时候不创建带有时间格式的子文件夹。当指定了这个参数，备份会直接创建在指定的备份目录下
--stream=STREAMNAME 指定流备份的格式。备份将会以指定格式输出到STDOUT。目前支持的格式有tar 和 xbstream。如果指定了这个参数，后面需要接tmpdir目录作为处理流的一个中间目录。
--slave-info    当备份一个作为复制环境的服务器时，这个参数会自动将CHANGE MASTER语句写到备份中，在恢复备份后，不必执行CHANGE MASTER语句。
--tables-file=FILE        这个参数会接受一个字符串，这个字符串指定了一个文件，这个文件包含了要备份的表名，格式如database.table，一行一个。
--use-memory=#        这个参数用于在准备备份时，xtrabackup执行crash recovery所使用的内存大小。这个参数仅和--apply-log搭配时才生效。
1、全库备份：innobackupex --defaults-file=/etc/my.cnf --user=root --password='Abcd234!' /backup/20180424/
2、备份一致性合并：innobackupex --defaults-file=/etc/my.cnf  --apply-log --user=root --password='Abcd1234!' /backup/20180424/2018-04-22_21-22-30/  注：想要加快apply-log的进程，推荐使用--use-memory参数。
3、恢复数据：
先停止mysqld,再改名datadir，再新建datadir，
全库恢复:innobackupex --defaults-file=/etc/my.cnf  --copy-back /backup/20180424/2018-04-22_21-22-30/
最后修改路径权限：chown -R mysql:mysql /data/mysql 并启动mysqld
注：另外，在恢复过程中，datadir目录必须为空，如果不为空，innobackupex --copy-back 将不会复制，除非指定了 --force-non-empty-directories选项。
4、基于binlog position恢复：
先找到上次备份完成的binglog position位置，在备份路径下的xtrabackup_binlog_info中记录
再通过mysqlbinglog进行recover：mysqlbinlog --start-position=29388004  /data/mysql-binlog/mysql-bin.000002 | mysql -uroot -p'Abcd234!'
5、增量备份：innobackupex --defaults-file=/path/conf/my.cnf --host=127.0.0.1 --port=3306 --user=mysql --password=backup --incremental --incremental-basedir=/path/backup_dir/ /path/incremental_backup_dir
6、基于LSN的增量备份：innobackupex --defaults-file=/path/conf/my.cnf --host=127.0.0.1 --port=3306 --user=mysql --password=backup --incremental --incremental-lsn=834506398072 /path/incremental_backup_dir
7、增量备份一致性合并：
首先，在全量备份上执行innobackup --apply-log --redo-only base_dir
然后，在所有的增量备份上（除最后一个）执行innobackup --apply-log --redo-only --incremental-dir=/path/incremental_backup_dir base_dir
在最后一个增量备份上执行innobackup --apply-log --incremental-dir=/path/incremetal_backup_dir base_dir

10、binlog size

binlog_cache_size:为每个session 分配的内存，在事务过程中用来存储二进制日志的缓存。提高记录bin-log的效率
没有什么大事务，dml也不是很频繁的情况下可以设置小一点，如果事务大而且多，dml操作也频繁，则可以适当的调大一点。
前者建议是1048576  --1M
后者建议是： 2097152 -- 4194304  即 2--4M
max_binlog_cache_size:表示的是binlog 能够使用的最大cache 内存大小
当我们执行多语句事务的时候 所有session的使用的内存超过max_binlog_cache_size的值时就会报错：“Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage”
设置太大的话，会比较消耗内存资源;设置太小又会使用到临时文件即disk
max_binlog_size:二进制日志文件的最大长度(默认设置是1GB)。在前一个二进制日志文件里的信息量超过这个最大长度之前，MySQL服务器会自动提供一个新的二进制日志文件接续上。
Binlog_cache_disk_use:表示因为我们binlog_cache_size设计的内存不足导致缓存二进制日志用到了临时文件的次数
Binlog_cache_use:表示 用binlog_cache_size缓存的次数
expire_logs_days:定义了mysql清除过期日志的时间。二进制日志自动删除的天数。默认值为0,表示“没有自动删除”。启动时和二进制日志循环时可能删除。

11、General_log

开启 general log 将所有到达MySQL Server的SQL语句记录下来。
一般不会开启开功能，因为log的量会非常庞大。但个别情况下可能会临时的开一会儿general log以供排障使用。 
相关参数一共有3：general_log、log_output、general_log_file
set global general_log=on; -- 开启日志功能
set global general_log_file='tmp/general.lg'; -- 设置日志文件保存位置
set global log_output='table'; -- 设置输出类型为 table
set global log_output='file';   -- 设置输出类型为file

12、开启BINLOG

查看binlog开启状态：show variables like 'log_bin';
配置方式1：
vim /etc/my.cnf
在【mysqld】中添加：
log-bin=/home/data/mysql-log/mysql-bin
server-id=12345
网上很多教程都只是添加log-bin一行就行了，此处我们为什么要加 server-id？ 
因为我们用的是5.7及以上版本的话，不加server-id重启mysql服务会报错，5.7以下版本就不用加了。 
配置方式2：
log_bin=ON  
log_bin_basename=/var/lib/mysql/mysql-bin  
log_bin_index=/var/lib/mysql/mysql-bin.index 

13、常用BINLOG日志操作命令

查看所有binlog日志列表：show master logs;
查看master状态，即最后(最新)一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值：show master status;
刷新log日志，自此刻开始产生一个新编号的binlog日志文件：flush logs;
注：每当mysqld服务重启时，会自动执行此命令，刷新binlog日志；在mysqldump备份数据时加 -F 选项也会刷新binlog日志；
重置(清空)所有binlog日志：reset master;
查看binlog日志内容（以表格形式）：show binlog events in 'mysql-bin.000002';

14、mysqlbinlog命令使用

mysqlbinlog功能是将mysql的binlog日志转换成Mysql语句，默认情况下binlog日志是二进制文件，无法直接查看。我们直接在mysql目录的bin目录下启动该命令。（在MySQL5.5以下版本使用mysqlbinlog命令时如果报错，就加上 “–no-defaults”选项） 
-d  //指定库的binlog
-r  //相当于重定向到指定文件
--start-position--stop-position //按照指定位置精确解析binlog日志（精确），如不接--stop-positiion则一直到binlog日志结尾
--start-datetime--stop-datetime //按照指定时间解析binlog日志（模糊，不准确），如不接--stop-datetime则一直到binlog日志结尾
例：解析yj-test数据库的binlog日志并写入my.sql文件
./mysqlbinlog -d yj-test /home/data/mysql-log/mysql-bin.000003 -r my.sql
./mysqlbinlog mysql-bin.000003 --start-position=100  --stop-position=200 -r my.sql

15、binlog的三种工作模式

（1）Row level 
ROW是基于行级别的,他会记录每一行记录的变化,就是将每一行的修改都记录到binlog里面,记录的非常详细，但sql语句并没有在binlog里。 
日志中会记录每一行数据被修改的情况，然后在slave端对相同的数据进行修改。在replication里面也不会因为存储过程触发器等造成Master-Slave数据不一致的问题,但是有个致命的缺点日志量比较大.由于要记录每一行的数据变化,当执行update语句后面不加where条件的时候或alter table的时候,产生的日志量是相当的大。 
（2）Statement level（默认） 
每一条被修改数据的sql都会记录到master的bin-log中，slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql再次执行 
优点：解决了 Row level下的缺点，不需要记录每一行的数据变化，减少bin-log日志量，节约磁盘IO，提高性能
（3）Mixed（混合模式） 
结合了Row level和Statement level的优点。 
在默认情况下是statement,但是在某些情况下会切换到row状态，如当一个DML更新一个ndb引擎表，或者是与时间用户相关的函数等。在主从的情况下，在主机上如果是STATEMENT模式，那么binlog就是直接写now()，然而如果这样的话，那么从机进行操作的时间，也执行now()，但明显这两个时间不会是一样的，所以对于这种情况就必须把STATEMENT模式更改为ROW模式，因为ROW模式会直接写值而不是写语句（该案例是错误的，即使是STATEMENT模式也可以使用now()函数，具体原因以后再分析）。同样ROW模式还可以减少从机的相关计算，如在主机中存在统计写入等操作时，从机就可以免掉该计算把值直接写入从机。

15、sql_log_bin

如果想在主库上执行一些操作，但不复制到slave库上，可以通过修改参数sql_log_bin来实现。
比如想在主库上修改某个表的定义，但是在slave库上不做修改：
master mysql> set sql_log_bin=0;#设为0后，在Master数据库上执行的语句都不记录binlog
master mysql> alter table test1 drop index idx_id add index (id,username);
master mysql> set sql_log_bin=1;
要慎重使用global修饰符（set global sql_log_bin=0)，这样会导致所有在Master数据库上执行的语句都不记录到binlog，这肯定不是你想要的结果

16、mysql show full processlist 用来查看当前线程处理情况

返回的结果是实时变化的，是对mysql链接执行的现场快照，所以用来处理突发事件非常有用。
show full processlist命令的详解,我们可以通过三种方式来查看命令运行的结果：
1、通过SHOW FULL PROCESSLIST命令查看：
2、通过查询链接线程相关的表来查看快照
select id, db, user, host, command, time, state, info from information_schema.processlist order by time desc 
3、通过navicat中的【工具】=> 【服务器监控】进行查看结果
下面针对每列做下介绍：
Id：链接mysql 服务器线程的唯一标识，可以通过kill来终止此线程的链接。
User：当前线程链接数据库的用户
Host：显示这个语句是从哪个ip 的哪个端口上发出的。可用来追踪出问题语句的用户
db: 线程链接的数据库，如果没有则为null
Command: 显示当前连接的执行的命令，一般就是休眠或空闲（sleep），查询（query），连接（connect）
Time: 线程处在当前状态的时间，单位是秒
State：显示使用当前连接的sql语句的状态，很重要的列，后续会有所有的状态的描述，请注意，state只是语句执行中的某一个状态，一个 sql语句，已查询为例，可能需要经过copying to tmp table，Sorting result，Sending data等状态才可以完成
Info: 线程执行的sql语句，如果没有语句执行则为null。这个语句可以使客户端发来的执行语句也可以是内部执行的语句
由于Command的状态大部分都是sleep对我们分析问题没什么作用，所以我们可以通过如下语句来排除sleep状态的线程：
-- 查询非 Sleep 状态的链接，按消耗时间倒序展示，自己加条件过滤
select id, db, user, host, command, time, state, info from information_schema.processlist where command != 'Sleep' order by time desc 
4、kill 使用
-- 查询执行时间超过2分钟的线程，然后拼接成 kill 语句
select concat('kill ', id, ';') from information_schema.processlist where command != 'Sleep' and time > 2*60 order by time desc

17、show open tables

这条命令能够查看当前有那些表是打开的。In_use列表示有多少线程正在使用某张表，Name_locked表示表名是否被锁，这一般发生在Drop或Rename命令操作这张表时。所以这条命令不能帮助解答我们常见的问题：当前某张表是否有死
锁，谁拥有表上的这个锁等。这个列表可能特别长，你的屏幕估计都装不下。我遇到过，滚动条翻到最上面还是显示不了第一行，所以可以考虑使用客户端软件查看。或者通过指定数据库来减少返回条数：show open tables from database
show OPEN TABLES where In_use > 0;

18、查看lock状态:

show status like ‘%lock%';

19、查看innodb存储引擎状态：

show engine innodb status\\G;

20、查看超时相关参数：

show variables like '%timeout%';

21、查询正在执行的事务：

SELECT * FROM information_schema.INNODB_TRX;

22、查看正在锁的事务：

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

23、查看等待锁的事务：

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;