ITPub博客

如何得到表定义文件：./include/table_defs.h ----------------------------------------- table_defs.h 可以从多种渠道得到： 1，如果你还拥有建表语句，那么你可以把表建起来，然后用"create_defs.pl"生成。 2，另外你也可以手动生成。但千万不要忘了两个内部字段（DB_TRX_ID，DB_ROLL_PTR）[@more@] 下面有一个例子供参考： || #ifndef table_defs_h || #define table_defs_h || || // Table definitions || table_def_t table_definitions[] = { || { || name: &q

就像是ORACLE的DUL，MYSQL也有自己的数据抽取工具：Innodbrecoverytool。他能根据表定义（table_defs.h），从数据表空间中抽取丢失的数据。他可以在以下几种情况下恢复数据：　-------------------------------------------- delete from table where 1=1 -- truncate table -- drop table , ## need .ibd-- corrupted tablespace.[@more@]在恢复过程中，我们主要用到以下几个工具： --------------------------------------------**`page_parser`**： 将表空间文件导出成N个多少16K大小的PAGE文件；--**`constraints_parser`** 从以上产生

如果你拥有一个很大的内存，那么在享受性能的同时，你也享受着CRASH时，恢复时漫长等待的痛苦。 http://www.mysqlperformanceblog.com/2007/07/17/innodb-recovery-is-large-buffer-pool-always-better/这个情况在MYSQL 5.5，InnoDB Plugin 1.0.7以后将有所改变 [@more@]（以下内容部分转载）首先来了解一个崩溃恢复的原理 ： 崩溃恢复（Crash recovery）可以看成两个阶段， 第一阶段称为扫描重做日志（Redo scan），这时InnoDB读取磁盘上的Redo Log，并将其存放到一个Hash表中； 第二阶段应用这些Redo Log，将这些日志应用到Data Page上

cat $SQLFILE | while read -r LINE -r Backslash does not act as an escape character. The backslash is considered to be part of the line. In particular, a backslash-newline pair may not be used as a line continuation.[@more@] 我们来看一下效果：（注意read后面的-r）[root@im_ctuallot2 dmp-heyf]# cat del_on_db1111.sqldelete from ctulog.db_allot where id='cntaobao[;'[]';delete from ctulog.db_allot where id='cntaobaogirl's kiss';delete from ctulog.db_allot

