0

select id, col from tab;  -- 测试表，id为聚簇索引，col为普通辅助索引
+----+------+
| id | col  |
+----+------+
| 10 |   10 |
| 15 |   15 |
| 16 |   16 |
| 20 |   20 |
+----+------+


-- session 1
start transaction;
-- 下面两行都可以用来测试，都获得写锁
select * from tab where id=10 for update;
update tab set col=10 where id=10;
-- session 2
start transaction;
update tab set col=10 where id=10; -- 超时，记录锁
insert tab (id,col) values (5, 5); 
-- 成功，聚簇索引、唯一性索引不引入上一键锁，仅使用记录锁

-- session 1
start transaction;
-- 下面改用辅助索引执行检索
-- 如果col没有创建索引，这将导致锁整个表
update tab set col=10 where col=10; -- Next-Key范围：(-∞,10]
-- session 2
start transaction;
insert tab (id,col) values (5, 5); -- 超时，处于下一键锁范围
update tab set id=15 where col=15; -- 成功
insert tab (id,col) values (13, 13); -- 超时，辅助索引下一键值的间隙锁(10,15)
update tab set col=13 where col=13; -- 成功，记录不存在的更新不会导致锁等待


-- session 1
start transaction;
update tab set col=15 where col=15;  -- Next-Key范围(10,15]
-- session 2
start transaction;
insert tab (id,col) values (13, 13); -- 超时，处于下一键锁范围


-- session 1
start transaction;
update tab set col=20 where col=20; -- Next-Key范围：(16,20]
-- session 2
start transaction;
update tab set col=16 where col=16; -- 成功，不在Next-Key范围
insert tab (id,col) values (17,17); -- 超时，处于下一键锁范围
insert tab (id,col) values (22,22); -- 超时，辅助索引的下一键值的间隙锁

-- session 1
start transaction;
-- 由于此行的插入尚未提交，不会使用下一键锁
insert tab (id,col) values (22,22); -- 下一键范围：(20, +∞)
-- session 2
start transaction;
insert tab (id,col) values (22,22); -- 超时
update tab set col=20 where col=20; -- 成功
insert tab (id,col) values (21,21); -- 成功
insert tab (id,col) values (23,23); -- 成功
insert tab (id,col) values (25,25); -- 成功

-- 事务1
start transaction;
select * from tab1;
select * from tab2;
-- 事务1得到tab1、tab2的元数据锁，在事务提交前，这些锁不会释放

-- 事务2
-- 其它事务如果在元数据锁定表上执行DDL或者写锁，会被阻塞
start transaction;  
drop table tab1;         -- 失败
alter table tab2;        -- 失败
lock table tab1 write;   -- 失败

-- 显示字符集信息
show variables like 'character_set_%';
-- 显示MySQL版本信息
show variables like "%version%";
-- 显示当前会话的自动提交状态
show variables like 'autocommit';

-- 显示innodb锁统计信息
show status like 'innodb_row_lock_%';
-- 显示innodb缓冲池信息
show status like 'innodb_buffer_pool_%';
-- 显示最后一次查询的成本
show status like 'Last_query_cost';

cd mysql

adduser mysql
chown -R mysql:mysql data

scripts/mysql_install_db --basedir=. --datadir=data

bin/mysqld_safe --defaults-file=my.cnf &

在MySQL中create user 语句用于创建用户，相应的alter user 、drop user 用于修改、删除用户。MySQL在mysql.user 表中存储用户。

CREATE USER [IF NOT EXISTS]
-- 目标规格，格式 user [ auth_option ]
-- 其中user必须是'username'@'host'格式，引号可以省略
-- host中可以出现%，用于通配，例如192.168.0.%通配所有192.168.0子网的主机
-- %.gmem.cc则通配所有gmem.cc下的主机
-- auth_option指定身份验证方式，可以是：
-- IDENTIFIED BY 'auth_string' | DENTIFIED BY PASSWORD 'hash_string'
-- IDENTIFIED WITH auth_plugin | IDENTIFIED WITH auth_plugin BY 'auth_string'
-- IDENTIFIED WITH auth_plugin AS 'hash_string'
-- 其中auth_string表示明文，hash_string则为身份验证插件处理后的散列值，皆存放在authentication_string字段
user_specification [, user_specification] ...

-- tsl_option，指定与SSL相关的选项，语法和CREATE USER相同，可以是:
-- SSL | X509 | CIPHER 'cipher' | ISSUER 'issuer' | SUBJECT 'subject'
[REQUIRE {NONE | tsl_option [[AND] tsl_option] ...}]
-- resource_option，指定用户的资源配额，可以是：
-- MAX_QUERIES_PER_HOUR count | MAX_UPDATES_PER_HOUR count
-- MAX_CONNECTIONS_PER_HOUR count | MAX_USER_CONNECTIONS count
[WITH resource_option [resource_option] ...]
-- password_option 密码选项，可以是：
-- PASSWORD EXPIRE | PASSWORD EXPIRE DEFAULT
-- PASSWORD EXPIRE NEVER | PASSWORD EXPIRE INTERVAL N DAY
-- lock_option 账户锁定选项，可以是：
-- ACCOUNT LOCK | ACCOUNT UNLOCK
[password_option | lock_option] ... 

-- 创建一个可从所有主机上登录的用户
create user 'newuser'@'%' identified by 'newpasswd';
-- 创建一个可从192.168.0网段登录的用户
create user 'newuser'@'192.168.0.%' identified by 'newpasswd';
-- 创建一个只能从服务器本机登录的用户，不授予密码
create user 'newuser'@'localhost'; 

SET PASSWORD [FOR user] = PASSWORD('auth_string');
# 举例
set password for gmem = password('gmem');

在MySQL中，grant 语句用于给MySQL用户授权，相应的revoke 命令用于收回权限。

