转 pt-online-schema-change安装使用详解
https://blog.csdn.net/lizarel/article/details/113242838
一、pt-online介绍
pt-online-schema-change是percona公司开发的一个工具，在percona-toolkit包里面可以找到这个功能，它可以在线修改表结构
原理:
首先它会新建一张一模一样的表，表名一般是_new后缀
然后在这个新表执行更改字段操作
然后在原表上加三个触发器，DELETE/UPDATE/INSERT，将原表中要执行的语句也在新表中执行
最后将原表的数据拷贝到新表中，然后替换掉原表
使用pt-online-schema-change执行SQL的日志 SQL语句:
ALTER TABLE `tmp_task_user` ADD support tinyint(1) unsigned NOT NULL DEFAULT '1';
?
sh pt.sh tmp_task_user "ADD COLUMN support tinyint(1) unsigned NOT NULL DEFAULT '1'"
好处:
降低主从延时的风险
可以限速、限资源，避免操作时MySQL负载过高
建议:
在业务低峰期做，将影响降到最低
限制条件
操作期间，文件系统空间消耗会增加一倍，因为要复制一张表，
是因为pt 要求被作用的表需要含有主键或者唯一索引
##使用create as select * from table ,不会创建索引，因为pt-online-schema-change修改表，要求表必须有主键，所以改用swbench 创建带索引的大表对数据操作
##执行修改命令报错：There is no good index and the table is oversized.
##pt-online-schema-change检查发现：这是因为pt 要求被作用的表需要含有主键或者唯一索引
###Cannot chunk the original table `metas`.`PART`: There is no good index and the table is oversized. at /usr/bin/pt-online-schema-change line 5970.
二、pt-online安装
1.去官网下载对应的版本，官网下载地址:https://www.percona.com/downl…
2.下载解压之后就可以看到pt-online-schema-change
先安装依赖：
yum -y install perl-DBI perl-DBD-MySQL perl-Digest-MD5 perl-IO-Socket-SSL perl-TermReadKey
rpm -ivh percona-toolkit-3.3.0-1.el7.x86_64.rpm
验证
pt-online-schema-change --help
1
三、pt-online-schema-change使用
1.参数 ./bin/pt-online-schema-change --help 可以查看参数的使用，我们只是要修改个表结构，只需要知道几个简单的参数就可以了
–user= 连接mysql的用户名
–password= 连接mysql的密码
–host= 连接mysql的地址
P=3306 连接mysql的端口号
D= 连接mysql的库名
t= 连接mysql的表名
–alter 修改表结构的语句
–execute 执行修改表结构
–charset=utf8 使用utf8编码，避免中文乱码
–no-version-check 不检查版本，在阿里云服务器中一般加入此参数，否则会报错
2.执行
pt-online-schema-change --user=root --password=123456 --host=127.0.0.1 P=3306,D=test,t=users --charset=utf8 --no-version-check --execute --alter "ADD COLUMN pid int(10) DEFAULT 0"
3.为避免每次都要输入一堆参数，写个脚本复用一下，pt.sh
#!/bin/bash
table=$1
alter_conment=$2
cnn_host='127.0.0.1'
cnn_user='root'
cnn_pwd='123456'
cnn_db='test'
echo "$table"
echo "$alter_conment"
pt-online-schema-change --user=${cnn_user} --password=${cnn_pwd} --host=${cnn_host} P=3306,D=${cnn_db},t=${table} --charset=utf8 --no-version-check --alter "${alter_conment}" --execute
那么该语句可以这么写：
sh pt.sh users "ADD COLUMN sid tinyint(4) DEFAULT 0"
————————————————
版权声明：本文为CSDN博主「菜鸟一直在路上」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lizarel/article/details/113242838
######sample 1; 下面测试 原生的mysql 客户端修改 和pt 工具修改的差异：
分如下场景
场景1：空闲的数据库，进行修改数据字段的操作
场景2：繁忙的数据库，对该表的频繁的dml操作，
综合得知：
原生的alter table 速度会略快于pt工具修改，但是会导致阻塞其他对同样的表dml操作
Pt 工具不会阻塞其他对同样的表dml操作，效率会略微慢20%。
建议使用原生的mysql on-line ddl 语句操作，因为感觉生产的io 和测试的io 不是一个数量级的，
##需要注意的是不要使用create as select * from table ,创建测试表，但是测试表不会创建索引，因为pt 修改表，要求表必须有主键，所以改用swbench 创建带索引的大表对数据操作
##
###
##执行修改命令报错：There is no good index and the table is oversized.
##检查发现：这是因为pt 要求被作用的表需要含有主键或者唯一索引
-> 第二次测试 swbench 创建了1000万数据的大表
create database sysbench_test;
select count(*) from sysbench_test.sbtest1
show create table sysbench_test.sbtest1
CREATE TABLE `sbtest1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`k` int(11) NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=20000001 DEFAULT CHARSET=utf8mb4
----》》》#mysql 客户端操作：
-》场景1：空闲的数据库，进行修改数据字段的操作
-> CHANGE 字段字符编码 ，1000万大表执行时间为26分钟，等待事件为Waiting for table metadata lock，正常
16:24:10
alter table sysbench_test.sbtest1 modify column pad char(60) character set latin1;
mysql> alter table sysbench_test.sbtest1 modify column pad char(60) character set latin1;
Query OK, 0 rows affected (26 min 0.78 sec)
Records: 0 Duplicates: 0 Warnings: 0
-》场景2：繁忙的数据库，对该表的频繁的dml操作，dml操作全部阻塞，等待事件为Waiting for table metadata lock，
同时进行ddl,1000万大表执行时间完成事件31分钟
mysql> alter table sysbench_test.sbtest1 modify column pad char(60) character set latin1;
Query OK, 10002797 rows affected (30 min 44.51 sec)
Records: 10002797 Duplicates: 0 Warnings: 0
----》》》#pt工具修改
-》场景1：空闲的数据库，进行修改数据字段的操作
-》换一种方法是用pt工具修改 字段字符类型，消耗时间为34分钟。虽然事件多出了7分钟，但是影响面比较小，因为这是复制一张新表，然后在复制回原来表，
-》影响原来的表事件不多
sh pt.sh sbtest1 "modify column pad char(60) character set utf8mb4"
脚本如下：
#!/bin/bash
table=$1
alter_conment=$2
cnn_host='127.0.0.1'
cnn_user='root'
cnn_pwd='Admindb'
cnn_db='sysbench_test'
echo "$table"
echo "$alter_conment"
pt-online-schema-change --user=${cnn_user} --password=${cnn_pwd} --host=${cnn_host} P=3306,D=${cnn_db},t=${table} --charset=utf8 --no-version-check --alter "${alter_conment}" --execute
结果如下
[root@sdwsmn2 dba]# sh pt.sh sbtest1 "modify column pad char(60) character set utf8mb4"
sbtest1
modify column pad char(60) character set utf8mb4
No slaves found. See --recursion-method if host sdwsmn2 has slaves.
Not checking slave lag because no slaves were found and --check-slave-lag was not specified.
Operation, tries, wait:
analyze_table, 10, 1
copy_rows, 10, 0.25
create_triggers, 10, 1
drop_triggers, 10, 1
swap_tables, 10, 1
update_foreign_keys, 10, 1
Altering `sysbench_test`.`sbtest1`...
Creating new table...
Created new table sysbench_test._sbtest1_new OK.
Altering new table...
Altered `sysbench_test`.`_sbtest1_new` OK.
2022-05-10T15:53:14 Creating triggers...
2022-05-10T15:53:14 Created triggers OK.
2022-05-10T15:53:14 Copying approximately 9754681 rows...
Copying `sysbench_test`.`sbtest1`: 6% 07:16 remain
Copying `sysbench_test`.`sbtest1`: 11% 07:24 remain
。。。。。
Copying `sysbench_test`.`sbtest1`: 99% 00:09 remain
2022-05-10T16:27:57 Copied rows OK.
2022-05-10T16:27:57 Analyzing new table...
2022-05-10T16:27:57 Swapping tables...
2022-05-10T16:27:58 Swapped original and new tables OK.
2022-05-10T16:27:58 Dropping old table...
2022-05-10T16:27:59 Dropped old table `sysbench_test`.`_sbtest1_old` OK.
2022-05-10T16:27:59 Dropping triggers...
2022-05-10T16:27:59 Dropped triggers OK.
Successfully altered `sysbench_test`.`sbtest1`.
-》场景2：繁忙的数据库，对该表的频繁的dml操作，dml操作不会阻塞，可以正常进行，
同时进行ddl,1000万大表执行时间完成事件41分钟
2022-05-10T17:21:07 Copying approximately 9696990 rows...
2022-05-10T18:00:47 Analyzing new table...
2022-05-10T18:00:48 Swapping tables...
2022-05-10T18:00:49 Swapped original and new tables OK.
2022-05-10T18:00:49 Dropping old table...
2022-05-10T18:00:50 Dropped old table `sysbench_test`.`_sbtest1_old` OK.
2022-05-10T18:00:50 Dropping triggers...
2022-05-10T18:00:50 Dropped triggers OK.
#######sample 3 进一步思考on-line ddl ,和 pt-osc 的区别
https://opensource.actionsky.com/20200916-ddl/
-》如何选择
从原理中，可以看出几个关键点：
-
可以看到 pt-osc、gh-ost、原生 Online DDL copy 方式（实际上是非 Online），都是需要 copy 原表数据到一个新表，这个是非常耗时的；
-
pt-osc 采用触发器实现应用 DDL 期间的 DML, gh-ost 通过 binlog 应用 DDL 期间的 DML，理论上触发器会有一定的负载，且 gh-ost 可以从从库上拉取binlog，对主库的影响更小；
-
原生 Online DDL 中 Inplace 方式，对于 no-rebuild 方式，不需要重建表，只需要修改表的元数据，这个是非常快的；
-
原生 Online DDL 中 Inplace 方式，对于 rebuild 方式，需要重建表，但是也是在 InnoDB 内部完成的，比 copy 的方式要快；
-》因此，总结以下几个选择工具的判断依据：
1. 如果 MySQL 版本是 5.6 之前，不支持 Online DDL，选用第三方工具 pt-osc 或 gh-ost；
2. 如果 MySQL 版本是 5.6 以上，对于使用 copy table 方式的 DDL，不支持 Online，使用第三方工具 pt-osc 或 gh-ost；
3. 对于可以使用 Inplace no-rebuild 方式的 DDL，使用原生 Online DDL；
4. 对于使用 Inplace rebuild table 方式的 DDL，如果想使 DDL 过程更加可控，且对从库延迟比较敏感，使用第三方工具 pt-osc 或 gh-ost，否则使用原生 Online DDL；
5. 对于想减少对主库的影响，实时交互，可以选用 gh-ost；
-》
4.1.1 MySQL 原生 DDL
自 MySQL 5.6 起，MySQL 原生支持 Online DDL，即在执行 DDL 期间允许执行 DML(insert、update、delete)。了解 Online DDL 先了解一下之前 DDL 的 2 种算法 copy 和 inplace。
-》Copy：
1. 按照原表定义创建一个新的临时表
2. 对原表加写锁（禁止 DML，允许 select）
3. 步骤 1）建立的临时表执行 DDL
4. 将原表中的数据 copy 到临时表
5. 释放原表的写锁
6. 将原表删除，并将临时表重命名为原表可见，
采用 copy 方式期间需要锁表，禁止 DML，因此是非 Online 的。
-》比如：删除主键、修改列类型、修改字符集，这些操作会导致行记录格式发生变化（无法通过全量 + 增量实现 Online）。
-》Inplace：在原表上进行更改，不需要生成临时表，不需要进行数据 copy 的过程。根据是否行记录格式，分为两类：
-
rebuild：需要重建表（重新组织聚簇索引）。比如 optimize table、添加索引、添加/删除列、修改列 NULL/NOT NULL 属性等；
-
no-rebuild：不需要重建表，只需要修改表的元数据，比如删除索引、修改列名、修改列默认值、修改列自增值等。
对于 rebuild 方式实现 Online 是通过缓存 DDL 期间的 DML，待 DDL 完成之后，将 DML 应用到表上来实现的。
例如，执行一个 alter table A engine=InnoDB;
重建表的 DDL 其大致流程如下：
1. 建立一个临时文件，扫描表 A 主键的所有数据页；
2. 用数据页中表 A 的记录生成 B+ 树，存储到临时文件中；
3. 生成临时文件的过程中，将所有对 A 的操作记录在一个日志文件（row log）中；
4. 临时文件生成后，将日志文件中的操作应用到临时文件，得到一个逻辑数据上与表 A 相同的数据文件；
5. 用临时文件替换表 A 的数据文件。
说明：1. 在 copy 数据到新表期间，在原表上是加的 MDL 读锁（允许 DML，禁止 DDL）
2. 在应用增量期间对原表加 MDL 写锁（禁止 DML 和 DDL）
3. 根据表A重建出来的数据是放在 tmp_file 里的，这个临时文件是 InnoDB 在内部创建出来的，整个 DDL 过程都在 InnoDB 内部完成。对于 server 层来说，没有把数据挪动到临时表，是一个原地操作，这就是“inplace”名称的来源。
-》测试用例
3.2 使用示例
本示例模拟修改列类型，将列类型由 char(20) 修改为 varchar(200)
版本信息：MySQL 5.7.25，percona-tool 3.2.0
数据量 200 万
准备
3.2.1 创建用户
3.2.2 写 ALTER 语句GRANT SELECT, INSERT, UPDATE, DELETE, \CREATE, DROP, PROCESS, REFERENCES, \INDEX, ALTER, SUPER, LOCK TABLES, \REPLICATION SLAVE, TRIGGERON *.* TO 'ptosc'@'%'modify c varchar(200) not null default ""3.2.3 环境检查
说明：工具在执行时也会进行检查，如果遇到不能执行的情况，则报错，建议在执行前先进行 dry-run。3.2.3.1 检查要变更的表上是否有主键或非空唯一键3.2.3.2 检查是否有其他表外键引用该表mysql> desc sbtest1;+-------+-----------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+-------+-----------+------+-----+---------+----------------+|| k | int(11) | NO | MUL | 0 | ||| pad | char(60) | NO | | | |+-------+-----------+------+-----+---------+----------------+4 rows in set (0.00 sec)select * from information_schema.key_column_usage where referenced_table_schema='testdb' and referenced_table_name='sbtest1'\G*************************** 1. row ***************************CONSTRAINT_CATALOG: defCONSTRAINT_SCHEMA: testdbCONSTRAINT_NAME: test2_ibfk_1TABLE_CATALOG: defTABLE_SCHEMA: testdbTABLE_NAME: test2COLUMN_NAME: t_idORDINAL_POSITION: 1POSITION_IN_UNIQUE_CONSTRAINT: 1REFERENCED_TABLE_SCHEMA: testdbREFERENCED_TABLE_NAME: sbtest1REFERENCED_COLUMN_NAME: id1 row in set (0.01 sec)若有，则需要使用 –alter-foreign-keys-method 选项
3.2.3.3 检查表上是否有触发器*************************** 1. row ***************************ACTION_REFERENCE_OLD_TABLE: NULLACTION_REFERENCE_NEW_TABLE: NULL1 row in set (0.00 sec)若有，则需指定 –preserve-triggers 选项，且在 percona tool 3.0.4 起，对于 MySQL 5.7.2 以上，支持原表上有触发器，建议使用前在测试环境进行测试。
官方 issue 链接：https://jira.percona.com/browse/PT-913.2.3.4 检查从库是否设置 change filter
show slave status\G...Replicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:如果设置了 change filter，则不会执行，除非指定 –no-check-replication-filters
3.2.4 执行 dry run
# pt-online-schema-change --print --statistics \--progress time,30 --preserve-triggers --user=ptosc \--password=ptosc --alter 'modify c varchar(200) not null default ""' \h=127.0.1.1,P=3306,D=testdb,t=sbtest1 \--pause-file=/tmp/aa.txt --max-load=threads_running=100,threads_connected=200 \--critical-load=threads_running=1000 --chunk-size=1000 \--alter-foreign-keys-method auto --dry-runOperation, tries, wait:analyze_table, 10, 1copy_rows, 10, 0.25create_triggers, 10, 1drop_triggers, 10, 1swap_tables, 10, 1update_foreign_keys, 10, 1Child tables:`testdb`.`test2` (approx. 1 rows)Will automatically choose the method to update foreign keys.Starting a dry run. `testdb`.`sbtest1` will not be altered. Specify --execute instead of --dry-run to alter the table.Creating new table...CREATE TABLE `testdb`.`_sbtest1_new` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` char(120) COLLATE utf8mb4_bin NOT NULL DEFAULT '',`pad` char(60) COLLATE utf8mb4_bin NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)) ENGINE=InnoDB AUTO_INCREMENT=2000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_binCreated new table testdb._sbtest1_new OK.Altering new table...ALTER TABLE `testdb`.`_sbtest1_new` modify c varchar(200) not null default ""Altered `testdb`.`_sbtest1_new` OK.Not creating triggers because this is a dry run.Not copying rows because this is a dry run.INSERT LOW_PRIORITY IGNORE INTO `testdb`.`_sbtest1_new` (`id`, `k`, `c`, `pad`) SELECT `id`, `k`, `c`, `pad` FROM `testdb`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= ?)) AND ((`id` <= ?)) LOCK IN SHARE MODE /*pt-online-schema-change 6337 copy nibble*/SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `testdb`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= ?)) ORDER BY `id` LIMIT ?, 2 /*next chunk boundary*/Not determining the method to update foreign keys because this is a dry run.2020-08-23T13:24:19 Adding original triggers to new table.Not swapping tables because this is a dry run.Not updating foreign key constraints because this is a dry run.Not dropping old table because this is a dry run.Not dropping triggers because this is a dry run.DROP TRIGGER IF EXISTS `testdb`.`pt_osc_testdb_sbtest1_del`DROP TRIGGER IF EXISTS `testdb`.`pt_osc_testdb_sbtest1_upd`DROP TRIGGER IF EXISTS `testdb`.`pt_osc_testdb_sbtest1_ins`2020-08-23T13:24:19 Dropping new table...DROP TABLE IF EXISTS `testdb`.`_sbtest1_new`;2020-08-23T13:24:19 Dropped new table OK.# Event Count# ====== =====# INSERT 0Dry run complete. `testdb`.`sbtest1` was not altered.
–print：打印工具执行的 SQL 语句。
–statistics：打印统计信息。
–pause-file：当指定的文件存在时，终止执行。
–max-load：超过指定负载时，暂定执行。
–critical-load：超过指定负载时，终止执行。
–chunck-size：指定每次复制的行数。
–alter-foreign-keys-method：指定外键更新方式。
–progress：copy 进度打印的频率。
3.2.5 执行
将 –dry-run 修改为 –execute如上，输出比较简单，包括了每一步执行的 SQL。copy 数据期间打印了 copy 的进度以及预计剩余时间；最后打印出统计信息，比如 insert 的数据块数。# pt-online-schema-change --print --statistics \--progress time,30 --preserve-triggers --user=ptosc \--password=ptosc --alter 'modify c varchar(200) not null default ""' \h=127.0.1.1,P=3306,D=testdb,t=sbtest1 \--pause-file=/tmp/aa.txt --max-load=threads_running=100,threads_connected=200 \--critical-load=threads_running=1000 --chunk-size=1000 \--alter-foreign-keys-method auto --executeFound 2 slaves:10-186-64-51 -> 10.186.64.51:330610-186-64-48 -> 10.186.64.48:3306Will check slave lag on:10-186-64-51 -> 10.186.64.51:330610-186-64-48 -> 10.186.64.48:3306Operation, tries, wait:analyze_table, 10, 1copy_rows, 10, 0.25create_triggers, 10, 1drop_triggers, 10, 1swap_tables, 10, 1update_foreign_keys, 10, 1Child tables:`testdb`.`test2` (approx. 1 rows)Will automatically choose the method to update foreign keys.Altering `testdb`.`sbtest1`...Creating new table...CREATE TABLE `testdb`.`_sbtest1_new` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` char(120) COLLATE utf8mb4_bin NOT NULL DEFAULT '',`pad` char(60) COLLATE utf8mb4_bin NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)) ENGINE=InnoDB AUTO_INCREMENT=2000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_binCreated new table testdb._sbtest1_new OK.Altering new table...ALTER TABLE `testdb`.`_sbtest1_new` modify c varchar(200) not null default ""Altered `testdb`.`_sbtest1_new` OK.2020-08-23T14:44:53 Creating triggers...2020-08-23T14:44:53 Created triggers OK.2020-08-23T14:44:53 Copying approximately 1972656 rows...INSERT LOW_PRIORITY IGNORE INTO `testdb`.`_sbtest1_new` (`id`, `k`, `c`, `pad`) SELECT `id`, `k`, `c`, `pad` FROM `testdb`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= ?)) AND ((`id` <= ?)) LOCK IN SHARE MODE /*pt-online-schema-change 15822 copy nibble*/SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `testdb`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= ?)) ORDER BY `id` LIMIT ?, 2 /*next chunk boundary*/Copying `testdb`.`sbtest1`: 52% 00:27 remainCopying `testdb`.`sbtest1`: 99% 00:00 remain2020-08-23T14:45:53 Copied rows OK.2020-08-23T14:45:53 Max rows for the rebuild_constraints method: 4000Determining the method to update foreign keys...2020-08-23T14:45:53 `testdb`.`test2`: 1 rows; can use rebuild_constraints2020-08-23T14:45:53 Adding original triggers to new table.2020-08-23T14:45:53 Analyzing new table...2020-08-23T14:45:53 Swapping tables...RENAME TABLE `testdb`.`sbtest1` TO `testdb`.`_sbtest1_old`, `testdb`.`_sbtest1_new` TO `testdb`.`sbtest1`2020-08-23T14:45:54 Swapped original and new tables OK.2020-08-23T14:45:54 Rebuilding foreign key constraints...ALTER TABLE `testdb`.`test2` DROP FOREIGN KEY `test2_ibfk_1`, ADD CONSTRAINT `_test2_ibfk_1` FOREIGN KEY (`t_id`) REFERENCES `testdb`.`sbtest1` (`id`)2020-08-23T14:45:54 Rebuilt foreign key constraints OK.2020-08-23T14:45:54 Dropping old table...DROP TABLE IF EXISTS `testdb`.`_sbtest1_old`2020-08-23T14:45:54 Dropped old table `testdb`.`_sbtest1_old` OK.2020-08-23T14:45:54 Dropping triggers...DROP TRIGGER IF EXISTS `testdb`.`pt_osc_testdb_sbtest1_del`DROP TRIGGER IF EXISTS `testdb`.`pt_osc_testdb_sbtest1_upd`DROP TRIGGER IF EXISTS `testdb`.`pt_osc_testdb_sbtest1_ins`2020-08-23T14:45:54 Dropped triggers OK.# Event Count# ================== =====# INSERT 2000# rebuilt_constraint 1Successfully altered `testdb`.`sbtest1`.3.2.6 执行后检查
3.2.6.1 检查原表是否正确修改
mysql> show create table sbtest1\G*************************** 1. row ***************************Table: sbtest1Create Table: CREATE TABLE `sbtest1` (`id` int(11) NOT NULL AUTO_INCREMENT,`k` int(11) NOT NULL DEFAULT '0',`c` varchar(200) COLLATE utf8mb4_bin NOT NULL DEFAULT '',`pad` char(60) COLLATE utf8mb4_bin NOT NULL DEFAULT '',PRIMARY KEY (`id`),KEY `k_1` (`k`)) ENGINE=InnoDB AUTO_INCREMENT=2000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin1 row in set (0.00 sec)mysql> desc sbtest1;+-------+--------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+-------+--------------+------+-----+---------+----------------+| id | int(11) | NO | PRI | NULL | auto_increment || k | int(11) | NO | MUL | 0 | || c | varchar(200) | NO | | | || pad | char(60) | NO | | | |+-------+--------------+------+-----+---------+----------------+4 rows in set (0.01 sec)3.2.6.2 检查引用该表的外键
3.2.6.3 检查原表上触发器mysql> show create table test2\G*************************** 1. row ***************************Table: test2Create Table: CREATE TABLE `test2` (`id` int(11) NOT NULL AUTO_INCREMENT,`t_id` int(11) DEFAULT NULL,PRIMARY KEY (`id`),KEY `_test2_ibfk_1` (`t_id`),CONSTRAINT `_test2_ibfk_1` FOREIGN KEY (`t_id`) REFERENCES `sbtest1` (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin1 row in set (0.00 sec)
mysql> show triggers\G*************************** 1. row ***************************Trigger: trig1Event: INSERTTable: sbtest1Statement: INSERT INTO time VALUES(NOW())Timing: AFTERCreated: 2020-08-23 14:45:53.96sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTIONDefiner: root@localhostcharacter_set_client: utf8collation_connection: utf8_general_ciDatabase Collation: utf8mb4_bin1 row in set (0.00 sec)