Mysql
配置mysql丛库小心使用replicate_do_db和replicate_ignore_db
0小心使用replicate_do_db和replicate_ignore_db2009-01-07 15:54使用replicate_do_db和replicate_ignore_db时有一个隐患,跨库更新时会出错
如设置 replicate_do_db=test
use mysql;
update test.table1 set ……
第二句将不会被执行
如设置 replicate_ignore_db=mysql
use mysql;
update test.table1 set ……
第二句会被忽略执行
原因是设置replicate_do_db或replicate_ignore_db后,MySQL执行sql前检查的是当前默认数据库,所以跨库更新语句被忽略。
可以使用replicate_wild_do_table和replicate_wild_ignore_table来代替
如
replicate_wild_do_table=test.%
或
replicate_wild_ignore_table=mysql.%
这样就可以避免出现上述问题了
select into outfile 语法
0select email into outfile “test.txt” from email;
select substring(boss,0,2),addr from guest;
LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE “/opt/abc.txt” INTO TABLE table_name FIELDS TERMINATED BY ‘,’ (column1, column2,colum3);
mysql> SELECT * FROM table1 INTO OUTFILE ‘data.txt’
FIELDS TERMINATED BY ‘,’
FROM …
为了将由逗号分隔的文件读回来,正确的语句将是:
mysql> LOAD DATA INFILE ‘data.txt’ INTO TABLE table2
FIELDS TERMINATED BY ‘,’;
相反,如果你试图用下面显示的语句读取文件,它不会工作,因为它命令LOAD DATA INFILE在字段之间寻找定位符:
mysql> LOAD DATA INFILE ‘data.txt’ INTO TABLE table2
FIELDS TERMINATED BY ‘\t’;
可能的结果是每个输入行将被解释为单个的字段。
LOAD DATA INFILE能被用来读取从外部来源获得的文件。例如,以dBASE格式的文件将有由逗号分隔并用双引号包围的字段。如果文件中的行由换行符终止,下面显示的命令说明你将用来装载文件的字段和行处理选项:
mysql> LOAD DATA INFILE ‘data.txt’ INTO TABLE tbl_name
FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘”‘
LINES TERMINATED BY ‘\n’;
任何字段或行处理选项可以指定一个空字符串(”)。如果不是空,FIELDS [OPTIONALLY] ENCLOSED BY和 FIELDS ESCAPED BY值必须是一个单个字符。FIELDS TERMINATED BY和LINES TERMINATED BY值可以是超过一个字符。例如,写入由回车换行符对(CR+LF)终止的行,或读取包含这样行的一个文件,指定一个LINES TERMINATED BY ‘\r \n’子句。
FIELDS [OPTIONALLY] ENCLOSED BY控制字段的包围字符。对于输出 (SELECT … INTO OUTFILE),如果你省略OPTIONALLY,所有的字段由ENCLOSED BY字符包围。对于这样的输出的一个例子(使用一个逗号作为字段分隔符)显示在下面:
“1″,”a string”,”100.20″
“2″,”a string containing a , comma”,”102.20″
“3″,”a string containing a \” quote”,”102.20″
“4″,”a string containing a \”, quote and comma”,”102.20″
=================
insert into tabl(id,email) select id, email from guest;
用mysqlbinlog查看row格式的事件 zt
0MySQL 5.1开始,binlog支持row-based的格式,默认情况下只能看到一些经过base-64编码的信息,如
DELIMITER /*!*/;
# at 7493962
#090827 5:25:03 server id 1 end_log_pos 0 Start: binlog v 4, server v 5.1.26-rc-community-log created 090827 5:25:03
BINLOG ‘
L6iVSg8BAAAAZgAAAAAAAAAAAAQANS4xLjI2LXJjLWNvbW11bml0eS1sb2cAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
‘/*!*/;
# at 7493962
# at 7494009
#090827 13:20:40 server id 1 end_log_pos 7494009 Table_map: `test`.`test1` mapped to number 96991
#090827 13:20:40 server id 1 end_log_pos 7494045 Write_rows: table id 96991 flags: STMT_END_FBINLOG ‘
qBeWShMBAAAALwAAAHlZcgAAAN96AQAAAAAABHRlc3QABXRlc3QxAAIDDwI8AAM=
qBeWShcBAAAAJAAAAJ1ZcgAQAN96AQAAAAEAAv/8AwAAAAEz
‘/*!*/;
# at 7494045
#090827 13:20:40 server id 1 end_log_pos 7494072 Xid = 2525562
COMMIT/*!*/;
DELIMITER ;
# End of log file
这里只能看到`test`.`test1`表做了改动,但具体改了什么,就不知道了,那么怎样才能看到到底改了什么呢?从MySQL 5.1.28开始,mysqlbinlog多了个参数–verbose(或-v),将改动生成带注释的语句,如果使用两次这个参数(如-v -v),会生成字段的类型、长度、是否为null等属性信息。如下:
mysqlbinlog -v -v mysql-bin.001912
DELIMITER /*!*/;
# at 7493962
#090827 5:25:03 server id 1 end_log_pos 0 Start: binlog v 4, server v 5.1.26-rc-community-log created 090827 5:25:03
BINLOG ‘
L6iVSg8BAAAAZgAAAAAAAAAAAAQANS4xLjI2LXJjLWNvbW11bml0eS1sb2cAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
‘/*!*/;
# at 7493962
# at 7494009
#090827 13:20:40 server id 1 end_log_pos 7494009 Table_map: `test`.`test1` mapped to number 96991
#090827 13:20:40 server id 1 end_log_pos 7494045 Write_rows: table id 96991 flags: STMT_END_FBINLOG ‘
qBeWShMBAAAALwAAAHlZcgAAAN96AQAAAAAABHRlc3QABXRlc3QxAAIDDwI8AAM=
qBeWShcBAAAAJAAAAJ1ZcgAQAN96AQAAAAEAAv/8AwAAAAEz
‘/*!*/;
### INSERT INTO test.test1
### SET
### @1=3 /* INT meta=0 nullable=1 is_null=0 */
### @2=’3′ /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
# at 7494045
#090827 13:20:40 server id 1 end_log_pos 7494072 Xid = 2525562
COMMIT/*!*/;
DELIMITER ;
# End of log file
这时能看懂了吧?但还有个问题,BINLOG开头的那些信息还是会显示出来,很难看,能不能去掉呢?答案是肯定的,加–base64-output=DECODE-ROWS参数。如下
mysqlbinlog -v -v –base64-output=DECODE-ROWS mysql-bin.001912
DELIMITER /*!*/;
# at 7493962
#090827 5:25:03 server id 1 end_log_pos 0 Start: binlog v 4, server v 5.1.26-rc-community-log created 090827 5:25:03
# at 7493962
# at 7494009
#090827 13:20:40 server id 1 end_log_pos 7494009 Table_map: `test`.`test1` mapped to number 96991
#090827 13:20:40 server id 1 end_log_pos 7494045 Write_rows: table id 96991 flags: STMT_END_F
### INSERT INTO test.test1
### SET
### @1=3 /* INT meta=0 nullable=1 is_null=0 */
### @2=’3′ /* VARSTRING(60) meta=60 nullable=1 is_null=0 */
# at 7494045
#090827 13:20:40 server id 1 end_log_pos 7494072 Xid = 2525562
COMMIT/*!*/;
DELIMITER ;
# End of log file
这样看起来清晰多了吧?
MYSQL数值类型INT,SMALLINT,BIGINT,MEDIUMINT,FLOAT的相关说明,存储大小等! zt
0MySQL支持所有标准SQL数值数据类型。这些类型包括严格数值数据类型(INTEGER、SMALLINT、DECIMAL和NUMERIC),以及近似数值数据类型(FLOAT、REAL和DOUBLE PRECISION)。关键字INT是INTEGER的同义词,关键字DEC是DECIMAL的同义词。
BIT数据类型保存位字段值,并且支持MyISAM、MEMORY、InnoDB和BDB表。
作为SQL标准的扩展,MySQL也支持整数类型TINYINT、MEDIUMINT和BIGINT。下面的表显示了需要的每个整数类型的存储和范围。
| 类型 | 字节 | 最小值 | 最大值 |
| (带符号的/无符号的) | (带符号的/无符号的) | ||
| TINYINT | 1 | -128 | 127 |
| 0 | 255 | ||
| SMALLINT | 2 | -32768 | 32767 |
| 0 | 65535 | ||
| MEDIUMINT | 3 | -8388608 | 8388607 |
| 0 | 16777215 | ||
| INT | 4 | -2147483648 | 2147483647 |
| 0 | 4294967295 | ||
| BIGINT | 8 | -9223372036854775808 | 9223372036854775807 |
| 0 | 18446744073709551615 |
MySQL还支持选择在该类型关键字后面的括号内指定整数值的显示宽度(例如,INT(4))。该可选显示宽度规定用于显示宽度小于指定的列宽度的值时从左侧填满宽度。
显示宽度并不限制可以在列内保存的值的范围,也不限制超过列的指定宽度的值的显示。
当结合可选扩展属性ZEROFILL使用时, 默认补充的空格用零代替。例如,对于声明为INT(5) ZEROFILL的列,值4检索为00004。请注意如果在整数列保存超过显示宽度的一个值,当MySQL为复杂联接生成临时表时会遇到问题,因为在这些情况下MySQL相信数据适合原列宽度。
所有整数类型可以有一个可选(非标准)属性UNSIGNED。当你想要在列内只允许非负数和该列需要较大的上限数值范围时可以使用无符号值。
浮点和定点类型也可以为UNSIGNED。同数类型,该属性防止负值保存到列中。然而,与整数类型不同的是,列值的上范围保持不变。
如果为一个数值列指定ZEROFILL,MySQL自动为该列添加UNSIGNED属性。
对于浮点列类型,在MySQL中单精度值使用4个字节,双精度值使用8个字节。
FLOAT类型用于表示近似数值数据类型。SQL标准允许在关键字FLOAT后面的括号内选择用位指定精度(但不能为指数范围)。MySQL还支持可选的只用于确定存储大小的精度规定。0到23的精度对应FLOAT列的4字节单精度。24到53的精度对应DOUBLE列的8字节双精度。
MySQL允许使用非标准语法:FLOAT(M,D)或REAL(M,D)或DOUBLE PRECISION(M,D)。这里,“(M,D)”表示该值一共显示M位整数,其中D位位于小数点后面。例如,定义为FLOAT(7,4)的一个列可以显示为-999.9999。MySQL保存值时进行四舍五入,因此如果在FLOAT(7,4)列内插入999.00009,近似结果是999.0001。
MySQL将DOUBLE视为DOUBLE PRECISION(非标准扩展)的同义词。MySQL还将REAL视为DOUBLE PRECISION(非标准扩展)的同义词,除非SQL服务器模式包括REAL_AS_FLOAT选项。
为了保证最大可能的可移植性,需要使用近似数值数据值存储的代码应使用FLOAT或DOUBLE PRECISION,不规定精度或位数。
DECIMAL和NUMERIC类型在MySQL中视为相同的类型。它们用于保存必须为确切精度的值,例如货币数据。当声明该类型的列时,可以(并且通常要)指定精度和标度;例如:
salary DECIMAL(5,2)
在该例子中,5是精度,2是标度。精度表示保存值的主要位数,标度表示小数点后面可以保存的位数。
在MySQL 5.1中以二进制格式保存DECIMAL和NUMERIC值。
标准SQL要求salary列能够用5位整数位和两位小数保存任何值。因此,在这种情况下可以保存在salary列的值的范围是从-999.99到999.99。
在标准SQL中,语法DECIMAL(M)等价于DECIMAL(M,0)。同样,语法DECIMAL等价于DECIMAL(M,0),可以通过计算确定M的值。在MySQL 5.1中支持DECIMAL和NUMERIC数据类型的变量形式。M默认值是10。
DECIMAL或NUMERIC的最大位数是65,但具体的DECIMAL或NUMERIC列的实际范围受具体列的精度或标度约束。如果此类列分配的值小数点后面的位数超过指定的标度允许的范围,值被转换为该标度。(具体操作与操作系统有关,但一般结果均被截取到允许的位数)。
BIT数据类型可用来保存位字段值。BIT(M)类型允许存储M位值。M范围为1到64。
要指定位值,可以使用b’value‘符。value是一个用0和1编写的二进制值。例如,b’111′和b’100000000′分别表示7和128。参见9.1.5节,“位字段值”。
如果为BIT(M)列分配的值的长度小于M位,在值的左边用0填充。例如,为BIT(6)列分配一个值b’101′,其效果与分配b’000101′相同。
当要在一个数值列内保存一个超出该列允许范围的值时,MySQL的操作取决于此时有效的SQL模式。如果模式未设置,MySQL将值裁剪到范围的相应端点,并保存裁减好的值。但是,如果模式设置为traditional(“严格模式”),超出范围的值将被拒绝并提示错误,并且根据SQL标准插入会失败。参见5.3.2节,“SQL服务器模式”。
如果INT列是UNSIGNED,列范围的大小相同,但其端点会变为到0和4294967295。如果你试图保存-9999999999和9999999999,以非严格模式保存到列中的值是0和4294967296。
如果在浮点或定点列中分配的值超过指定(或默认)精度和标度规定的范围,MySQL以非严格模式保存表示范围相应端点的值。
当MySQL没有工作在严格模式时,对于ALTER TABLE、LOAD DATA INFILE、UPDATE和多行INSERT语句,由于裁剪发生的转换将报告为警告。当MySQL工作在严格模式时,这些语句将失败,并且部分或全部值不会插入或更改,取决于是否表为事务表和其它因素。详情参见5.3.2节,“SQL服务器模式”。
MySQL 执行load data infile时同步原理及注意事项
0It appears that the file you load with LOAD DATA INFILE on the master are automatically transferred via the replication log from the master to the slave. The slave loads these files when it gets to the LOAD DATA INFILE in the statement-based replication queue.
I’m inferring this from a couple of statements in the docs:
16.1: Backing Up Replication Slaves
If your MySQL server is a slave replication server, then regardless of the backup method you choose, you should also back up the master.info and relay-log.info files when you back up your slave’s data. These files are always needed to resume replication after you restore the slave’s data. If your slave is subject to replicating LOAD DATA INFILE commands, you should also back up any SQL_LOAD-* files that may exist in the directory specified by the –slave-load-tmpdir option.
16.1.2.3: Replication Slave Options and Variables
When the slave SQL thread replicates a LOAD DATA INFILE statement, it extracts the file to be loaded from the relay log into temporary files, and then loads these into the table. If the file loaded on the master is huge, the temporary files on the slave are huge, too. Therefore, it might be advisable to use this option to tell the slave to put temporary files in a directory located in some filesystem that has a lot of available space. In that case, the relay logs are huge as well, so you might also want to use the –relay-log option to place the relay logs in that filesystem.