-- 要给其它用户授权，当前用户必须具有GRANT OPTION权限，同时拥有那些即将授出的权限
-- 如果系统变量read_only启用，则需要额外的权限SUPER
GRANT 
-- 权限类型，可以指定多个。括号内的列列表，用于指定特殊的权限级别——列
priv_type [(col_list)] [,priv_type [(col_list)]]...  
ON 
-- 可选的对象类型，可以是：TABLE、FUNCTION、PROCEDURE
[object_type] 
-- 权限级别，授权应用到哪个库的哪些对象，可以是：
-- * | *.* | db_name.* | db_name.tbl_name | tbl_name | db_name.routine_name
priv_level
TO
-- 目标用户，格式 user [ auth_option ]
-- 其中user为'username'@'host'格式
-- auth_option可以是：
-- IDENTIFIED BY 'auth_string' | DENTIFIED BY PASSWORD 'hash_string'
-- IDENTIFIED WITH auth_plugin | IDENTIFIED WITH auth_plugin BY 'auth_string'
-- IDENTIFIED WITH auth_plugin AS 'hash_string'
user_specification [, user_specification] ...

-- tsl_option，指定与SSL相关的选项，语法和CREATE USER相同，可以是:
-- SSL | X509 | CIPHER 'cipher' | ISSUER 'issuer' | SUBJECT 'subject'
[REQUIRE {NONE | tsl_option [[AND] tsl_option] ...}]

-- GRANT OPTION 表示新用户可以向其它人授权
-- resource_option，指定用户的资源配额，可以是：
-- MAX_QUERIES_PER_HOUR count | MAX_UPDATES_PER_HOUR count
-- MAX_CONNECTIONS_PER_HOUR count | MAX_USER_CONNECTIONS count
[WITH {GRANT OPTION | resource_option} ...];

MySQL支持以下权限类型：

-- 把数据库database的object对象的全部权限授予newuser，并允许他把这些权限授予别人
grant all privileges on database.object to 'newuser'@'%' with grant option;
-- 把所有数据库的所有权限授予newuser
grant all privileges on *.* to 'newuser'@'%';

-- 今年的第一天
SELECT CONCAT(YEAR(CURDATE()),'-01-01') FROM dual;
-- 得到YYYYMMDD格式的整数
SELECT CURDATE() + 0 FROM dual;

SELECT MONTH(CURDATE()) FROM dual; 

SELECT CONCAT('My', 'SQL') FROM dual;
SELECT CONCAT(6.12) FROM dual;

MySQL系统变量包含一系列配置信息，它们都具有默认值，并且大部分可以在运行时使用SET命令动态的修改，在表达式中，亦可引用系统变量。可以通过多种方式来查看这些系统变量的值：

-- 使用mysqladmin命令查看
mysqladmin variables;
-- 通过information_schema数据库查看
select * from information_schema.SESSION_STATUS;
-- 查看包含了编译时默认值和配置文件合并的系统参数列表
mysqld --verbose --help
-- 查看编译时默认值的系统参数列表
mysqld --no-defaults --verbose --help

这些变量和选项（以下统称参数）用来定制MySQL服务器的配置，或者优化性能。基于文件进行配置时，应该把参数列在my.cnf的[mysqld]段。下面列出MySQL 5.6版本的参数说明：

Purge done for trx's n:o < 0 290315608 undo n:o < 0 17
#迟滞值为20
History list length 20

----------------------
BUFFER POOL AND MEMORY
----------------------
Pages read ahead 0.00/s, 
evicted without access 0.00/s, 
Random read ahead 0.00/s

[client]
default_character_set=utf8
socket=/var/lib/mysql/mysql.sock
port=3306

[mysql]
default_character_set=utf8

[mysqld]
character_set_server                = utf8
basedir                             = /var/lib/mysql/
datadir                             = /var/lib/mysql/data/                
socket                              = /var/lib/mysql/mysql.sock     
pid_file                            = /var/lib/mysql/mysql.pid        
user                                = mysql                       
port                                = 3306
default_storage_engine              = InnoDB      
transaction_isolation=READ-COMMITTED      
innodb_log_buffer_size              = 8M
innodb_buffer_pool_size             = 4096M                  
innodb_log_file_size                = 512M
innodb_log_files_in_group           = 2
innodb_flush_log_at_trx_commit      = 2
innodb_flush_method                 = O_DIRECT
innodb_file_per_table               = 1                               
innodb_thread_concurrency           = 0
innodb_data_file_path               = ibdata1:1024M:autoextend 
innodb_max_dirty_pages_pct          = 90
innodb_lock_wait_timeout            = 30
innodb_sync_spin_loops              = 100
innodb_file_io_threads              = 4
innodb_read_io_threads              = 4
innodb_write_io_threads             = 4

key_buffer_size                     = 2048M
myisam_block_size                   = 4K
skip_external_locking
myisam-recover

sort_buffer_size                    = 2M
join_buffer_size                    = 2M
read_buffer_size                    = 1M 
read_rnd_buffer_size                = 16M 
bulk_insert_buffer_size             = 64M 
tmp_table_size                      = 256M
max_heap_table_size                 = 256M
thread_stack                        = 192K 
query_cache_type                    = 0
query_cache_size                    = 64M
query_cache_limit                   = 4M 
query_cache_min_res_unit            = 2K
max_connections                     = 3000
max_connect_errors                  = 32
max_allowed_packet                  = 32M
thread_cache_size                   = 256
table_cache_size                    = 9000
open_files_limit                    = 65535    
back_log                            = 600   

log_error                           = /var/lib/mysql/mysql-error.log
long_query_time                     = 2
slow_query_log_file                 = /var/lib/mysql/mysql-slow.log

log_bin                             = /var/lib/mysql/mysql-bin 
server_id                           = 1
sync_binlog                         = 1
innodb_support_xa                   = 1
log_slave_updates                   = 1
relay_log                           = /var/lib/mysql/mysql-relay-bin
skip_slave_start                    = 1
sync_master_info                    = 1
sync_relay_log                      = 1
sync_relay_log_info                 = 1
binlog_cache_size                   = 4M
max_binlog_cache_size               = 8M
max_binlog_size                     = 512M

read_only                           = 1 
expire_logs_days                    = 7
lower_case_table_names              = 1
skip_name_resolve                   = 1

[mysqldump]
quick

使用show status命令、mysqladmin extended-status可以查看服务器/连接的状态信息，这些状态是只读的：

mysql> show status like 'Innodb_buffer_pool_pages_d%';
+---------------------------------------+----------+
| Variable_name                         | Value    |
+---------------------------------------+----------+
| Innodb_buffer_pool_pages_data         | 993      |
+---------------------------------------+----------+
#使用information_schema亦可：
mysql> SELECT * FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME  LIKE 'INNODB_BUFFER_POOL%'; --显示全局状态
mysql> SELECT * FROM information_schema.SESSION_STATUS WHERE VARIABLE_NAME LIKE 'INNODB_BUFFER_POOL%'; --显示会话状态

