ITPub博客

记得以前，当出现：ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction，要解决是一件麻烦的事情 ；特别是当一个SQL执行完了，但未COMMIT，后面的SQL想要执行就是被锁，超时结束； DBA光从数据库无法着手找出源头是哪个SQL锁住了； 有时候看看show engine innodb status , 并结合 show full processlist; 能暂时解决问题；但一直不能精确定位；在5.5中，information_schema 库中增加了三个关于锁的表（MEMORY引擎）；innodb_trx ## 当前运行的所有事务innodb_locks ## 当前出现的锁innodb_lock_w

在以前的版本中，一个事务请求表的“元数据锁”直到“语句”执行完毕；（这个时候整个事务没有完成）；这个时候，如果有人执行了DDL语句（如DROP table，可以马上执行）；那么在BINLOG日志中，会先记录drop table ,再记录事务的相关语句（因为事务后COMMIT）；这时候到SLAVE上面去应用就会报错；[@more@]在5.5中，这个表的“元数据锁”一直到整个"事务"全部完成后才会释放 ；这也意味着当一个表被一个事务使用（哪怕只有SELECT），在事务结束前就不对这个表作DDL；这样也就可以避免上面说到的日志顺序错误的问题；以下是原文：I

在之前版本，碎片回收操作是主线程的一部分，这经定期调度的方式运行，但会阻塞数据库的其他操作；[@more@]到5.5以后，可以将这个线程独立出来 ；方法：innodb_purge_threads =1 这个应该能让碎片回收得更及时而且不影响其他线程的操作；Improved Purge Scheduling - The InnoDB purge operation is a type of garbage collection that runsperiodically. In previous versions, the purge was part of the master thread, meaning that it couldblock other database operations when running. In MySQL 5.5 this operation can run in

1) 用正式表达式 regexp "[u0391-uFFE5]" 2) 用length和char_length[@more@] drop table t1; create table t1 ( id varchar(200)) default charset=utf8 ; insert into t1 values ('中文'),('sdalfkj'); 1)用正式表达式 regexp "[u0391-uFFE5]"root@127.0.0.1 : test 21:55:33> select id ,id regexp "[u0391-uFFE5][u0391-uFFE5]" from t1;+---------+--------------------------------------------+| id | id regexp "[u0391-uFFE5][u0391-uFFE5]" |+---------+---------------------

昨天鹰眼需求从一个大表（27G）删除47026788数据；用存储过程通过主键删除实现；用了1个小时50分钟； QPS=47026788/(60*110)=7125.2709这个速度已经满快了，都是随机读；[@more@]当时我在想，MASTER用近两个小时，是不是SLAVE也用这么长时间么；到SLAVE一看，根本没有SQL在跑；而且表里数据已经被清空；通过测试，我们发现MASTER在应用存过时，在BINLOG里记录的是真正最后执行的DML操作；比如： #101202 13:58:43 server id 2 end_log_pos 15842 Query thread_id=4058 exec_time=0 error_code=0SET TIMESTAMP=129126952

InnoDB buffer pool 被设为两个SUBLIST：一个是存放大部分查询所需用到的块；另一个是存放小量查询所需用到的块；并可以被回收；[@more@]The InnoDB buffer pool is divided into two sublists: A new sublist containing blocks that are heavily used by queries,and an old sublist containing less-used blocks and from which candidates for eviction are taken. InnoDB buffer pool 被设为两个SUBLIST：一个是存放大部分查询所需用到的块；另一个是存放小量查询所需用到的块；并可以被回收； In the default operation of the buff

Mysql半同步SLAVE，类似于ORACLE安全模式的DATAGUARD（但不完全是）；为什么是半同步呢，因为MYSQL只保证“至少一个”SLAVE接收到日志后返回； 虽然可能不会有太多的人去用这个东西（因为对网络的要求和机器的稳定性很高）；但MYSQL还是补全了这一块的功能缺失[@more@] A commit performed on the master side blocks before returning to the session that performed the transaction until at least one slave acknowledges that it has received and logged the events for the transaction. Semisynchronous replication is

在5.1版本中，slave 从MASTER拿到日志后，写到relay-log,并进行SQL应用；在这里注意，写到RELAY-LOG，指的是先写到 “OS cache”的relay-log，而不是马上刷新到磁盘上；什么时候刷新还依赖于操作系统的CACHE刷新时间；[@more@]如果在这期间，一个日志刚同步到"relay-log @os cache ",而没有被刷新到"relay-log @disk", OS CRASH, 那么这个日志将丢失；（这个问题不用担心：MYSQL会在重启后重新从MASTER获取日志）同样存在一致问题的相关SLAVE文件还有：relay-log.info ; master.info; 如果这两个文件发生不一致，问题

