前几日，遇到的问题，表数据量不是很大，研发人员，修改表结构，导致数据库出现大量元数据锁等待，由于是5.5版本的数据库，对表进行alter操作是要锁表的。
解决：
show processlist;查看数据库出现大量元数据锁等待。
select * from information_schema.innodb_trx;命令查看，正在获得锁的SQL
找到之后，将线程ID 杀死。此时数据库恢复正常
---------------------------------------------------------------------
？有人会想，该SQL已经运行了，一段时间，中途KILL，那么表是改了还是没有改，是改了一部分吗？
？此时从库是怎么做的？
---------------------------------------------------------------------
那么针对这两个问题，做了个实验：
环境一主一从：
mysql数据库修改字段的过程：
a:创建一个临时的新表，首先复制旧表的表结构包含索引
create table new_table like old_table;
b:给新的表添加字段等操作
c:把旧表的数据复制过来
insert into new_table(file1,file2...) select file1,file2... from old_table;
d:删除旧表，重命名旧表的名字为新表的名字
1、在主库执行SQL，等数据库执行完了的情况
（1）在主库执行alter table wxj2 add address varchar(10) not null;操作之后；
主库查看show processlist;此时数据库显示 altering table
此时查看主库的binlog文件，并没有记录alter table的SQL语句，此时登录从库查看show processlist;没有显示alter table操作。binlog也没有记录
（2）等待主库将这个SQL语句执行完了，将执行的SQL语句，记录到自己的binlog日志中，此时从库把binlog写入到自己的中继日志中，重复主库的操作。那么此时，如果主库有对该表大量的写入，从库会出现延迟。
2、在主库执行SQL，执行了一半的时候，在主库将alter操作KILL掉，查看主从的状况。
（1）在主库执行alter table wxj2 modify address varchar(100) not null;语句，此时数据库正在做copy to tmp table.此时binlog没有记录，如果此时线上业务出现高峰，阻塞，那么直接将改语句进行kill掉。binlog是没有记录的，因为此时正在拷贝数据，SQL还没有执行完，不记录 BINLOG。此时数据库是没有任何更改的，从库当然也没有。因为主库没有记录BINLOG。
总结：alter操作，是SQL执行完毕，才记录BINLOG，中途将SQL中止掉，是不记录BINLOG的，那么主库和从库都不会修改。
=================================================================================================
下面是使用PT工具修改表结构，查看 binlog记录的格式
=================================================================================================
在主库使用工具修改表结构：
pt-online-schema-change --no-version-check --execute --critical-load="Threads_running=1200" --alter-foreign-keys-method=auto --alter "add column sie1_length DECIMAL(7,2) NOT NULL DEFAULT 0.00" h=10.205.9.55,P=3306,u=root,p=123456,D=pp,t=wxj2
主库执行该命令的时候，会把PT工具执行的原理过程都记录到自己的BINLOG中，建新表，创建触发器，alter操作，然后向新表拷贝数据，此时从库看到有新的binlog写入，也会跟着在自己的从库，重新操作一遍。
此时从库也会出现延迟！！！！
总结：alter操作是原子性 ，要么成功，要么失败，而pt工具修改，过程是正常SQL操作，需要写入BINLOG，所以，如果一个大表使用PT工具修改表结构，BINLOG会增加很多。