我也不知道，就写写吧
- int（10）与int（11）的区别
MySQL类型关键字后面的括号内指定整数值的显示宽度(例如，INT(11))。该可选显示宽度规定用于显示宽度小于指定的列宽度的值时从左侧填满宽度。显示宽度并不限制可以在列内保存的值的范围，也不限制超过列的指定宽度的值的显示。
所以INT(10)和INT(11)默认是没有任何区别的
- char与varchar的区别
char是一种固定长度的类型，varchar则是一种可变长度的类型char(M)类型的数据列里，每个值都占用M个字节，如果某个长度小于M，MySQL就会在它的右边用空格字符补足.在检索操作中那些填补出来的空格字符将被去掉）在varchar(M)类型的数据列里，每个值只占用刚好够用的字节再加上一个用来记录其长度的字节（即总长度为L+1字节）
- MySQL主从数据库同步
- 原理
谈到MySQL数据库主从同步延迟原理，得从mysql的数据库主从复制原理说起
mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生binlog，binlog是顺序写，
所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率很比较高
问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。
DML和DDL的IO操作是随即的，不是顺序的，成本高很多，还可能可slave上的其他查询产生lock争用，
由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。
当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，
当然还有就是可能与slave的大型query语句产生了锁等待。
- 解决方案
最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。
还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
