案例一：
环境说明：mysql 5.6
用户连接不上mysql ，查看error 日志：unble to lock ./ibdata1 error，等待20分钟左右，在启动mysql恢复正常。./ibdate1 文件 40G
解决方法：
1、查看slow log
2、show procedure status
#查看存储过程，该实例有很多存储过程
3、show create procedure 存储过程名称 \G
结论：复杂的存储过程(数据库里的数据也不对)，导致sql语句执行的时间很长，7万多秒。这时mysql hug住了 占用了./ibdate1 文件
案例二：
有一个线上库的ibdate1文件从1G，一直不断增长到100多G，到底怎么回事呢?
ibdate1 文件暴增原因：
- 大量事务，产生大量来不及purge的undo log
- 有旧事务长时间未提交，产生大量旧undo log
- file i/o 性能差，purge进度慢
- 32bit系统下有bug
- 使用共享表空间方式，所有表数据放在一起
大量事务，产生大量来不及purge的undo log
最新事务ID：21520177836
最新purged的事务ID：21516167648
二者相差：4010188
等待purge的undo事务列表：41341108
有旧事务长时间未提交，产生大量旧undo log
解决办法：
调度ibdate1的初始大小
innodb_date_file_path = ibdata1:1G:autoextend
升级到5.6及以上(64-bit),采用独立undo表空间
innodb_undo_directory = path
innodb_undo_logs = 128
innodb_undo_tablespaces = 126
启用独立表空间，ibdata1 只存放系统数据
innodb_file_per_table = 1
增加purge线程数
innodb_purge_threads = 4
提高file i/o能力
raid 10 & wb & BBU
xfs
deadline/noop
ssd/pice ssd
事务及时提交，不要积压
及时commit/rollback
注意事务自动提交设置
默认打开autocommit = 1
检查开发框架，确认autocommit =0 的地方，事务结束后都有提交或回滚
mysql参数优化:
innodb_buffer_pool_size：约物理内存的50%~~70%
innodb_date_file_path:初始大小至少1G
设置独立数据表空间以及独立undo表空间(5.6+)
innodb_log_file_size ,5.5及以上1G以上，5.5以下建议不超过512M
innodb_flush_log_at_trx_commit,0 => 最快数据最不安全，1 =>最慢最安全，2=>折中
innodb_max_dirty_pages_pct: 25%~~50% 为宜
innodb_io_capacity ：普通机械盘=>1000左右，ssd=>10000左右，PCle SSD=>20000以上