ITPub博客

MyISAM Key buffer命中率：100 - ( (Key_reads * 100) / Key_read_requests )MyISAM Key buffer的使用率：100 - ( (Key_blocks_unused * key_cache_block_size) * 100 / key_buffer_size ) InnoDB Buffer Pool 的命中率(Innodb_buffer_pool_read_requests - Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100%[@more@]

最近机房那边中毒，网络经常不正常，经常导致MySQL的复制中断，前几次都是报Got fatal error 1236: 'error reading log entry' from master when reading data from binary log的错误，今天却出现一个奇怪的现象，从库上show slave status一切正常，主库上却没有了slave i/o的连接，从库日志中也没发现异常。因此我crontab中定期检查slave status的任务也检查不到错误了，没办法stop slave;start slave;复制恢复正常。。。。[@more@]

原文作者：风轻扬出处：http://wangyuanzju.blog.163.com/blog/static/1302920070245344752/前两篇文章中已经通过介绍Falcon的架构和对面向Web 2.0的存储引擎的讨论引出数据访问扭曲这一话题，对于我接触更多，也是最为流行的两大开源DBMS：PostgreSQL和MySQL，自然忍不住按它 来比较一把了。由于这一问题只与DBMS的存储系统有关，因此这里实际上比较的是PostgreSQL与MySQL的事务型存储引擎InnoDB。PostgreSQL与InnoDB都采用多版本并发控制技术，但两者在存储的实现机制上仍然有以下两个重大差别：PostgreSQL用堆存储记录，而InnoDB用按

4、 自适应的哈希索引 如果一个表几乎完全缓存在主内存中，在其上执行查询最快的方法就是使用哈希索引。InnoDB有一个自动机制，它监视对为一个表定义的索引的索引搜索。如果InnoDB注意到查询会从建立一个哈希索引中获益，它会自动地这么做。 注意，哈希索引总是基于表上已存在的B树索引来建立。根据InnoDB对B树索引观察的搜索方式，InnoDB会在为该B树定义的任何长度的键的一个前缀上建立哈希索引。 哈希索引可以是部分的：它不要求整个B树索引被缓存在缓冲池。InnoDB根据需要对被经常访问的索引的那些页面建立哈希索引。 在某种

MySQL把表的数据词典信息以.frm文件的形式存在数据库目录里，所有MySQL存储引擎都是这样的。但是每个InnoDB表在表空间内的InnoDB内部数据词典里也有它自己的条目。当MySQL移除表或数据库，它不得不删除.frm文件和InnoDB数据词典内的相应条目。这就是为什么你不能在数据库之间简单地移动.frm文件来移动InnoDB表。 [@more@]1、聚集索引和第二索引 每个InnoDB有一个叫聚集索引（clustered index）的特殊索引，行的数据被存于其中。如果你的表定义了主键，主键的索引就是聚集索引。 如果你的表没有主键，MySQL就选择第一个不可为空的唯

因为InnoDB是多版本化的数据库存储引擎, 它必须在表空间中保存关于旧版本数据行的信息。这个信息被存在名为rollback segment（类似于Oracle中的回滚段）的数据结构中。[@more@]在内部，InnoDB给数据库中的每一行添加三个域。一个是6字节的DB_TRX_ID域，用来说明插入或更新该行的最后一个事务的事务识别符。同时，删除操作也被内部处理为更新操作，其中行中一个特殊的位被设置用来标注该行已删除。每一行也包含一个称为回滚指针的7字节DB_ROLL_PTR域。回滚指针指向一个写在回滚段中的撤销日志记录。如果该行被更新，撤销日志记录包含重

sysbench是一款开源的性能测试工具，可以对多种数据库的性能进行测试，包括用来对MySQL，ORACLE，POSTGRESQL进行性能测试。 sysbench按照指定的数量开启线程,每个线程与MySQL建立一个连接,每个线程不停地进行事务操作，打开事务，然后进行一些查询、更新、插入操作，提交事务，再开始新的事务；所有的SQL只访问一个表sbtest，是由sysbench的prepare命令建好的。其中的记录数，也是在prepare时指定好并创建的。测试结束，会有一个统计结果，包括例如每秒事务数、平均响应时间等等。下面是一个sysbench调用调用存储过程的例子：[@more@]sys

前几天群里有人问MySQL的游标能不能嵌套使用，想当然地以为不能，后来试了下，居然可以，唉，不能随便想当然啊。例子如下：[@more@]CREATE PROCEDURE curdemo() NOT DETERMINISTIC CONTAINS SQL SQL SECURITY DEFINER COMMENT ''BEGIN declare done1,done2 int default 0; declare name1,name2 varchar(20); declare id1,id2 int; declare cur1 cursor for select id,name from test1; declare continue handler for not found set done1 = 1; open cur1; repeat fetch cur1 into id1, name1; if not done1 then

大型的系统，数据库往往会根据业务逻辑分隔放在多台机上，但统计的时候又经常需要互相关联，MySQL理论上是不支持多个主库同步到一个从库上的，那么如果实现多主一从以方便统计查询呢？我试着利用MyISAM的简单文件存储的特点来实现，过程如下：[@more@] 1设置主库，启用Binlog，建议复制帐号。具体过程跟一主多从设置一样。 2设置从库，在从库使用mysqld_multi启动多库实例，每个实例对应一个主库，并分别设置好主从复制。需要注意的是，1、从库只安装MyISAM引擎，这样不管主库是用什么引擎，从库都使用MyISAM。2、从库的几个实例的数据目

今天几台MySQL服务器突然停电，重启后复制无法启动，总是报如下错误：080922 10:29:01 [Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000778' at position 2874108, relay log './relay-bin.003287' position: 2874245080922 10:29:01 [Note] Slave I/O thread: connected to master 'replication@192.168.0.10:3306', replication started in log 'mysql-bin.000778' at position 2874108080922 10:29:01 [ERROR] Error reading packet from server: Client requested master to start replication fro

http://imysql.cn/2008_06_17_sth_about_update_duplicate_key原来mysql在update时也可以order by，学习了。。[@more@]

昨天修改一个表的字段，发现主从复制同步失效了，但同步进程没有出错，mysql日志也没有出错，仔细查找了一下原因，发现是新增的自增主键字段的起始值在主从库上不一致，导致按主键更新数据时无法在从库找到对应记录。事情经过如下：[@more@]表table1（主库为innodb类型，从库为MyISAM类型），有一自增主键pid，现将pid改成非自增，非主键，另外增加一自增主键。alter table table1 modify pid int not null;alter talbe table1 drop primary key;alter table table1 add aid int not null auto_increment primary key first;结果主库上表t

如果使用innodb存储引擎，推荐使用innotop来监控管理，详见：http://www.xaprb.com/blog/2006/07/02/innotop-mysql-innodb-monitor/如果想在windows下使用，请参照：http://www.xaprb.com/blog/2006/11/11/how-to-install-innotop-on-microsoft-windows/[@more@]

Address 为Innodb表，AppUser 为FEDERATED表，下面的连接查询如果用INNER JOIN 就正常，用left join连接的结果Name全为null，即使有匹配的行，怀疑是mysql的bugselect a.*,b.Name from Address AS aLEFT JOIN AppUser AS b ON b.AID = a.CheckAdminIDwhere a.AID=1006948暂时解决办法：将AppUser改名AppUser1，建个视图AppUser引用AppUser1，结果正常。[@more@]