单条insert会导致什么？

HI ALL~
闲来无事，分享一条insert的坑，希望研发同学引以为戒。故事还要从五天前说起…
一个平和宁静，风和日丽的中午，我还在午睡，突然被线上急促告警邮件声惊醒，打开相关电脑一看，主库活跃连接数过多，主库反应卡顿，从库io线程中断，过了几秒钟，自己恢复了。一切的现象都和AWS磁盘抖动有关，通过阿里的orz监控发现，这次磁盘抖动的现象和以往不一样啊，磁盘的吞吐很高，iops很低，await很高，第一次告警也没在意，觉得就是AWS的硬件问题，因为AWS的磁盘真的真的经常抖…
但是，事情远远没有想象的那么简单，到了半夜，这告警又来？2次？研发同学第二天带着黑黑的眼圈过来找我，我于心不忍，表示一定要AWS给个回复，当天给AWS提了CASE，AWS回复也算及时，表示我们的硬件No problem，我不是很信，但也在挖掘更多的信息，通过一些监控，发现大量写入导致了磁盘吞吐的性能瓶颈，并定位到几条大事务的SQL，但现在看来都不是出现的问题的SQL，delete五千行这样的，接下来就是推动研发优化，但是有个过程，线上告警几个小时来一次，先磁盘升下配吧，将gp2的磁盘升至了io1，吞吐提升至1000M，纳尼？还是有告警，隔了一天，将iops升至了16000，纳尼 ？还是有告警，磁盘的配置已经很高了，这下该怎么办？？？
扯了半天犊子，差点忘了这是个技术类的文章，言归正传。说下现象，几次告警有个共同点
1、主库卡顿，无法及时响应请求
2、从库IO中断，通过show slave status看到io_thread:connecting
3、从库io延迟
4、binlog文件异常大，远超过max_binlog_size

问题定位：
1、通过orzdba监控发现当时磁盘吞吐达到上限，await高是造成主库卡顿的原因
2、从库io中断，目前想到的原因是主库卡顿，从库slave_net_timeout是8s，主库4s像从库发送心跳包失败，从库8s后重连，但是主库未及时响应从库重连请求
3、大量写入导致io延迟，一般是由于大字段的导致io出现延迟
4、通过解析binlog，发现了一条insert 的大字段，大字段的插入类似向二维集合一样，包含了90000个值，并且一直在批量插，没放在一个事务里，为什么binlog文件变得那么大？和组提交有关？和COMMIT_ORDER有关？后面研究研究

后面找研发同学把这条SQL优化了，告警就没了。

总之：大字段不要用，对于大字段的使用可以放到mongodb中去使用。