一、系统粒粒面应该避免长事务，如果你是业务开发负责人同时也是数据库负责人，你会有什么方案来避免出现或者处理这种情况呢？

首先，从应用开发端来看：

1、确认是否使用了set autocommit=0。这个确认工作可以在测试环境中开展，把MySQL的general_log开起来，然后随便跑一个业务逻辑，通过general_log的日志来确认。一般框架如果会设置这个值，也就会提供参数来控制行为，你的目标就是把它改成1。

2、确认是否有不必要的只读事务。有些框架会习惯不管什么语句先用begin/commit框起来。有些业务并没有这个需要，但是也把好几个select语句放到了事务中。这种只读事务可以去掉。

3、业务连接数据库的时候，根据业务本身的预估，通过set max_execution_time命令，来控制每个语句执行的最长时间，避免单个语句意外执行太长时间。

其次，从数据库端来看：

1、监控infoirmation_schema.Innodb_trx表，设置长事务阈值，超过就警报/或者kill。

2、Percona的pt-kill这个工具不错，推荐使用。

3、在业务功能测试阶段要求输出所有的general_log，分析日志行为提前发现问题。

4、如果使用的是MySQL 5.6或者更新版本，把innodb_undo_tablespaces设置成或更大的值。如果真的出现大事务导致回滚段过大，这样设置后清理起来更方便。

二、InnoDB表T，如果你要重建索引k，你的两个sql语句可以这么写：

alter table T drop index k;

alter table T add index(k);

如果你要重建主键索引，也可以这么写：

alter table T drop primary k;

alter table T add primary key(k);

问题是，对于上面两个重建索引的作法，说出你的理解。如果有不适合的，为什么，更好的方法是什么？

重建索引k的作法是合理的，可以达到省空间的目的。但是，重建主键的过程不合理。不论是删除主键还是创建主键，都会将整个表重建。所以连着执行者两个语句的话，第一个语句就白做了。这两个语句，可以用这个语句代替：alter T engine=InnoDB。