MySQL5.0以后，show status的功能发生很大变化，MySQL把一部分变量全局的维护，另外一部分per-connection的维护，show status则是显示两者的混合。

通过比较一段时间前后的值，可以总体上评估MySQL的工作负载。使用innotop的命令摘要模式（Command Summary mode），可以很容易看到这种对比，亦可使用命令：

#每10秒更新一次包含Select的变量
mysqladmin -uroot -ppassword extended -r -i10 | grep Select

或者这样的SQL：

SELECT STRAIGHT_JOIN
	LOWER(gs0.VARIABLE_NAME) AS variable_name,
	gs0.VARIABLE_VALUE AS value_0,
	gs1.VARIABLE_VALUE AS value_1,
	( s1.VARIABLE_VALUE - gs0.VARIABLE_VALUE ) AS diff,
	( gs1.VARIABLE_VALUE - gs0.VARIABLE_VALUE ) / 10 AS per_sec,
	( gs1.VARIABLE_VALUE - gs0.VARIABLE_VALUE ) * 60 / 10 AS per_min
FROM
	( SELECT VARIABLE_NAME, VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS UNION ALL
		 SELECT '', SLEEP(10) FROM DUAL
	) AS gs0
JOIN information_schema.GLOBAL_STATUS gs1 USING (VARIABLE_NAME)
WHERE gs1.VARIABLE_VALUE <> gs0.VARIABLE_VALUE;

进程列表（process list）是连接到MySQL的Connections（Threads）的列表。show processlist可以显示连接状态的列表。innotop可以显示自动更新的进程列表。show full processlist不会截断文字的显示。

显示InnoDB详细的互斥信息，对分析并发、可扩展性问题很有帮助。该命令的输出形式依MySQL版本的不同而变化，MySQL5.5的输出如下：

mysql> SHOW ENGINE INNODB MUTEX;
+--------+------------------------------+-------------+
| Type   | Name                         | Status      |
+--------+------------------------------+-------------+
| InnoDB | &table->autoinc_mutex        | os_waits=1  |
| InnoDB | &dict_sys->mutex             | os_waits=1  |
| InnoDB | &log_sys->mutex              | os_waits=12 |
| InnoDB | &fil_system->mutex           | os_waits=11 |
| InnoDB | &kernel_mutex                | os_waits=1  |
| InnoDB | &dict_table_stats_latches[i] | os_waits=2  |
| InnoDB | &dict_operation_lock         | os_waits=13 |
| InnoDB | &log_sys->checkpoint_lock    | os_waits=66 |
| InnoDB | combined &block->lock        | os_waits=2  |
+--------+------------------------------+-------------+

根据输出中等待的数量可以确定InnoDB的哪个部分存在性能瓶颈，任何互斥都代表着潜在的资源争用。

MySQL提供若干命令来监控数据复制的状态：

1. show master status显示master的复制状态和配置：

   mysql> SHOW MASTER STATUS
   *************************** 1. row ***************************
               File: mysql-bin.000079
           Position: 13847
       Binlog_Do_DB:
   Binlog_Ignore_DB:

2. show binary logs显示二进制日志的列表
3. show binlog events显示日志中的事件
4. show relaylog events显示转播日志中的事件
5. show slave status显示replica的状态

从MySQL5.0+引入，包含一系列类似数据字典的功能。MySQL Forge 、common_schema提供很多针对这些字典的视图。

该schema的最大缺点是某些时候比相应的show命令缓慢。

InnoDB表

从MySQL5.5+引入，默认情况下被禁用，启用后可能导致8% - 11%的资源占用。

只需要在select语句前附加explain，即可获取其执行计划。explain命令包含两个变体：

1. explain extended：提示服务器把执行计划“反编译”为SQL语句，通过后续的show warnings命令，即可看到该语句。
2. explain partitions：显示查询需要访问的所有表分区

explain可能会导致语句的执行，例如对于from中包含子查询的SQL，则会执行子查询并把结果放入临时表。

使用pt-visual-explain可以使用树形结构来显示执行计划

执行计划返回的是近似的信息，其包含以下限制：

1. explain不提供任何可能影响查询的触发器、存储函数、UDF信息
2. 对存储过程无效
3. 不提供MySQL执行时即时优化的信息
4. 执行计划显示的统计信息只是近似的，有时会很不准确
5. 某些情形下没有做合理的区分，例如filesort可以表示内存排序、临时文件排序；Using temporary可能指内存或者磁盘临时表

MySQL5.6针对执行计划做了以下改进：

1. 支持update, insert之类语句的执行计划
2. 尽量推迟临时表的物化，可以在不执行子查询的情况下完成执行计划的解释
3. 添加optimizer trace功能，允许用户查看优化器的决定，以及作出决定的原因

//简单子查询的例子
mysql> EXPLAIN SELECT (SELECT 1 FROM sakila.actor LIMIT 1) FROM sakila.film;
+----+-------------+-------+...
| id | select_type | table |...
+----+-------------+-------+...
| 1  | PRIMARY     | film  |...
| 2  | SUBQUERY    | actor |...
+----+-------------+-------+...
//导出表的例子
mysql> EXPLAIN SELECT film_id FROM (SELECT film_id FROM sakila.film) AS der;
+----+-------------+------------+...
| id | select_type | table |...
+----+-------------+------------+...
| 1  | PRIMARY     |  |...
| 2  | DERIVED     | film       |...
+----+-------------+------------+...
//UNION的例子
mysql> EXPLAIN SELECT 1 UNION ALL SELECT 1;
+------+--------------+------------+...
| id   | select_type  | table      |...
+------+--------------+------------+...
| 1    | PRIMARY      | NULL       |...
| 2    | UNION        | NULL       |...
//UNION的结果总是存放到临时表中，并重新读取
| NULL | UNION RESULT | <union1,2> |... 
+------+--------------+------------+...

mysql> EXPLAIN SELECT film.film_id
-> FROM sakila.film
-> INNER JOIN sakila.film_actor USING(film_id)
-> INNER JOIN sakila.actor USING(actor_id);
+----+-------------+------------+...
| id | select_type | table      |...
+----+-------------+------------+... //这三行都是属于第一个查询
| 1  | SIMPLE      | actor      |... //MySQL修改了原始查询中给定的JOIN顺序
| 1  | SIMPLE      | film_actor |...
| 1  | SIMPLE      | film       |...
+----+-------------+------------+...

