如果有正在进行的写操作，MySQL会等待这些操作完成。这意味着，直到所有之前的写事务提交或回滚，索引创建操作才会开始。在此期间，表对于其他写操作而言是不可用的，可能会导致这些操作等待或者超时

也可以自定义脚本，使用探活语句来判断，好处是能够确认数据库连接情况（因为可能存在端口开着，数据库无法连接的情况），但是也有缺点，在数据库压力较大的时候可能会探活失败，导致误报。

存储过程调用子存储过程试试

给你举个例子。我以前做的。mysqlbinlogstartdatetime'2018082112:50:00'stopdatetime'2018082113:05:00'base64outputdec

innodb理论上64T。实际上很少有人做到这个。多大不是问题。就看你维护的了吗？我以前oracle单表100TB也没问题，但是有人mysql1T就不行了。不是数据库的问题，是人的问题。

是老的mysql的环境变量没删除导致的，记录一下这个经验

1.对于应用来说是丢失链接，因为应用的请求是通过mycat去分发的。应用只会认为，mysql无法连接，执行的事务失败。2.对于mysql来说突然宕机，对于宕机的服务器来说，内存的东西丢掉了，写入日志的

看是否符合索引覆盖看索引排序是否是SQL排序相同

MySQL中的更新操作会生成撤销日志（undolog），用于事务回滚和MVCC。与Oracle的UNDORETENTION不同，MySQL没有直接设置来控制undolog保留时间。InnoDB存储引擎

你的ab要做成双主模式才行。