41：ibdata 共享表空间使用注意事项，insert buffer 何种情况下会增长很快，undo 何种情况下会增长很快，将 undo 从 ibdata 里面独立出来，初始化数据库的时候，之后就不能改变了；或者说：如何将 undo 从 ibdata 分离出来，初始设置 ibdata 大小 10G。
ibdata共享表空间里包括：undo、insert buffer、double write、数据字典。
insert buffer增长很快的情况：
索引过多
有些索引较冷
数据更新频繁
表序与索引序差距大
undo增长很快的情况：
并发量大
长事务、大事务多
将undo从ibdata里独立出来需要在初始化数据库的时候，之后无法进行修改，即使修改也无法独立出来。
innodb_undo_directory | 设置rollback segment文件所在的路径，默认为’.’。 |
Innodb_data_file_path | 该参数设置ibdata的空间大小及其路径，默认为10M。 |
42：理解 sock 文件和 pid 文件，在启动过程中存在的陷阱。
sock文件：系统连接MySQL数据库有好几种方式，其中的套接字方式就需要一个套接字文件，即sock文件，该文件由参数socket控制，默认在/tmp目录下，所以如果使用该方式启动时，且sock文件不在该目录下，应指定sock文件启动。如果该文件丢失，可以通过重启数据库重新创建。
pid文件：MySQL数据库启动时会产生自身的进程ID，pid文件就是用来保存进程ID的，该文件由参数pid_file控制，默认在数据库目录下。如果这个文件丢了，可以自行创建，然后将ID数字写入里面。
43：理解 basedir ，特别是里面的结构。
basedir是MySQL数据库的安装路径目录，里面存放数据库实例的数据。
44：详细解读 tpcc 压力测试结果，同时进行硬件和参数的性能调整，调整以后重新进行压力测试，看一下结果的变化情况。
45：使用 zabbix 对我们的压力测试结果进行绘图。
通过自定义item动态获取tpcc压测出的事务量的值，设置为10s一次，在图表上进行展现，可直观看到MySQL数据库事务的动态变化量。
46：主键的选择依据，以及 IOT 表的存储结构以及对 insert 和 select 的场景要求（考虑批量增加用户的速度） IOT 对于通过主键批量取数据的特点（综合考虑）。
IOT表即索引组织表，是按照主键顺序组织存放的，每张表都会有主键，在MySQL中，主键索引就是聚集索引，其本身就是一个B+树，数据页为聚集索引的叶子节点。
主键的选择为非空且唯一的列，一般会选择id类型的具有唯一标示性的数字列作为主键，也可以设置自增长列作为主键。如果在创建表的时候没有显式的定义主键，innodb存储引擎会按照以下规则选择或创建主键：
1.先看表中是否存在非空的唯一索引，如果有，则该列为主键（如果有多个选择，会选择在创建表时第一个定义且符合要求的索引列）；
2.如果没有，会自行创建一个6字节大小的指针，即ROWID。
insert的时候会选择走主键索引，具有主键约束；
select的时候要看具体查询的列来判断走什么索引以及需不需要回表排序等操作。
批量增加用户时，因为主键约束的存在且锁的范围有可能会导致锁全表；如果是自增长列的话还应该考虑自增长锁的设置。
通过主键批量取数据的特点：
IOT表本身就按照主键顺序进行存放
数据页即聚集索引的叶子节点，不需要回表
47：如何提升 IOT 表批量 insert 的效率。
主键依次递增
48：详细描述如何从一个表中读取一行数据的过程，研究可变长度和 null 位的意义。
innodb存储引擎提供了compact和redundant两种格式来存放行的记录。MySQL5.1版本之后默认使用compact的格式。
变长字段长度列表：按照列的顺序逆序放置，若列的长度小于255字节，用1字节表示，若大于255字节，用2字节表示。
null标志位：指示了该行数据中是否有NULL值，有则用1表示。
49：如何评估 ddl 语句对表的操作风险，举几个例子：增加列，修改列的名字，修改列的长度（加长和减小）。
增加列：会修改表中每一行的数据，数据量大时慎重；
修改列的名字：跟数据无关，只会修改数据字典里的信息；
加长列的长度：会修改表中每一行的数据，数据量大时慎重；
减小列的长度：不允许被操作，因为无法修改已存储的数据，容易造成数据溢出。
50：MySQL 如何减少 delete 操作对 undo 空间占用。
首先要知道在Oracle undo记录中，INSERT产生最少的undo，Update产生的undo居中，而Delete操作产生的undo最多。
对于INSERT操作，回滚段只需要记录插入记录的rowid，如果回退，只需将该记录根据rowid删除即可；
对于UPDATE操作，回滚段只需要记录被更新字段的旧值即可（前镜像），回退时通过旧值覆盖新值即可完成回退；
对于DELETE操作，则必须记录整行的数据，在回退时，通过一个反向操作恢复删除的数据。
在MySQL数据库中，进行了delete操作时数据并不会被立马删除，而是进行标记，后期会通过purge线程进行真正的删除，这是因为MVCC的特性；而通过undo回滚时会直接通过行数据上的事务id列和回滚指针列定位到之前的行数据，因此避免了delete操作对undo空间的占用。