1  EXPLAIN
2  select
3    actor_id,
4    (select 1 from film_actor where actor_id = der_1.actor_id limit 1)
5  from (
6    select actor_id
7    from actor limit 5
8  ) AS der_1
9 
10 UNION ALL
11
12 select film_id,
13   (select @var1 from rental LIMIT 1)
14 from(
15   select film_id, (select 1 from store limit 1) from film limit 5
16 ) AS der_2;

+------+----------------------+------------+...
| id   | select_type          | table |...
+------+----------------------+------------+...
//对der_1的前向引用，对应SQL第2行
| 1    | PRIMARY              |  |...
//id为3表示它是第3个SELECT的部分，DERIVED表示它是FROM子查询，对应SQL第6行
| 3    | DERIVED              | actor      |...
//对应SQL第4行，其具有一个较小的id，表示它是后来执行的（executed afterward）
//DEPENDENT表示它的结果依赖于外部查询的结果（亦称相关子查询correlated subquery）
| 2    | DEPENDENT SUBQUERY   | film_actor |...
//表示其是UNION语句中的第二个或者更靠后的查询，从6中获取数据
| 4    | UNION                |  |...
//对应SQL第15行
| 6    | DERIVED              | film       |...
//的SELECT子句的子查询，注意其ID为7，这很重要，它不是相关子查询
| 7    | SUBQUERY             | store      |...
//注意ID变小了，每当出现一个DERIVED类型的查询时，意味着开启了一个嵌套的scope
//其后ID会变大，如果又变得比DERIVED查询小了，说明嵌套scope已经结束
//下一行是使用进行查询的SELECT的一部分
| 5    | UNCACHEABLE SUBQUERY | rental     |...
//从临时表中读取数据，对应的导出表的ID为1、4
| NULL | UNION RESULT         | <union1,4> |...
+------+----------------------+------------+...

与其它的show命令不同，该命令的输出是一个字符串，分为若干个段落，分别关注InnoDB的不同方面。

其输出包含一些自上一次命令输出以来的平均统计信息，例如fsync()每秒被调用的次数，如果需要分析这些统计信息，务必等待30秒或更长以保证统计的采样更加精确，并且通过多次采样来分析InnoDB的运行走势。诸如innotop之类的工具可以提供比该命令更方便的功能。

mysql> show engine innodb status;
'第一部分是信息头'
1 =====================================
2 070913 10:31:48 INNODB MONITOR OUTPUT
3 =====================================
4 Per second averages calculated from the last 49 seconds '上一次统计以来的流逝的时间，最好大于30秒'

'第二部分是信号量，对于高并发的工作负载的分析具有重要意义。InnoDB使用互斥量和信号量来保护代码关键区的独占访问'
'以及在存在活动reader的时候限制writer的操作，等等。'
'包含两类数据：1、事件计数器；2、一个当前等待的列表。如果出现性能瓶颈，这些数据有利于分析瓶颈的所在'
'下面是信号量的简单输出示例：'
1 ----------
2 SEMAPHORES
3 ----------
'下行显示操作系统等待数组的信息，这是一个插槽（slots）的队列，InnoDB为信号量保留数组中的插槽，操作系统'
'使用信号量来提示（signal）线程可以继续并进行其正在等待（某种资源）去做的事情了，该行显示了InnoDB需要'
'使用系统等待的次数。其中reservation count说明了InnoDB分配插槽的频度；signal count则说明了线程被通过'
'OS等待数组被signal的频度。相比起自旋等待（spin waits），操作系统等待的成本更高'
4 OS WAIT ARRAY INFO: reservation count 13569, signal count 11421
'5-12行显示了当前正在等待互斥量（mutex）的线程的信息，每个等待以Thread  has waited at ...开头'
'本例中，包含2个等待的线程，理想情况下，最好为0个，除非系统并发非常高，从而必须使用操作系统等待'
'这些信息中最有价值的是线程等待的文件名，可以去分析资源争用出现什么地方，例如buf0buf.ic说明存在缓冲池争用'
5 --Thread 1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds '等待时间'
the semaphore:
6 Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0 
7 waiters flag 0 '多少个等待者正在等待该互斥量'
8 wait is ending '表示互斥量当前已经可用了，但是操作系统尚未调度线程运行'
9 --Thread 1147709792 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds
the semaphore:
10 Mutex at 0x2a957858b8 created file buf0buf.c line 517, lock var 0
11 waiters flag 0
12 wait is ending
'InnoDB使用多阶段等待策略，首先，尝试对锁的自旋等待，如果失败，则进入比较昂贵的操作系统等待。尽管自旋等待需要'
'占用CPU周期进行不停的检查，但是通常并不消耗太多资源，因为在CPU等待I/O的时候通常存在空闲CPU周期。除了自旋等待'
'以外，另外一种方式是线程上下文切换，导致当前线程休眠，这期间其它线程可以运行，然后，休眠线程可以通过OS等待队列'
'里面的信号量来激活（signal）。信号量激活是很快的，但是上下文切换则比较昂贵，特别是每秒上千次切换将消耗大量资源'
'调整innodb_sync_spin_loops来在自旋和操作系统等待之间获得平衡，如果自旋循环（rounds）达到每秒成百上千，则可'
'以考虑自旋等待的配置是否有问题。可以结合SHOW ENGINE INNODB MUTEX、performance_schema来解决问题'
'显示几个与互斥有关的计数器。注意操作系统等待的次数'
13 Mutex spin waits 5672442, rounds 3899888, OS waits 4719
'显示与读/写共享锁、独占锁的计数器。注意操作系统等待的次数'
14 RW-shared spins 5920, OS waits 2918; RW-excl spins 3463, OS waits 3163

