AnySQL.net

    在MySQL中binlog的作用和Oracle中的归档日志类似, Oracle中提供了DBMS_LOGMNR来对日志文件进行分析, 来解出Redo SQL和Undo SQL, MySQL中也提供了一个名为mysqlbinlog的工具, 用来解释或取出存放在binlog中的SQL语句, 有没有Undo SQL我到是没有研究过. 最基本的使用语法如下:

mysqlbinlog [options] log_file ...

    在选项中, 可以指定一些过滤条件, 来解出你所想用的东西, 这样的选项有:

--database=db_name, -d db_name

--offset=N, -o N

--[start|stop]-datetime=datetime

--[start|stop]-position=N

    解出来的就是一条一条SQL语句了, 将这些语句执行一下, 就等于增量恢复了, 估计不是用绑定变量的, 可能在MySQL中是不是绑定变量不是很重要了. 当然重要的一点是不要运行多个进程去跑, 因为这样的话, 顺序就得不到保证了. 如下所示:

$ mysqlbinlog binlog.000001 >  /tmp/statements.sql
$ mysqlbinlog binlog.000002 >> /tmp/statements.sql
$ mysql -e "source /tmp/statements.sql"

    Oracle的LogMiner不太爽是因为他不是离线的, 做成MySQL这样的倒是比较方便多了. 看到这儿也应当可以想象到, MySQL中的复制大约是什么回事了吧?

    在MySQL中并没有Shared Pool来共享SQL及其执行计划, 因此是否共享不是很重要, 在程序中是否使用绑定(Bind)变量也不是很重要. 事实上在目前的版本中, 只有Server Side的编程才能使用绑定变量, 而客户端的程序虽然用了绑定变量, 但实际是上只是被进行了文本替换, 最早我在MySQL的JDBC驱动说明上看到了这一点, 现在用Perl程序(asyncdata.pl)从Oracle向MySQL复制数据时(启动MySQL时指定--log选项)从SQL的日志文件中看到如下记录:

Query       DELETE FROM T_OBJECTS WHERE OBJECT_ID='441766' AND 1=1
Query       DELETE FROM T_OBJECTS WHERE OBJECT_ID='441767' AND 1=1
Query       DELETE FROM T_OBJECTS WHERE OBJECT_ID='441768' AND 1=1

    而根据MySQL的解释, 使用真正的绑定变量时, SQL的日志文件应当记录如下:

Prepare  [1] SELECT ?
Execute  [1] SELECT 3

    而我找遍了整个日志文件, 也没有发现Prepare字样, 虽然我的Perl程序中调用了prepare方法. MySQL中另一个功能Query Cache则刚好是建立在不绑定的基础上的, 这个缓冲区会将最近执行过的SQL的结果存起来, 下同遇到同样的SQL(区分大小写的文本比较)时, 就直接将结果返回来, 但如果这个SQL下面的的表有数据变动, 则将再次执行, 这个功能默认是禁用(query_cache_size的默认值为0)的, 估计现实生活中, 这样的应用少. 看起来象如下:

my (%qcache);

if (query_cache_size)
{
    if (exists $qcache{SQL})
    {
        return $qcache{SQL}
    }
    else
    {
        my $rows = mysql_execute(SQL);
        $qcache{SQL} = $rows;
        return $rows;
    }
}
else
{
    return mysql_execute(SQL);
}

    其实MySQL中有内存表了, 完全可以不用这个功能. 对于Query Cache, MySQL提供了query_cache_type变量来控制发送到数据库的SQL是否进行Cache, 有三个值:

0, 对SQL语句不进行Cache.

1, 对于有SQL_NO_CACHE提示的SQL不进行Cache.

2, 仅对于有SQL_CACHE进示的SQL进行Cache.

    这个设计比较先进, 不过最好加上一个对表进行不进行Cache的控制, 如果指定某个表Cache则对所有只访问这个表的SQL进行Cache, 这样可能要对DBA方便很多, 否则我们得一条一条地更改SQL语句啊. 不知道有没有用过这个功能的人? 谈谈感想?

    MySQL正如日中天, 不了国外有人发表了不用MySQL的14个理由, 在这儿我意译了一下.

1. 折扣让许可证费或服务费不再是问题.
2. 不必在意是否具有你并不需要的功能.
3. 管理少量大型数据库比大量MySQL简单.
4. 如果跑在Windows上, 为什么不用SQL Server?
5. 过去,SQL Server是很优良的中型数据库.
6. 微软对SQL Server管理工具作了很大改进.
7. Oracle也简化了很多数据库的工具和管理.
8. 都提供便宜或免费的版本, 升级时兼容性也好.
9. 业务增长很快时, 不如及早上大型数据库.
10. 很多或更好的数据类型支持.
11. MySQL上出现的问题更多.
12. MySQL的一些特有的功能, 并没有做得很好.
13. 传统数据库有更多更好的第三方软件支持.
14. 没有因为推荐用传统数据库而被开除.

    当然招致了很多人的反驳, 还一条一条地反驳呢, 就在回复里面, 英文水平有限, 不意译了, 自已看吧. 不过, 一开始的选择的确需要慎重.