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.%
这样就可以避免出现上述问题了

MYSQL TIMESTAMP时间戳介绍

0

如果要实现你某列的默认值为当前更新日期与时间的功能,
你可以使用TIMESTAMP列类型

下面就详细说明TIMESTAMP列类型

TIMESTAMP列类型
TIMESTAMP值可以从1970的某时的开始一直到2037年,精度为一秒,其值作为数字显示。
TIMESTAMP值显示尺寸的格式如下表所示:

+—————+—————-+
| 列类型    | 显示格式    |
| TIMESTAMP(14) | YYYYMMDDHHMMSS |
| TIMESTAMP(12) | YYMMDDHHMMSS  |
| TIMESTAMP(10) | YYMMDDHHMM   |
| TIMESTAMP(8) | YYYYMMDD    |
| TIMESTAMP(6) | YYMMDD     |
| TIMESTAMP(4) | YYMM      |
| TIMESTAMP(2) | YY       |
+—————+—————-+
“完整”TIMESTAMP格式是14位,但TIMESTAMP列也可以用更短的显示尺寸创造
最常见的显示尺寸是6、8、12、和14。
你可以在创建表时指定一个任意的显示尺寸,但是定义列长为0或比14大均会被强制定义为列长14。
列长在从1~13范围的奇数值尺寸均被强制为下一个更大的偶数。

列如:
定义字段长度   强制字段长度
TIMESTAMP(0) -> TIMESTAMP(14)
TIMESTAMP(15)-> TIMESTAMP(14)
TIMESTAMP(1) -> TIMESTAMP(2)
TIMESTAMP(5) -> TIMESTAMP(6)

所有的TIMESTAMP列都有同样的存储大小,
使用被指定的时期时间值的完整精度(14位)存储合法的值不考虑显示尺寸。
不合法的日期,将会被强制为0存储

这有几个含意:

1、虽然你建表时定义了列TIMESTAMP(8),但在你进行数据插入与更新时TIMESTAMP列实际上保存了14位的数据(包括年月日时分秒),只不过在你进行查询时MySQL返回给你的是8位的年月日数据。如果你使用ALTER TABLE拓宽一个狭窄的TIMESTAMP列,以前被“隐蔽”的信息将被显示。
2、同样,缩小一个TIMESTAMP列不会导致信息失去,除了感觉上值在显示时,较少的信息被显示出。
3、尽管TIMESTAMP值被存储为完整精度,直接操作存储值的唯一函数是UNIX_TIMESTAMP();由于MySQL返回TIMESTAMP列的列值是进过格式化后的检索的值,这意味着你可能不能使用某些函数来操作TIMESTAMP列(例如HOUR()或SECOND()),除非 TIMESTAMP值的相关部分被包含在格式化的值中。例如,一个TIMESTAMP列只有被定义为TIMESTAMP(10)以上时, TIMESTAMP列的HH部分才会被显示,因此在更短的TIMESTAMP值上使用HOUR()会产生一个不可预知的结果。
4、不合法TIMESTAMP值被变换到适当类型的“零”值(00000000000000)。(DATETIME,DATE亦然)

你可以使用下列语句来验证:
CREATE TABLE test (‘id’ INT (3) UNSIGNED AUTO_INCREMENT, ‘date1′ TIMESTAMP (8) PRIMARY KEY(‘id’));
INSERT INTO test SET id = 1;
SELECT * FROM test;
+—-+—————-+
| id | date1     |
+—-+—————-+
| 1 | 20021114    |
+—-+—————-+
ALTER TABLE test CHANGE ‘date1′ ‘date1′ TIMESTAMP(14);
SELECT * FROM test;
+—-+—————-+
| id | date1     |
+—-+—————-+
| 1 | 20021114093723 |
+—-+—————-+

你可以使用TIMESTAMP列类型自动地用当前的日期和时间标记INSERT或UPDATE的操作。
如果你有多个TIMESTAMP列,只有第一个自动更新。

自动更新第一个TIMESTAMP列在下列任何条件下发生:

1、列值没有明确地在一个INSERT或LOAD DATA INFILE语句中指定。
2、列值没有明确地在一个UPDATE语句中指定且另外一些的列改变值。(注意一个UPDATE设置一个列为它已经有的值,这将不引起TIMESTAMP列被更新,因为如果你设置一个列为它当前的值,MySQL为了效率而忽略更改。)
3、你明确地设定TIMESTAMP列为NULL.
4、除第一个以外的TIMESTAMP列也可以设置到当前的日期和时间,只要将列设为NULL,或NOW()。

CREATE TABLE test (
‘id’ INT (3) UNSIGNED AUTO_INCREMENT,
‘date1′ TIMESTAMP (14),
‘date2′ TIMESTAMP (14),
PRIMARY KEY(‘id’)
);

INSERT INTO test (id, date1, date2) VALUES (1, NULL, NULL);
INSERT INTO test SET id= 2;
+—-+—————-+—————-+
| id | date1     | date2     |
+—-+—————-+—————-+
| 1 | 20021114093723 | 20021114093723 |
| 2 | 20021114093724 | 00000000000000 |
+—-+—————-+—————-+