'第三部分是最近发生的外键错误记录，如果没有外键错误发生，该部分不会显示，如果出现新错误，旧的可能被覆盖'
'外键错误发生时机：1、在进行增删改操作时违反外键约束时；2、尝试删除存在外键约束的表时'
'增删改操作时违反外键约束的例子，依次执行下面三个SQL语句'
'INSERT INTO parent(parent_id) VALUES(1);'
'INSERT INTO child(parent_id) VALUES(1);'
'DELETE FROM parent;'
'会出现错误：'
'ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint'
'fails (`test/child`, CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES'
'`parent` (`parent_id`)) 执行SEIS命令，输出如下：'
1 ------------------------
2 LATEST FOREIGN KEY ERROR
3 ------------------------
4 070913 10:57:34 Transaction:   '显示外键错误发生的时间'
'5-9行显示违反外键约束的事务的详细信息'
5 TRANSACTION 0 3793469, ACTIVE 0 sec, process no 5488, OS thread id 52064 updating or deleting...
6 mysql tables in use 1, locked 1
7 4 lock struct(s), heap size 1216, undo log entries 1
8 MySQL thread id 9, query id 305 localhost baron updating
9 DELETE FROM parent
'10-19行显示修改时出现错误的数据的精确信息'
10 Foreign key constraint fails for table `test/child`:
11 
12 CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`parent_id`)
13 Trying to delete or update in parent table, in index `PRIMARY` tuple:
14 DATA TUPLE: 3 fields;
15 0: len 4; hex 80000001; asc ;; 1: len 6; hex 00000039e23d; asc 9 =;; 2: len
7; hex 000000002d0e24; asc - $;;
16
17 But in child table `test/child`, in index `parent_id`, there is a record:
18 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
19 0: len 4; hex 80000001; asc ;; 1: len 6; hex 000000000500; asc ;;
'尝试删除存在外键约束的表的例子，执行下面的语句：'
'ALTER TABLE parent MODIFY parent_id INT UNSIGNED NOT NULL;会出现错误：'
'ERROR 1025 (HY000): Error on rename of ./test/#sql-1570_9 to ./test/parent'
'上面的1025报错没有给出足够的信息， SEIS命令则阐明了详细的错误原因：'
1 ------------------------
2 LATEST FOREIGN KEY ERROR
3 ------------------------
4 070913 11:06:03 Error in foreign key constraint of table test/child:
5 there is no index in referenced table which would contain
6 the columns as the first columns, or the data types in the
'外键类型必须完全匹配，包括类似UNSIGNED的修饰符'
7 referenced table do not match to the ones in table. Constraint: 
8 ,
9 CONSTRAINT child_ibfk_1 FOREIGN KEY (parent_id) REFERENCES parent (parent_id)
10 The index in the foreign key in table is parent_id
11 See http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html
12 for correct foreign key definition.

'第四部分是死锁相关的信息，如果不存在死锁，该部分不会显示，新的死锁可能覆盖旧的信息'
'死锁是等待图（waits-for graph）中出现的闭环，该环可能具有任意的大小，每当事务需要等待一个锁时，InnoDB就会立即'
'进行死锁检测，因此在InnoDB中死锁是即刻发现的，不需要超时机制。死锁可能非常复杂，但是该部分内容只会显示最后两个牵'
'涉到死锁中的事务、每个事务最后执行的语句、以及在等待图中制造了闭环的锁。除了我们平常熟悉的死锁，InnoDB把检查闭环'
'的开销过大的情形也认为是发生死锁，这些情形包括：等待图中超过100万个锁；检查时递归超过200个事务'
'注意除了事务、等待的锁之外，该部分的输出还包括相关的记录本身，这可能非常大，导致内容阶段，可以使用Percona Server'
'下面是一个简单的死锁的例子：'
1 ------------------------
2 LATEST DETECTED DEADLOCK
3 ------------------------
4 070913 11:14:21  '显示死锁发生的时间'
'5-10行显示牵涉到死锁的第一个事务的基本信息'
5 *** (1) TRANSACTION:
6 TRANSACTION 0 3793488, ACTIVE 2 sec, process no 5488, OS thread id 1141287232
starting index read
7 mysql tables in use 1, locked 1
8 LOCK WAIT 4 lock struct(s), heap size 1216
9 MySQL thread id 11, query id 350 localhost baron Updating
10 UPDATE test.tiny_dl SET a = 0 WHERE a <> 0
'11=15行显示了死锁发生时，事务一正在等待的锁'
11 *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
'这一行的内容最重要，说明事务一在等待test.tiny_dl表的GEN_CLUST_INDEX索引的独占锁'
12 RECORD LOCKS space id 0 page no 3662 n bits 72 index `GEN_CLUST_INDEX` of table
`test/tiny_dl` trx id 0 3793488 lock_mode X waiting
13 Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
14 0: len 6; hex 000000000501 ...[ omitted ] ... '这边的信息用于调试InnoDB本身，被略去'
15
'16-21行显示牵涉到死锁的第二个事务的基本信息'
16 *** (2) TRANSACTION:
17 TRANSACTION 0 3793489, ACTIVE 2 sec, process no 5488, OS thread id 1141422400
starting index read, thread declared inside InnoDB 500
18 mysql tables in use 1, locked 1
19 4 lock struct(s), heap size 1216
20 MySQL thread id 12, query id 351 localhost baron Updating
21 UPDATE test.tiny_dl SET a = 1 WHERE a <> 1
'22-26行显示第二个事务持有的锁'
22 *** (2) HOLDS THE LOCK(S):
23 RECORD LOCKS space id 0 page no 3662 n bits 72 index `GEN_CLUST_INDEX` of table
`test/tiny_dl` trx id 0 3793489 lock mode S
24 Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
25 0: ... [ omitted ] ... '这边省略了若干牵涉到的记录'
26
'27-31行显示了死锁发生时，事务二正在等待的锁'
27 *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
28 RECORD LOCKS space id 0 page no 3662 n bits 72 index `GEN_CLUST_INDEX` of table
`test/tiny_dl` trx id 0 3793489 lock_mode X waiting
29 Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
30 0: len 6; hex 000000000501 ...[ omitted ] ...
31
'通常上面的信息足够判断查询使用了什么索引，并可以确定是否可以避免死锁'
'如果能使两个事务按照同样的顺序扫描同一个索引，可能减少死锁发生的次数，因为在同样顺序的情况下，不可能出现闭环'
'例如，两个事务需要更新同一张表，那么在内存中按照主键排序，并且按照该顺序依次更新，则两个事务不会发生死锁'
32 *** WE ROLL BACK TRANSACTION (2) '事务二被回滚了，InnoDB会尝试回滚其认为代价最低的事务'