# 在5.1版本上，这FILE_IO这一块MYSQL只用了4个线程来处理IO；# 但在5.5上，随着对多线程的更强支持；INNODB也加强了对IO读写线程的支持；更多发挥多线程的优势 ；# IO线程默认增加到了10个；（配太多也没用，因为IO能力有限，需要配合特殊机型）# 其实这个在5.5.0就已经增强了，不过在这里讲也不晚；[@more@]### 5.1# innodb_file_io_threads# The number of file I/O threads in InnoDB. # Normally, this should be left at the default value of 4, but disk I/O on Windows may benefit from a larger number.# On Unix, increasing

MYSQL 5.0.68 on RHEL 5u4 本实验主要是想看一下，INNODB 页何时被回收，何时被重新利用； 数据文件何时扩展，按多少比例扩展等；[@more@]MYSQL 5.0.68 on RHEL 5u4 Innodb Record 组成 ：--------------------------- Field Start Offsets ：(F*1) or (F*2) bytes ，F=字段个数Extra Bytes ：6 bytes Field Contents ：三个系统字段（ROWID,TXID（6B）,PID（7B） ） + 数据内容； 如果有主键，ROWID=PK；Innodb PAGE 组成 (16K)： ---------------------------Fil Header ： 38BPage Header：

If you want to Import data from dat file to Mysql , May be you will choose : Load Data infile; Normally, you will create a table without index (include primary key) ,then load the data , then create the index ; But ,I found after load data and create primary key , "select count(*) from T" is so slowly. [@more@]#### ENV OS:RHEL 5U4 MYSQL: 5140 Engine: Innodb #### Create Table ; CREATE TABLE `http_auth1` ( `username` varchar(64) NOT NULL, `pass` varchar(200) DEFAULT NULL, `co

# Mysql 5140 @ RHEL 5u4 X86_64 [@more@]# 先提供一些表的信息:===================================================================root@127.0.0.1 : trac_apsara 17:18:46> show create table wiki G*************************** 1. row *************************** Table: wikiCreate Table: CREATE TABLE `wiki` ( `name` longtext COLLATE utf8_bin, `version` int(11) DEFAULT NULL, `time` bigint(20) DEFAULT NULL, `author` longtext COLLATE utf8_bin, `ipnr` longtext COLLATE utf8_bin, `text` longtext

接同事需求，要求从SQLITE的数据转到MYSQL，这东西以前也没接触过。这里搜搜，那里试试，下面把过程列一下。 主要过程分三步：1，把SQLITE表结构导出来，作一定的格式调整2，把SQLITE数据导出来，作特殊字符的处理3，导出MYSQL（注意字符集）[@more@]下面是我操作的过程， 有两个部分：单表操作和批量处理（含脚本） ########### 单表操作 ##################### 打开SQLITE DBroot> sqlite3 mig.db # 查看表,可用用".help"获得帮助sqlite>.tables # 导出数据表结构sqlite>.output /tmp/heyf/createtable.sqlsqlite&gt

TEST STEP6：用"constraints_parser"试着从一个PAGE（找到INDEX_ID相对应的文件夹）中找出你的数据TEST STEP7: 如果你觉得你的数据没有问题，那么你可以将所有的表连接起来（cat *.page > table.page），用此方法恢复所有的数据.把数据导回表中[@more@]TEST STEP6：用"constraints_parser"试着从一个PAGE（找到INDEX_ID相对应的文件夹）中找出你的数据---------------------- || cd /opt/percona-innodb-recovery-tool || [root@localhost percona-innodb-recovery-tool]# ./constraints_parser -5 -U -f pages-

TEST STEP3：得到表定义文件：table_defs.hTEST STEP4：编译percona-innodb-recovery-tool，makeTEST STEP5：将数据表空间拆分成N个16K大小的PAGE[@more@]TEST STEP3：得到表定义文件：table_defs.h （可以用create_defs.pl自动产生），并替换include/table_defs.h.---------------------- || [root@localhost percona-innodb-recovery-tool]# perl create_defs.pl --table=recover1 || #ifndef table_defs_h || #define table_defs_h || || // Table definitions || table_def_t table_definitions[] = { || { ||

下面我们来看一个实例，用来恢复被TRUNCATE的数据----------------------------------------------[@more@]TEST STEP 0：创建测试环境：----------------------MYSQL 5140 at RHEL 5u4 X86_64use test;create table recover1 (id int auto_increment , c1 varchar(50), c2 varchar(100) ,primary key (id) ) engine=innodb;insert into recover1(c1,c2) values ('aaaaaa','bbbbbb');insert into recover1(c1,c2) select c1,c2 from recover1 ;insert into recover1(c1,c2) select c1,c2 from recover1 ;insert into recover1(c1,c2) selec

如何得到表定义文件：./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