testing-04
很难说Optimize Table到底能不能提高系统运行效率，但是有一点是肯定的：它能够帮我们回收更多的空间、减少“碎片”（defragment）。
1. 回收空间 Defragment
在InnoDB的维护过程中，我们总会遇到磁盘耗尽、或者InnoDB Tablespaces用完的情况。这时候，在考虑扩容等方案之前，最好先使用Optimize Table试试。如果你的表大字段（Text Blob Varchar），并且更新、删除较频繁的话，Optimize之后可能会腾出大量的空间。 (more…)
InnoDB Plugin在快速DDL上做了一些改进，在做的实验中看到，创建secondary indexes时，大约快了20%。
1. 原理
在MySQL5.0里面，如果数据表的记录数很多，增加和删除索引是非常慢的。CREATE INDEX and DROP INDEX命令是通过先创建一个空的临时表，这个表就是你新增或删除索引后的结构，然后把原表中的全部记录都拷贝（插入）到新的临时表中，最后把原表删除，临时表重命名成原表。
MySQL5.1的一些架构上的改变，可以简化上面的过程（不再需要逐行拷贝数据）。InnoDB Plugin利用这个改变，缩短了大多数情况下的索引变更时间。对InnoDB来说有两类索引：the clustered index and secondary indexes。因为InnoDB的主键是the clustered index，数据存放再此，所以，删除或者添加主键（the clustered index）逐行拷贝也是必须 (more…)
这两天是O’Reilly MySQL Conference & Expo，期间有很多关于MySQL的相关话题的介绍，包括MySQL、PBXT、Drizzle、MariaDB、XtraDB等等，不过最抢风头的应该是InnoDB1.0.7GA（with MySQL-5.5）的新特性，回头想想，Oracle/InnoDB也酝酿了很久的吧。
无论如何，这些新特性中最吸引我的是InnoDB的Faster Recovery。
一般地，MySQL/InnoDB都是运行在普通的PC Server + Linux（Unix），虽然不期待小型机+AIX的高可用，但想尽一切办法缩短MySQL的不可用时间，仍然是DBA的目标。根据经验，主机OS崩溃、硬件故障，仍然是影响MySQL可用性的最主要因素，当这些故障（OS、硬件）恢复后，另一个非常耗时的恢复就是InnoDB自己的恢复时间。一般主机发生一次重启，正常大约<5分钟，而这时InnoDB恢复可能需要40分钟或者更久（这依赖于Buffer Pool、脏页面比例、TPS等因素）。 (more…)
Percona are doing great job on Xtrabackup which help us a lot. We use it on most of our MySQL server, and it works quite fine. Xtrabckup not only helps us make the daily backup(sometimes recovery), but also help a lot setup the replication with less impact on the online server.
It is pleasure to share my experience here,which may make Xtrabackup works better.
1. Is the process of “copy-back” necessary?
Although the wiki tells us do the “copy-back” after the “apply-log”, but people found it is not necessary. Actually it will take a lot of time if you have a huge databases(e.g. > 50G).
Here is the usual process to make recovery from a tar backup,which I did in the last month.
* Extraction of the tar stream:
迫于开源社区、团体（Google Facebook Percona Xaprb等）的巨大压力，InnoDB Plugin相比Built-in版本有了很大的提升，这些提升多数来自开源社区贡献的代码，虽然本身也有一些改进。
1. 关于Fast locking
在多个线程并发访问相同资源的时候，需要使用一些InnoDB实现的互斥量（mutex）和读写锁（read/write lock）。在Unix-like平台上，InnoDB是通过Pthread的互斥量（这是POSIX标准的一部分）来实现的。在现代OS和硬件平台中，一般都有了更有效的替代方案，多数情况下这些替代方案使用更少的CPU指令和时钟周期来完成这些互斥处理。
(more…)
Plugin的一个重要的特性就是增加了压缩存储。对于数据中有很多Long column(包括TEXT BLOB或者大VARCHAR)的场景能够大幅节约空间，并提升效率。
1. 谁需要压缩？
在InnoDB中，是以16K的页（Page）为基本的存储单位的。我们知道，InnoDB是的数据是在Clustered index中存储的，在Secondary index中仅存储对应数据的PK。Clustered index和Secondary index都是B-Tree结构的，所以对InnoDB数据页和索引页的压缩很大程度上就是对B-Tree节点页的压缩。
在InnoDB中，除了B-Tree节点页，还有一类数据页（Page），称为“overflow page”。当需要存储Long column时，如果当前页能够完全存储全部字段时，则存储在当前页中；如果当前页不足以存储全部，则InnoDB选择最长的字段，将其存储到一个单独的页中，我们称这样的页为“overflow page”，而原数据页仅仅需存储一个20Bytes的指针。参考下图：
所以InnoDB除了有上面的B-Tree页外，InnoDB还存储overflow页。事实上，需要压缩的数据页也就是这两类，InnoDB为了获得更好的效率，针对这两类数据页的压缩是使用不同的策略的。