'第五部分是事务相关一些摘要性的信息'
1 ------------
2 TRANSACTIONS
3 ------------
4 Trx id counter 0 80157601 '当前的事务标识符，对于每一个事务，值会递增'
'InnoDB清理MVCC旧版本的进度——已经到达的事务标识符。通过下面的值与当前事务标识符的差值，可以知道有多少旧版本'
'MMVC尚未被清理：80157601 - 80154573 = 3028。没有严格的规则来判断此差值的安全最大值：如果当前不存在任何'
'数据更新，即使差值很大也不代表存在未清理的数据，因为所有事务都使用同样的版本；反之，如果很多行被更新，或者内'
'内中有很多行的一个或多个版本，则应该尽快的提交事务，因为开启的事务即使什么都不做，也会禁止旧版本数据的清理'
5 Purge done for trxs n:o= 0 80157601, sees

如果在Server级别发生锁争用，则show processlist中会有所证据。

Server级别锁包括以下几类：

表锁（Table Locks）

表锁可以是明确的或者隐含的，通过lock table语句可以创建明确锁：

-- 在会话1上对表进行共享锁定
LOCK TABLES sakila.film READ;
-- 在会话2上对表进行独占锁定，语句会挂起而无法完成：
LOCK TABLES sakila.film WRITE;
-- 显示进程列表，可以看到
SHOW PROCESSLIST
mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
Info: SHOW PROCESSLIST
*************************** 2. row ***************************
     Id: 11
   User: baron
   Host: localhost
     db: NULL
Command: Query
   Time: 4
  State: Locked --注意该线程的状态是被锁定，出现此状态表示在Server层被锁
   Info: LOCK TABLES sakila.film WRITE

-- 锁也可能是隐含获得的，例如在MyISAM上执行以下语句
SELECT SLEEP(30) FROM sakila.film LIMIT 1;
-- 在30秒内，开启另外一个会话，运行LOCK TABLES sakila.film WRITE;会被锁定

注意InnoDB，对于明确锁，它会做你期望做的，但是对于隐含锁，InnoDB会在Server表锁和InnoDB表锁类型进行必要的转换。

mysqladmin debug命令可以用于发现持有MyISAM表锁的线程。

全局读锁（The Global Read Lock）

-- 使用下面的语句可以获取全局读锁
FLUSH TABLES WITH READ LOCK;
-- 另外一个会话尝试锁定时：
LOCK TABLES sakila.film WRITE;
-- 会挂起，通过SHOW PROCESSLIST可以看到：
State: Waiting for release of readlock  --这意味着全局锁

名称锁（Name Locks）

这是一种表锁，当服务器进行表重命名或者DROP的时候会创建，该锁会与其他类型的表锁冲突并导致等待。

用户锁（User Locks）

本质上是一种命名的互斥量：

-- 会话1中执行：
SELECT GET_LOCK('my lock', 100);
-- 尝试在会话2上述语句，会导致挂起，SHOW PROCESSLIST显示：
State: User lock

任何支持row-level锁的存储引擎，在其内部实现锁定机制。

InnoDB通过show engine innodb status暴露了一些关于锁的信息，如果某个事务在等待一个锁，在transactions段可以看到相应的输出：

mysql> SET AUTOCOMMIT=0;
mysql> BEGIN;
mysql> SELECT film_id FROM sakila.film LIMIT 1 FOR UPDATE;

show engine innodb status
//显示类似如下的类型
1 LOCK WAIT 2 lock struct(s), heap size 1216
2 MySQL thread id 8, query id 89 localhost baron Sending data
3 SELECT film_id FROM sakila.film LIMIT 1 FOR UPDATE
4 ------- TRX HAS BEEN WAITING 9 SEC FOR THIS LOCK TO BE GRANTED: //已经等待了9秒
//线程正在等待索引idx_fk_language_id的194页的独占锁（lock_mode X）
5 RECORD LOCKS space id 0 page no 194 n bits 1072 index `idx` of table `sakila/film` trx id 0 61714 lock_mode X waiting

//最终，所等待会超时，显示以下内容：
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

//但是，无法看到是谁锁定了表，可以创建下面的表来激活InnoDB 锁监视器
CREATE TABLE innodb_lock_monitor(a int) ENGINE=INNODB;
//上述语句执行后，InnoDB定期（通常每分钟数次）会打印增强版本的（亦可手工执行）
//show engine innodb status信息到标准输出（通常是MySQL错误日志文件）
//如果要停止监控，DROP innodb_lock_monitor

//打开错误日志，可以看到类似下面的详细信息：
1 ---TRANSACTION 0 61717, ACTIVE 3 sec, process no 5102, OS thread id 1141152080
2 3 lock struct(s), heap size 1216
 //显示进程ID，与process list的ID列一致
3 MySQL thread id 11, query id 108 localhost baron
4 show innodb status
//该事务在film表上持有一个隐含的I独占锁X
5 TABLE LOCK table `sakila/film` trx id 0 61717 lock mode IX 
//显示索引上的锁的详细信息
6 RECORD LOCKS space id 0 page no 194 n bits 1072 index `idx` of table `sakila/film` trx id 0 61717 lock_mode X
7 Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
8 ... omitted ... //包含被锁定记录的DUMP，难以看懂，可以使用innotop、Percona Server或者MariaDB
9
10 RECORD LOCKS space id 0 page no 231 n bits 168 index `PRIMARY` of table `sakila/film`
trx id 0 61717 lock_mode X locks rec but not gap
11 Record lock, heap no 2 PHYSICAL RECORD: n_fields 15; compact format; info bits 0
12 ... omitted ...

可以使用information_schema中的表来获取锁的信息：

-- 显示谁持有锁（blocking），谁在等待(waiting)，等待了多久
SELECT r.trx_id AS waiting_trx_id, r.trx_mysql_thread_id AS waiting_thread,
    TIMESTAMPDIFF(SECOND, r.trx_wait_started, CURRENT_TIMESTAMP) AS wait_time,
    r.trx_query AS waiting_query,
    l.lock_table AS waiting_table_lock,
    b.trx_id AS blocking_trx_id, b.trx_mysql_thread_id AS blocking_thread,
    SUBSTRING(p.host, 1, INSTR(p.host, ':') - 1) AS blocking_host,
    SUBSTRING(p.host, INSTR(p.host, ':') +1) AS blocking_port,
    IF(p.command = "Sleep", p.time, 0) AS idle_in_trx,
    b.trx_query AS blocking_query
