diff --git a/published/20150709 Why is the ibdata1 file continuously growing in MySQL.md b/published/20150709 Why is the ibdata1 file continuously growing in MySQL.md
index af798b387a..64f74aecb0 100644
--- a/published/20150709 Why is the ibdata1 file continuously growing in MySQL.md	
+++ b/published/20150709 Why is the ibdata1 file continuously growing in MySQL.md	
@@ -6,7 +6,7 @@
 
 当监控服务器发送一个关于 MySQL 服务器存储的报警时，恐慌就开始了 —— 就是说磁盘快要满了。
 
-一番调查后你意识到大多数地盘空间被 InnoDB 的共享表空间 ibdata1 使用。而你已经启用了 [innodb_file_per_table][2]，所以问题是：
+一番调查后你意识到大多数地盘空间被 InnoDB 的共享表空间 ibdata1 使用。而你已经启用了 [innodb\_file\_per\_table][2]，所以问题是：
 
 ### ibdata1存了什么？ ###
 
@@ -17,7 +17,7 @@
 - 双写缓冲区
 - 撤销日志
 
-其中的一些在 [Percona 服务器][3]上可以被配置来避免增长过大的。例如你可以通过 [innodb_ibuf_max_size][4] 设置最大变更缓冲区，或设置 [innodb_doublewrite_file][5] 来将双写缓冲区存储到一个分离的文件。
+其中的一些在 [Percona 服务器][3]上可以被配置来避免增长过大的。例如你可以通过 [innodb\_ibuf\_max\_size][4] 设置最大变更缓冲区，或设置 [innodb\_doublewrite\_file][5] 来将双写缓冲区存储到一个分离的文件。
 
 MySQL 5.6 版中你也可以创建外部的撤销表空间，所以它们可以放到自己的文件来替代存储到 ibdata1。可以看看这个[文档][6]。
 
@@ -82,7 +82,7 @@ MySQL 5.6 版中你也可以创建外部的撤销表空间，所以它们可以
 
 没有，目前还没有一个容易并且快速的方法。InnoDB 表空间从不收缩...参见[10 年之久的漏洞报告][10]，最新更新自詹姆斯·戴（谢谢）：
 
-当你删除一些行，这个页被标为已删除稍后重用，但是这个空间从不会被回收。唯一的方法是使用新的 ibdata1 启动数据库。要做这个你应该需要使用 mysqldump 做一个逻辑全备份，然后停止 MySQL 并删除所有数据库、ib_logfile*、ibdata1* 文件。当你再启动 MySQL 的时候将会创建一个新的共享表空间。然后恢复逻辑备份。
+当你删除一些行，这个页被标为已删除稍后重用，但是这个空间从不会被回收。唯一的方法是使用新的 ibdata1 启动数据库。要做这个你应该需要使用 mysqldump 做一个逻辑全备份，然后停止 MySQL 并删除所有数据库、ib_logfile\*、ibdata1\* 文件。当你再启动 MySQL 的时候将会创建一个新的共享表空间。然后恢复逻辑备份。
 
 ### 总结 ###