ITPUB上有提问： 一个关于mysql中limit优化的问题 | stest | CREATE TABLE `stest` ( `id` int(10) unsigned NOT NULL, `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 | 第一条测试语句 mysql> select * from stest where id>=(select id from stest order by id asc limi t 900000,1) limit 50; 50 rows in set (2.58 sec) 第二

今天碰到了一次MYSQL CRASH,不像以前是BUG所致，这次是人为搞死的，又是一次血的教训 直接触发原因：　在白天业务期间执行了200W的DELETE语句（自动 提交）；以下是当时的日志和状态信息：100811 17:06:06 InnoDB: ERROR: the age of the last checkpoint is 1887429810,InnoDB: which exceeds the log group capacity 1887429428.InnoDB: If you are using big BLOB or TEXT rows, you must set theInnoDB: combined size of log files at least 10 times bigger than theInnoDB: largest such row.[@more@]100811 17:06:22 InnoDB: ER

单引号，以及行尾的斜杠引起的困惑：这一次的问题，我们直接从实际的工作中说起：工作内容简介： 有一批用户ID存在文件里，需要从数据库里删除？做这个事情，可能有很多的方法： 1， 把ID导入到数据库中，用SQL直接做表关联去删除 ； 2， 用SHELL（或其他语言）写个小程序，根据文件里的ID做一个FOR 循环，然后在MYSQL中去删除 ； 3， 用sed直接把ID转成delete语句，完了直接运行即可；[@more@]由于数据量较大（1.6亿），显然，我会用偷懒以及简单的方法3 ： ----------------------------------------------[root@im_ctuallot1 tmp]# cat

select * from table where id in (....)这样的查询，是走范围索引还是走等值索引？ select * from table where key_part1 in (....) and key_part2='XX';这样的查询，第二部分还走不走索引？测试目的，想知道，MYSQL对IN LIST是如何选择执行计划的；在单字段索引和复合索引中；[@more@]mysql 5.1.40os:rhel 5.4 engine=innodbinnodb_file_per_table# 先来创建测试环境： create table index_test ( id int auto_increment , col1 int ,col2 varchar(200) ,content varchar(500),primary key (id) ,key col1 (col1) ) engine=innodb de

一天有开发同学问我，说，我们表里的数据怎么都不区分大小写的。能不能把他们区分开来。 我猜想他说的应该就是校对规则相关的事情。 与之确认后是这么一回事：[@more@]root@127.0.0.1 : test 23:36:25> drop table if exists `t1`;Query OK, 0 rows affected (0.00 sec)root@127.0.0.1 : test 23:36:25> CREATE TABLE `t1` (-> `name` varchar(10) -> ) ENGINE=MyISAM DEFAULT CHARSET=utf8;Query OK, 0 rows affected (0.03 sec)root@127.0.0.1 : test 23:36:25> insert into t1 values ('A1'),('a1');Query OK, 2 rows a

OS：RHEL5u4_X64VER:MYSQL5.1.40MASTER_ERROR.LOG 报错： 100722 11:56:19 InnoDB: Error: unlock row could not find a 4 mode lock on the record100722 11:56:19 InnoDB: Error: unlock row could not find a 4 mode lock on the record100722 11:56:19 InnoDB: Error: unlock row could not find a 4 mode lock on the record[@more@]从错误看，非常像BUG 41756 ：http://bugs.mysql.com/bug.php?id=41756但条件场景不太像，我们系统变量 innodb_locks_unsafe_for_binlog=OFF，而以上BUG innodb_locks_unsafe_for_binlog=ON 才出现

MYSQL日志：100721 11:01:42 - mysqld got signal 11 ;This could be because you hit a bug. It is also possible that this binaryor one of the libraries it was linked against is corrupt, improperly built,or misconfigured. This error can also be caused by malfunctioning hardware.We will try our best to scrape up some info that will hopefully help diagnosethe problem, but since we have already crashed, something is definitely wrongand this may fail.[@more@]key_buffer_size=335544320read_buffer_size=1048

听同学介绍，MYSQL性能测试工具supersmack不错。 于是拿来搞一把。 [@more@]1.下载软件 http://vegan.net/tony/supersmack/ 2.编译安装 ./configure --prefix=/usr/local/supersmack --with-mysql --with-mysql-lib=/usr/lib64/mysql --with-mysql-include=/usr/include/mysqlmake && make install 3.配置测试信息cp /usr/local/supersmack/bin/* /usr/bin/cp /tmp/super-smack-1.3/smacks/* /usr/local/supersmack/bin/3.1 配置帐号密码 #修改 *.smack 里面的帐号密码及测试使用的数据库。(搜索：localhost)3.2 配置 测试类型比

Why my Shared-tablespace is so Big size; The Size of all DB just 40G , But Size of Shared-tablespace is 49G; I wonder What's inside ? [@more@]MYSQL: 5.0.68-enterprise-gpl-logOS: RHEL5u3 X86_64[root@im_offlog11a mysql]# ll | more total 1237270300-rw-rw---- 1 mysql mysql 49530535936 Jul 2 19:03 ibdata1-rw-rw---- 1 mysql mysql 524288000 Jul 2 19:03 ib_logfile0-rw-rw---- 1 mysql mysql 524288000 Jul 2 18:07 ib_logfile1-rw-rw---- 1 mysql mysql 524288000 Jul 2 18:42 ib_logfile2-rw-rw---- 1 m

上次在 http://steven1981.itpub.net/post/7967/497170 讨论：Mysql索引的使用-组合索引+跳跃条件结果是：KEY（key_part1,key_part2,key_part3）select .... from table where key_part1='xxx' and key_part3='yyy'; 在这种情况下，MYSQL只能在索引里处理掉key_par1，而不过在索引里过滤 key_part3的条件，除非 select 后面是 count(*) ;[@more@]这是上次测试时的表结构：CREATE TABLE `im_message_201005_21_old` (`msg_id` bigint(20) NOT NULL default '0',`time` datetime NOT NULL,`owner` varchar(64) NOT NULL,`other` varchar(64

## 实验环境：　双MASTER 结构　Master1 == 10.249.160.132Master2 == 10.249.160.133RHEL 5.4 X64, MYSQL 5.1.40 binlog_format = MIXED tx_isolation = READ-COMMITTED (这里有一个要点： READ-COMMITTED + INNODB , MYSQL 强制使用ROW 日志模式）[@more@]## 初始化数据use test; set names gbk; drop table if exists h1 ;create table h1 (id int , name varchar(20),comment varchar(500 ) , primary key (id))engine=innodb default charset =gbk ; insert into h1 values (1,'h1','h111'),(2,'h2','h112'),(3,'h3','h113'),(4,'h4'

关于MYSQL组合索引的使用，官方对下面的例子的说法是可以使用索引：KEY（key_part1,key_part2,key_part3）select .... from table where key_part1='xxx' and key_part3='yyy';从MYSQL的执行计划看，确实也是使用索引;但在实际的优化过程中，我们只是简单的关注是否使用了这个索引是不够的。[@more@]我们需要关注的是: 对key_part3这个关键字过滤的时候，是否用到了索引？ 下面我们来创建一个例子： CREATE TABLE `im_message_201001_12` ( `msg_id` bigint(20) NOT NULL default '0', `time` datetime NOT NULL, `owne

外键，FOREIGN KEY, 这个东东，作为DBA，在Oracle我们都不建议在数据库级别去实现约束，因为他的维护成本很高， 比如你要保证索引，导入数据时你得保证先后顺序等，所以我们更推荐由应用去控制逻辑。在MYSQL中是更不推荐使用，不过在这里主要是说说使用过程中要注意的问题。[@more@]## 建立约束，注意命名规范 FK1，FK2，FK3 ... 如果不指定约束名，系统会自动创建一个。 create table ... ... constraint `FK1` foreign key (`user_id`) REFERENCES `user`(`id`) ON DELETE CASCADE ON UPDATE CASCADE## 相应的字段（foreign key and

再次研究COLOCATION，希望其能在<2resource2group4score>的配置环境中起作用，（限制两个资源跑到一起）。1，配置：在<2resource2group4score>CIB.XML中， <configuration> ... <constraints> ... <rsc_colocation id="colocation1" to="IPaddr_10_2_225_225" from="mysql" score="INFINITY" symmetrical="true"> </rsc_colocation> </constraints> </configuration> 加完以后，请用crm_verify

今天发现数据库报检查到死锁，而且有大量的回滚。 当时状态见：< show engine innodb status G 结果>这个库压力比较大，但从STATUS看，都是 lock mode AUTO-INC waiting.而且从应用开发了解到，都是简单的INSERT和select。 没有交叉更新的事务。 如果是等待AUTO-INC锁，也不应该会产生死锁。因为AUTO-INC锁在某一时刻只会被一个事务/INSERT操作占有。INSERT一旦完成就会释放AUTO-INC锁。那怎么会有死锁呢? [@more@]于是上bugs.mysql.com 报了个BUG：http://bugs.mysql.com/bug.php?id=49084得到回复：[25 Nov 5:38] Valeriy Kravch

基于HA在发生切换时，都会做STOP本机资源，然后再START对方的资源。我们的实际环境中有两个资源: 一个是IPaddr,用来管理VIP;一个是mysql, 用来管理MYSQL资源;在实际的应用过程中，我们发现MYSQL一下子关不掉（flush dirty pages),或启动需要很长时间（recovery）.这样也就大大延长了HA切换的时间。所以我们在想，是不是可以让HA只管理MYSQL的状态，而不管理MYSQL的启动与STOP呢？[@more@]我们知道，HA管理lsb类型的资源时，是调用/etc/init.d/或者./resource.d/ 目录下的该资源相关命令加参数start/stop/status.比如，有mysql资源，启动my