FROM information_schema.INNODB_LOCK_WAITS AS w
INNER JOIN information_schema.INNODB_TRX AS b ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.INNODB_TRX AS r ON r.trx_id = w.requesting_trx_id
INNER JOIN information_schema.INNODB_LOCKS AS l ON w.requested_lock_id = l.lock_id
LEFT JOIN information_schema.PROCESSLIST AS p ON p.id = b.trx_mysql_thread_id
ORDER BY wait_time DESC

*************************** 1. row ***************************
    waiting_trx_id: 5D03
    waiting_thread: 3
         wait_time: 6  --已经等待了6秒
     waiting_query: select * from store limit 1 for update
waiting_table_lock: `sakila`.`store`
   blocking_trx_id: 5D02
   blocking_thread: 2
     blocking_host: localhost
     blocking_port: 40298
       idle_in_trx: 8  --持有锁，已经空闲了8秒
    blocking_query: NULL


-- 显示某个锁的持有者，多少线程在等待，等待了多久
SELECT CONCAT('thread ', b.trx_mysql_thread_id, ' from ', p.host) AS who_blocks,
    IF(p.command = "Sleep", p.time, 0) AS idle_in_trx,
    MAX(TIMESTAMPDIFF(SECOND, r.trx_wait_started, NOW())) AS max_wait_time,
    COUNT(*) AS num_waiters
FROM information_schema.INNODB_LOCK_WAITS AS w
INNER JOIN information_schema.INNODB_TRX AS b ON b.trx_id = w.blocking_trx_id
INNER JOIN information_schema.INNODB_TRX AS r ON r.trx_id = w.requesting_trx_id
LEFT JOIN information_schema.PROCESSLIST AS p ON p.id = b.trx_mysql_thread_id
GROUP BY who_blocks ORDER BY num_waiters DESC

*************************** 1. row ***************************
   who_blocks: thread 2 from localhost:40298
  idle_in_trx: 1016  -- 线程2已经空闲了很久
max_wait_time: 37    -- 最长的线程已经等待了37秒
  num_waiters: 8     -- 8个线程在等待2完成工作并提交

执行同步之前，首先要保证两个服务器的数据集一致。

主主复制和主从复制类似，只是互相指认对方为Master。需要注意可能存在的修改丢失问题 —— 如果SQL同步完成之间，同一条数据在目标库上修改，则随后发生的同步会覆盖此修改。

本节介绍一个主主复制的实例，服务器HK 47.90.76.189和BJ 39.107.94.255进行主主同步。

在两台机器上分别执行：

mysql -uroot <<SQL
create user 'sync'@'localhost' identified by 'sync';
grant replication slave on *.* to 'sync'@'localhost';
flush privileges;
SQL

两台服务器位于公网上，因此必须使用安全信道。我们可以使用SSH隧道。

首先安装SSH隧道监控工具：

wget http://www.harding.motd.ca/autossh/autossh-1.4e.tgz
tar xzf autossh-1.4e.tgz && rm  autossh-1.4e.tgz
cd autossh-1.4e/
./configure --prefix=/usr
make && make install
cd ..
rm -rf autossh-1.4e

然后开启自我维护的SSH隧道：

# 在BJ执行：
# localhost:3307:localhost:3306，将本机网络接口localhost上的3307端口绑定到远程主机localhost上的3306端口
autossh -M 22222 -fnN -L localhost:3307:localhost:3306 -i ~/Documents/puTTY/gmem.key root@hk.gmem.cc
# 在HK执行：
autossh -M 22222 -fnN -L localhost:3307:localhost:3306 -i ~/Documents/puTTY/gmem.key root@bj.gmem.cc 

主要相关的配置项如下表：

[mysqld]
# 必须，服务器标识符全局唯一
server-id                      = 1
# 必须，启用二进制日志
log-bin                        = /var/lib/mysql/mysql-bin
# 可选，混合二进制日志格式
binlog_format                  = mixed
# 可选，二进制日志保存时间
expire-logs-days               = 14
# 可选，每次事务提交后，都同步二进制日志缓存到磁盘
sync-binlog                    = 1

# Master相关配置
# 记录二进制日志的数据库列表，逗号分隔
binlog-do-db                   = gmem
# 必须，不记录二进制日志的数据库
binlog-ignore-db               = mysql,information_schema,performance_schema
# 主主同步时，每个数据库都可能插入数据，因此需要防止自增长键的冲突
# 自增长键每次增长的步长
auto-increment-increment       = 2
# 自增长键的偏移量
auto-increment-offset          = 1

# SLAVE相关配置
# 重放二进制日志的数据库列表
replicate-do-db                = gmem
# 必须，忽略二进制日志的数据库
replicate-ignore-db            = mysql,information_schema,performance_schema
# 可选，开启中继日志。复制线程先把Master的日志拷贝到中继日志中，再异步入库
relay_log                      = /var/lib/mysql/relay-bin
# 必须，中继日志执行之后将变化写入自己的二进制文件
log-slave-updates              = ON
# 可选，跳过所有的失败的SQL
slave-skip-errors              = all 

让两台服务器分别进入只读模式，然后获取二进制日志偏移量： 

# HK上的执行结果
mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)

mysql> show master status\G
*************************** 1. row ***************************
            File: mysql-bin.000002
        Position: 1373523
    Binlog_Do_DB: gmem
Binlog_Ignore_DB: mysql,information_schema,performance_schema
1 row in set (0.00 sec)

mysql> UNLOCK TABLES;

# BJ上的执行结果：
mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.01 sec)

mysql> show master status\G
*************************** 1. row ***************************
            File: mysql-bin.000002
        Position: 434
    Binlog_Do_DB: gmem
Binlog_Ignore_DB: mysql,information_schema,performance_schema
1 row in set (0.00 sec)

# HK上的命令
mysql> CHANGE MASTER TO MASTER_HOST='localhost',MASTER_PORT=3307,MASTER_USER='sync',MASTER_PASSWORD='sync',MASTER_LOG_FILE='mysql-bin.000002',MASTER_LOG_POS=434;
# BJ上的命令
mysql> CHANGE MASTER TO MASTER_HOST='localhost',MASTER_PORT=3307,MASTER_USER='sync',MASTER_PASSWORD='sync',MASTER_LOG_FILE='mysql-bin.000002',MASTER_LOG_POS=1373523;