->第一条指令因设date1、date2为NULL,所以date1、date2值均为当前时间
第二条指令因没有设date1、date2列值,第一个TIMESTAMP列date1为更新为当前时间,
而二个TIMESTAMP列date2因日期不合法而变为“00000000000000”

UPDATE test SET id= 3 WHERE id=1;
+—-+—————-+—————-+
| id | date1     | date2     |
+—-+—————-+—————-+
| 3 | 20021114094009 | 20021114093723 |
| 2 | 20021114093724 | 00000000000000 |
+—-+—————-+—————-+
->这条指令没有明确地设定date2的列值,所以第一个TIMESTAMP列date1将被更新为当前时间

UPDATE test SET id= 1,date1=date1,date2=NOW() WHERE id=3;
+—-+—————-+—————-+
| id | date1     | date2     |
+—-+—————-+—————-+
| 1 | 20021114094009 | 20021114094320 |
| 2 | 20021114093724 | 00000000000000 |
+—-+—————-+—————-+
->这条指令因设定date1=date1,所以在更新数据时date1列值并不会发生改变
而因设定date2=NOW(),所以在更新数据时date2列值会被更新为当前时间
此指令等效为 update test SET id= 1,date1=date1,date2=NULL WHERE id=3;

因MySQL返回的 TIMESTAMP 列为数字显示形式,
你可以用DATE_FROMAT()函数来格式化 TIMESTAMP 列

SELECT id,DATE_FORMAT(date1,’%Y-%m-%d %H:%i:%s’) As date1,
DATE_FORMAT(date2,’%Y-%m-%d %H:%i:%s’) As date2 FROM test;
+—-+———————+———————+
| id | date1        | date2        |
+—-+———————+———————+
| 1 | 2002-11-14 09:40:09 | 2002-11-14 09:43:20 |
| 2 | 2002-11-14 09:37:24 | 0000-00-00 00:00:00 |
+—-+———————+———————+

SELECT id,DATE_FORMAT(date1,’%Y-%m-%d’) As date1,
DATE_FORMAT(date2,’%Y-%m-%d’) As date2 FROM test;

+—-+————-+————-+
| id | date1    | date2    |
+—-+————-+————-+
| 1 | 2002-11-14 | 2002-11-14 |
| 2 | 2002-11-14 | 0000-00-00 |
+—-+————-+————-+

在某种程度上,你可以把一种日期类型的值赋给一个不同的日期类型的对象。
然而,而尤其注意的是:值有可能发生一些改变或信息的损失:

1、如果你将一个DATE值赋给一个DATETIME或TIMESTAMP对象,结果值的时间部分被设置为’00:00:00′,因为DATE值中不包含有时间信息。
2、如果你将一个DATETIME或TIMESTAMP值赋给一个DATE对象,结果值的时间部分被删除,因为DATE类型不存储时间信息。
3、尽管DATETIME, DATE和TIMESTAMP值全都可以用同样的格式集来指定,
但所有类型不都有同样的值范围。
例如,TIMESTAMP值不能比1970早,也不能比2037晚,
这意味着,一个日期例如’1968-01-01′,当作为一个DATETIME或DATE值时它是合法的,
但它不是一个正确TIMESTAMP值!并且如果将这样的一个对象赋值给TIMESTAMP列,它将被变换为0。

当指定日期值时,当心某些缺陷:

1、允许作为字符串指定值的宽松格式能被欺骗。例如,,因为“:”分隔符的使用,值’10:11:12′可能看起来像时间值,但是如果在一个日期中使用,上下文将作为年份被解释成’2010-11-12′。值’10:45:15′将被变换到’0000-00-00′,因为’45′不是一个合法的月份。

2、以2位数字指定的年值是模糊的,因为世纪是未知的。MySQL使用下列规则解释2位年值: 在00-69范围的年值被变换到2000-2069。 在范围70-99的年值被变换到1970-1999。

select into outfile 语法

0

select 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

0

MySQL 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_F

BINLOG ‘
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_F

BINLOG ‘
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

0

MySQL支持所有标准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时同步原理及注意事项

0
   Master上执行
      mysql> load data INFILE ‘/tmp/del_proid.txt’ INTO table del_proid;
   在Binlog中记录的SQL是这样的
      load data LOCAL INFILE ‘/tmp/SQL_LOAD_MB-1-0′ INTO table del_proid
   并且在/tmp目录中也确实出现了这个文件,内容和del_proid.txt一模一样
   同步时,Master的Binlog Dump进程会读取SQL_LOAD_MB-1-0文件的数据传,送给Slave的IO进程写入Relaylog,当Slave同步到该语句时,SQL进 程从Relaylog中解出数据,仍以文件名SQL_LOAD_MB-1-0写入slave-load-tmpdir参数打定的目录下,然后执行
   load data LOCAL INFILE ‘/tmp/SQL_LOAD_MB-1-0′ INTO table del_proid
   完成后,删除该文件
   slave-load-tmpdir参数,在默认或未设置的情况下,使用tmpdir参数值文档:

It 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.

Go to Top