在两台服务器上分别执行：

mysql> start slave; 
# 查看状态：
mysql> show slave status\G
...
Slave_IO_Running: Yes 
Slave_SQL_Running: Yes 

除非手工停止，MySQL重启后Slave都会自动启动。

如果不希望继续进行数据同步，可以在服务器上执行：

mysql> stop slave;

该列并非某种序列号，两个相邻的具有相同id的行，意味着基于标准的一遍扫描多次联接（single-sweep multi-join，从第一个表读取一行，然后从第二个表查找其匹配行）方式进行JOIN。

可以用于提示：

1. 一个新的子作用域被打开
2. 当前行和前面的行的某种关系
3. 当前行执行何种操作

具体如下：

通常是表名或者别名。也可以是：

1. derivedN：表示此行对ID为N的子查询所产生的临时表进行访问
2. unionM,N：表示对ID为M～N的查询的UNION结果进行访问

查询匹配哪些分区，仅仅用于分区表。

说明表如何被JOIN：

MySQL可以选择哪些索引来寻找当前表中的匹配行，如果显示NULL则意味着没有可用索引。

MySQL实际决定使用的索引。

MySQL使用索引的前多少字节。

使用到的索引（key字段）和什么列/常量进行比较，以获取匹配的行。

为了执行查询，MySQL需要检查的行数。对于InnoDB来说这一数值是大概的，不一定准确。

大概估算的被条件过滤的行的比例。rows × filtered / 100为实际和前表进行JOIN的行数量。

执行命令EXPLAIN EXTENDED时该列出现。

关于MySQL如何解析查询的额外信息。

用于将MySQL的执行计划转换为树状形式。命令格式：

# 从FILES读取执行计划
pt-visual-explain [OPTIONS] [FILES]
# 从MySQL命令输出中读取执行计划
mysql -e SQL | pt-visual-explain

mysql -h 10.255.223.249 -P 13306 -uuser -ppasswd -D digital -e 
"EXPLAIN SELECT count(1) subscriptionCount 
    FROM media_customer_subscription s 
    LEFT JOIN media_chapter c ON s.media_id = c.media_id 
 WHERE 1 = 1 AND s.media_id = 1960162291 AND s.cust_id = 274516853 AND c.last_modifyed_date >= '2018-03-21 19:35:19'"

| pt-visual-explain

# 输出
JOIN
+- Filter with WHERE
|  +- Bookmark lookup
|     +- Table
|     |  table          c
|     |  possible_keys  index_media_id_index_order
|     +- Index lookup
|        key            c->index_media_id_index_order
|        possible_keys  index_media_id_index_order
|        key_len        9
|        ref            const
|        rows           2823
+- Filter with WHERE
   +- Index lookup
      key            s->customer_subscription_cust_media_id
      possible_keys  customer_subscription_media_id,customer_subscription_cust_id_index,customer_subscription_cust_media_id
      key_len        18
      ref            const,const
      rows           1
# 解释如下：
# 1、对s表进行索引扫描，估计访问1行。ref分别为s.media_id、s.cust_id两个常量值
# 2、对c表进行索引扫描，预计访问2823行。ref为c.media_id
# 3、对c表通过索引定位的每一行，进行bookmark查找，即根据非聚簇索引上的条目查找实际数据
# 4、执行JOIN

频繁的对表进行插入、修改、删除，可能导致表空间上出现大量零散的空白，即碎片化，碎片会影响表的读取效率。下面的语句可以查看表的碎片化情况：

SELECT
	ENGINE,
	TABLE_NAME,
	Round(DATA_LENGTH / 1024 / 1024) AS data_mb,
	round(INDEX_LENGTH / 1024 / 1024) AS index_mb,
	round(DATA_FREE / 1024 / 1024) AS data_free_mb
FROM
	information_schema. TABLES
WHERE
	DATA_FREE > 0
ORDER BY
  DATA_FREE DESC

注意一个表空间中的所有表，会共享一个data_free，因此如果使用单独数据文件，可能看到很多重复的data_free值。使用下面的语句可以进行表优化：

optimize table wp_posts;
-- 如果提示： Table does not support optimize, doing recreate + analyze instead
-- 说明引擎不支持，可以改用：
alter table wp_posts engine='InnoDB'; 
-- 注意，如果设置：innodb_file_per_table=1，那么alter将为表新建独立的.ibd文件

找到my.ini，定位datadir的位置，其目录下有日志文件：服务器名.error，里面包含详细错误信息。如果配置存在问题，可以通过bin\MySQLIntanceConfig.exe进行重新配置。

注意，MySQL错误日志文件路径可以通过log-error参数定制。

添加外键约束时出现此错误，可能原因是：外键字段与目标表的主键字段的类型不兼容，例如varchar与int。

属于授权问题，可以授予目标用户相关的权限来解决：

grant all privileges on *.* to root@"%" identified by "root"; 

大表删除速度慢，原因和聚簇索引（cluster index，此索引每张表只能有一个）有关，MySQL会使用主键、唯一键（作为聚簇索引列）来在物理磁盘上对表的数据行进行排序，一旦行被删除，就会进行整个表的重新排序，这个排序正是耗时操作所在。 解决方案：

1. 规划主键的设计，如果删除的数据，其主键是集中在一个区间的，最好了
2. 或者，添加一个BIT列，在删除的时候，将其状态改为false，在某个时候进行单次批量删除

rem 打印MySQL使用的运行参数，可以检测配置是否生效
mysql --print-defaults    
rem 执行命令
mysql --verbose --help | less
rem 一直按回车，直到看见“Default options are read from the following files in the given order”
rem 下一行即为读取的配置文件位置，例如
rem C:\Windows\my.ini C:\Windows\my.cnf C:\my.ini C:\my.cnf D:\Programs\MySQL\my.ini D:\Programs\MySQL\my.cnf

另外，如果MySQL在Windows下作为服务运行，可能需要注意MySQL服务的配置，其命令行参数可能附带 --defaults-file参数，该参数指明了该服务实例使用的my.cnf文件。

sudo apt-get purge mysql* -y
sudo apt-get autoremove -y
sudo apt-get autoclean
sudo apt-get install mysql-server -y

# 执行命令行提供的SQL语句并退出
mysql -uroot -proot -e "create database newdb;"