如何实现MySQL远程访问?

  以下的文章主要向大家介绍的是实现MySQL程访问的实际操作流程,以及在实现MySQL远程访问的过程中哪些的相关事项是十分重要的,以下就是文章的具体内容讲述,望你浏览之后会对其有更深的了解。

  MySQL远程访问 :

  1、改表法。可能是你的帐号不允许从远程登陆,只能在localhost。这个时候只要在localhost的那台电脑,登入mysql后,更改 "mysql" 数据库里的 "user" 表里的 "host" 项,从"localhost"改称"%"

  mysql -u root -pvmwaremysql>use mysql;

  mysql>update user set host = '%' where user = 'root';

  mysql>select host, user from user;

  2、授权法。例如,你想myuser使用mypassword从任何主机连接到mysql服务器的话。

  GRANT ALL PRIVILEGES ON *.* TO 'myuser'@'%'IDENTIFIED BY 'mypassword' WI

  TH GRANT OPTION;

  在MySQL远程访问中如果你想允许用户myuser从ip为192.168.1.6的主机连接到mysql服务器,并使用mypassword作为密码

  GRANT ALL PRIVILEGES ON *.* TO 'myuser'@'192.168.1.3'IDENTIFIED BY

  'mypassword' WITH GRANT OPTION;

  我用的第一个方法,刚开始发现不行,在网上查了一下,少执行一个语句 mysql>FLUSH RIVILEGES

  使修改生效,就可以了

  另外一种方法:

  在安装mysql的机器上运行:

  1、d:\mysql\bin\>mysql -h localhost -u root

  这样应该可以进入MySQL服务器

  2、mysql>GRANT ALL PRIVILEGES ON *.* TO 'root'@'%'WITH GRANT OPTION

  赋予任何主机访问数据的权限

  3、mysql>FLUSH PRIVILEGES

  修改生效

  4、mysql>EXIT

  退出MySQL服务器

  这样就可以在其它任何的主机上以root身份登录啦。

MySQL日期函数From_unixtime及UNIX_TIMESTAMP及DATE_FORMAT

后者只能格式化标准日期格式,时间戳的不行
 

from_unixtime()是MySQL里的时间函数
date为需要处理的参数(该参数是Unix 时间戳),可以是字段名,也可以直接是Unix 时间戳字符串
后面的 '%Y%m%d' 主要是将返回值格式化
例如:
mysql>SELECT FROM_UNIXTIME( 1249488000, '%Y%m%d' )  
->20071120
mysql>SELECT FROM_UNIXTIME( 1249488000, '%Y年%m月%d' )
->2007年11月20
UNIX_TIMESTAMP() 是与之相对正好相反的时间函数

UNIX_TIMESTAMP(), UNIX_TIMESTAMP(date)

   若无参数调用,则返回一个 Unix timestamp ('1970-01-01 00:00:00' GMT 之后的秒数) 作为无符号整数。若用date 来调用 UNIX_TIMESTAMP(),它会将参数值以'1970-01-01 00:00:00' GMT后的秒数的形式返回。date 可以是一个 DATE 字符串、一个 DATETIME字符串、一个 TIMESTAMP或一个当地时间的YYMMDD 或YYYMMDD格式的数字。

例如:

mysql> SELECT UNIX_TIMESTAMP() ; (执行使得时间:2009-08-06 10:10:40)
->1249524739
mysql> SELECT UNIX_TIMESTAMP('2009-08-06') ;
->1249488000

SELECT *
FROM student
WHERE regTime > UNIX_TIMESTAMP( curdate( ) ) //
今天所有学生注册记录。

MySQL将null转代为0

1、如果为空返回0

select ifnull(null,0)
 

2、如果为空返回0,否则返回1
select if(isnull(col),0,1) as col.
MYSQL 中的IFNULL函数
IFNULL(expr1,expr2)
如果expr1不是NULL,IFNULL()返回expr1,否则它返回expr2。IFNULL()返回一个数字或字符串值,取决于它被使用的上下文环境。
mysql> select IFNULL(1,0);
-> 1
mysql> select IFNULL(0,10);
-> 0
mysql> select IFNULL(1/0,10);
-> 10
mysql> select IFNULL(1/0,'yes');
-> 'yes'

IF(expr1,expr2,expr3)
如果expr1是TRUE(expr1<>0且expr1<>NULL),那么IF()返回expr2,否则它返回expr3。IF()返回一个数字或字符串值,取决于它被使用的上下文。
mysql> select IF(1>2,2,3);
-> 3
mysql> select IF(1<2,'yes','no');
-> 'yes'
mysql> select IF(strcmp('test','test1'),'yes','no');
-> 'no'
expr1作为整数值被计算,它意味着如果你正在测试浮点或字符串值,你应该使用一个比较操作来做。
mysql> select IF(0.1,1,0);
-> 0
mysql> select IF(0.1<>0,1,0);
-> 1
在上面的第一种情况中,IF(0.1)返回0,因为0.1被变换到整数值, 导致测试IF(0)。这可能不是你期望的。在第二种情况中,比较测试原来的浮点值看它是否是非零,比较的结果被用作一个整数。
CASE value WHEN [compare-value] THEN result [WHEN [compare-value] THEN result ...] [ELSE result] END
 
CASE WHEN [condition] THEN result [WHEN [condition] THEN result ...] [ELSE result] END
第一个版本返回result,其中value=compare-value。第二个版本中如果第一个条件为真,返回result。如果没有匹配的result值,那么结果在ELSE后的result被返回。如果没有ELSE部分,那么NULL被返回。
mysql> SELECT CASE 1 WHEN 1 THEN "one" WHEN 2 THEN "two" ELSE "more" END;
-> "one"
mysql> SELECT CASE WHEN 1>0 THEN "true" ELSE "false" END;
-> "true"
mysql> SELECT CASE BINARY "B" when "a" then 1 when "b" then 2 END;

-> NULL
 

浅析MySQL数据碎片的产生

MySQL列表,包括MyISAM和InnoDB这两种最常见的类型,而根据经验来说,其碎片的产生及消除都是随机的。碎片会在你的表格中留下明显的空白,而这会给列表扫描工作带来相当大的困扰。对你的列表进行优化,这样会使列表的全面及分区扫描工作进行得更有效率。

碎片——实例

MySQL具有相当多不同种类的存储引擎来实现列表中的数据存储功能。 每当MySQL从你的列表中删除了一行内容,该段空间就会被留空。而在一段时间内的大量删除操作,会使这种留空的空间变得比存储列表内容所使用的空间更 大。当MySQL对数据进行扫描时,它扫描的对象实际是列表的容量需求上限,也就是数据被写入的区域中处于峰值位置的部分。如果进行新的插入操 作,MySQL将尝试利用这些留空的区域,但仍然无法将其彻底占用。

这种额外的破碎的存储空间在读取效率方面比正常占用的空间要低得多。让我们看一个实例。

我们将创建一个数据库(有时也称其为大纲)及一个测试用的列表:

现在让我们在列表中加入如下几行:

现在我们进行碎片查看:

现在我们删除一行,并再次检测:

需要注意的是,“data_free”一栏显示出了我们删除第二行后所产生的留空空间。想象一下如果你有两万行指令的话,结果是什么样的。以此推 算,它们将耗费四十万字节的存储空间。现在如果你将两万条命令行删到只剩一行,列表中有用的内容将只占二十字节,但MySQL在读取中会仍然将其视同于一 个容量为四十万字节的列表进行处理,并且除二十字节以外,其它空间都被白白浪费了。

清理碎片

幸运的是一旦你锁定了这一问题,MySQL提供了一种简便的修正方法。这就是所谓的优化列表,具体内容如下:

性能考量

“优化列表”功能在进行中会对整个列表进行锁定。对于小型列表,这一功能的效果非常好,因为整个列表的读取和修改速度都会很快。但对于那些体积巨大的列表来说,这一过程将消耗很长时间,并且其间会中断或减少可用的应用程序数量。怎么办?

再一次,MySQL幸运地提供了一项堪称伟大的功能,名为“主-主复制”。 在这种配置之下,你的后台数据库实际上成为两个单独的数据库,一个主动可调用的,一个被动可调整的。这两个数据库在各方面来说都是完全相同的。要实现各种 在线操作——包括“优化列表”操作——只需在你的被动数据库中即可进行。这将不会对你的应用程序造成丝毫影响。一旦优化操作完成,主、被动数据库将互相转 换,以便应用程序直接指向二号数据库,对还未进行优化的主动数据库部分自动开始优化工作。

这时,两套数据库的角色已经互换,而应用程序也将顺利指向二号数据库,执行与在一号数据库上相同的列表优化。而现在主动已经转换为被动,因此不会中断主要任务处理。

其它命令

显示你数据库中存在碎片的全部列表:

如果你更改了某个列表的存储引擎,你也应该对这一列表进行碎片清理。这是因为MySQL的工作原理导致其必须读取整个列表,然后利用新的存储引擎将内容写回磁盘,而在此过程中碎片所在的位置及影响到的数据都对执行效率造成了严重的不良影响。

上述情况如下所示:

结论

如果你发现一些列表中包含了大量的数据留空现象,那么对其进行优化是绝对值得的,因为这一过程会大大提升列表的读取性能及应用表现。

mysql where id in 排序 按in的顺序排序

select id fromtablewhere id in(2,1,3,5)order bysubstring_index('2,1,3,5',id,1);
substring_index(str,delim,count) 字符串截取函数
str 要截取的字符串 delim 截取的分割符 count 截取的数量
返回从字符串str的第count个出现的分隔符delim之后的子串。如果count是正数,返回最后的分隔符到左边(从左边数) 的所有字符。如果count是负数,返回最后的分隔符到右边的所有字符(从右边数)。
那 order by substring_index(‘2,1,3,5′,id,1) 这个啥意思呢
这个是在字符串’2,1,3,5′里查找id,如果找不到,就返回整个字符串select id fromtablewhere id in(2,1,3,5)order by find_in_set(id,'2,1,3,5')
find_in_set(str,strlist)
字符串函数
如果字符串str在由N子串组成的表strlist之中,返回一个1到N的值。如果str不是在strlist里面或如果strlist是空字符串,返回0。

SELECT FIND_IN_SET('b','a,b,c,d');
->2
所以 find_in_set返回的是一个1到N的值,在order by的话,就是按顺序排了。

此句测试中id为主键,type一直为all,不知是有优化方法?

 

另一种,没有试过(收藏一下)

SQL: select * from table where id IN (3,6,9,1,2,5,8,7);
这样的情况取出来后,其实,id还是按1,2,3,4,5,6,7,8,9,排序的,但如果我们真要按IN里面的顺序排序怎么办?SQL能不能完成?是否需要取回来后再foreach一下?
其实可以这样
sql: select * from table where id IN (3,6,9,1,2,5,8,7) order by field(id,3,6,9,1,2,5,8,7);
出来的顺序就是指定的顺序了

 

 

项目 中用到

$order = "order by substring_index('$ids',g.goods_id,1)";//按in 排序用

MySQL不能启动 Can't start server : Bind on unix socket: Permission denied

mysql突然不能启动,查看最后的启动日志如下:

080825 09:38:04 mysqld started
080825 9:38:04 [ERROR] Can't start server : Bind on unix socket: Permission denied
080825 9:38:04 [ERROR] Do you already have another mysqld server running on socket: /var/mysql.sock ?
080825 9:38:04 [ERROR] Aborting

080825 9:38:04 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

080825 09:38:04 mysqld ended
 

my.cnf配置如下:
[mysqld]
datadir=/usr/local/mysql/data
socket=/var/mysql.sock

[mysql]
socket=/tmp/mysql.sock
[mysql.server]
user=mysql
basedir=/usr/local/mysql

[safe_mysqld]
err-log=/usr/local/mysql/mysqld.log

pid-file=/usr/local/mysql/mysqld.pid
 

根据日志文件显示,首先检查运行权限,再看一下/var/mysql.sock,发现/var/mysql.sock目录下并没有该文件,是否是没有权限 写/var目录?OK,那就用root用户运行一下safe_mysqld,启动正常。使用mysql连接数据库,提示错误,连接不到数据库服务器, /tmp目录下没有mysql.sock这个文件,到这里,基本清楚了Mysql客户端和服务器端在本机的通信方式了,通过一个名为mysql.sock 文件来进行初始化通信的,因此该文件所存放的目录必须双方都有权限可以访问到,而且服务器在启动时需要写该文件,如果my.cnf中这两项配置不正确,就 会出现Permission denied等类似错误。将配置文件修改如下,就没有问题了。

 

[mysqld]
datadir=/usr/local/mysql/data
socket=/tmp/mysql.sock

[mysql]
socket=/tmp/mysql.sock
[mysql.server]
user=mysql
basedir=/usr/local/mysql

[safe_mysqld]
err-log=/usr/local/mysql/mysqld.log
pid-file=/usr/local/mysql/mysqld.pid

Fedora 15 安装mysql数据库

用fedora 15自带的yum安装方式:
只要在终端里输入:yum -y install mysql-server ,系统自动下载和安装Mysql的,
chkconfig --add mysqld 在服务清单中添加mysql服务
service mysqld start 服务启动
mysqladmin -u root password 'newpassword' 更改密码
mysql -u root -p

 

Enter password:输入刚才更改的密码

 
 

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5
Server version: 5.5.13 MySQL Community Server (GPL)

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

以上是登录成功信息

 
 

mysql> show databases; 查询数据库

+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
+--------------------+
4 rows in set (0.00 sec)

mysql> use test; 使用test数据库

mysql> show tables; 查询test数据库所有表
Empty set (0.00 sec)

 

要使数据库支持中文,还要修改一个文件:

vi /etc/my.cnf

增加一项:character_set_server=utf8

 

关于MySQL的Float和Decimal精确度比较

float,double容易产生误差,对精确度要求比较高时,建议使用decimal来存,decimal在mysql内存是以字符串存储的,用于定义货币要求精确度高的数据。在数据迁移中,float(M,D)是非标准定义,最好不要这样使用。M为精度,D为标度。

mysql> create table t1(c1 float(10,2), c3 decimal(10,2)); 
Query OK, 0 rows affected (0.02 sec)

mysql> insert into t1 values(1234567.23, 1234567.23);
Query OK, 1 row affected (0.01 sec)

mysql> select * from t1;
+------------+------------+
| c1         | c3         |
+------------+------------+
| 1234567.25 | 1234567.23 | 
+------------+------------+
1 row in set (0.02 sec)

mysql> insert into t1 values(9876543.21, 9876543.12);                       
Query OK, 1 row affected (0.00 sec)

mysql> 
mysql> select * from t1;                             
+------------+------------+
| c1         | c3         |
+------------+------------+
| 1234567.25 | 1234567.23 | 
| 9876543.00 | 9876543.12 | 
+------------+------------+
2 rows in set (0.00 sec)

不定义fload, double的精度和标度时,存储按给出的数值存储,这于OS和当前的硬件有关。

decimal默认为decimal(10,0)

因为误差问题,在程序中,少用浮点数做=比较,可以做range比较。如果数值比较,最好使用decimal类型。

精度中,符号不算在内:

mysql> insert into t1 values(-98765430.21, -98765430.12);
Query OK, 1 row affected (0.01 sec)

mysql> select * from t1;                                                              
+--------------+--------------+
| c1           | c3           |
+--------------+--------------+
|   1234567.25 |   1234567.23 | 
|   9876543.00 |   9876543.12 | 
| -98765432.00 | -98765430.12 | 
+--------------+--------------+
3 rows in set (0.00 sec)

float占4个字节,double占8个字节,decimail(M,D)占M+2个字节。

Out of resources when opening file './xxx.MYD' (Errcode: 24) 解决

前两天数据库出现了这个错误,在网上查找到了解决方法。在解决过程中的一些问 题记录下来。首先出现Out of resources when opening file './xxx.MYD' (Errcode: 24)错误是因为打开的文件数超过了my.cnf的--open-files-limit。 open-files-limit选项无法在mysql命令行直接修改,必须在my.cnf中设定,最大值是65536。

 

重新启动以后,发现

mysql> show variables like 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 1024  |
+------------------+-------+
1 row in set (0.00 sec)

 

并没有改变。赶快查看服务器的打开文件数设定的值(用ulimit -n查看),结果发现果然是1024。在修改服务器设置后,也改成了65536,重启服务还是没有改变。需要重新登录服务器再重启数据库服务就OK了。原来这个值会取数据库和服务器设定的最小值。
 
 

mysql> show variables like 'open%';

+------------------+-------+

| Variable_name    | Value |

+------------------+-------+

| open_files_limit | 65536 |

+------------------+-------+


1 row in set (0.00 sec)
 
 
 
 
 

使用ulimit -a 可以查看当前系统的所有限制值,使用ulimit -n 可以查看当前的最大打开文件数。

 

新装的linux默认只有1024,当作负载较大的服务器时,很容易遇到error: too many open files。因此,需要将其改大。

 

使用 ulimit -n 65535 可即时修改,但重启后就无效了。(注ulimit -SHn 65535 等效 ulimit -n 65535,-S指soft,-H指hard)

 

有如下三种修改方式:

 

1.在/etc/rc.local 中增加一行 ulimit -SHn 65535
2.在/etc/profile 中增加一行 ulimit -SHn 65535
3.在/etc/security/limits.conf最后增加如下两行记录
* soft nofile 65535
* hard nofile 65535

 

具体使用哪种,试试哪种有效吧,我在 CentOS中使用第1种方式无效果,使用第3种方式有效果,而在Debian中使用第2种有效果

 

MySQL Replication的实现原理

要想用好一个系统,理解其实现原理是非常重要的事情,只有理解了其实现原理,我们才能够扬长避短,合理的利用,才能够搭建出最适合我们自己应用环境 的系统,才能够在系统实施之后更好的维护他。MySQL Replication 可以说是在目前 MySQL 数据库的实际应用场景中最为常见的Scale Out 手段了,这里就针对其实现原理做一个简单的分析。
 

  一、 Replication 线程

   Mysql的 Replication 是一个异步的复制过程,从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成,其中两个线程(Sql线程和IO线程)在 Slave 端,另外一个线程(IO线程)在 Master 端。

 

  要实现 MySQL 的 Replication ,首先必须打开 Master 端的Binary Log(mysql-bin.xxxxxx)功能,否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全 顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “—log-bin” 参数选项,或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。

 

  MySQL 复制的基本过程如下:

 

  1. Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;

 

   2. Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息,返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 Binary Log 中的位置;

 

  3. Slave 的 IO 线程接收到信息后,将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中,以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”

 

   4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后,会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句,并在自身执行这些 Query。这样,实际上就是在 Master 端和 Slave 端执行了同样的 Query,所以两端的数据是完全一样的。

 
 

  实际上,在老版本中,MySQL 的复制实现在 Slave 端并不是由 SQL 线程和 IO 线程这两个线程共同协作而完成的,而是由单独的一个线程来完成所有的工作。但是 MySQL 的工程师们很快发现,这样做存在很大的风险和性能问题,主要如下:

 

   首先,如果通过一个单一的线程来独立实现这个工作的话,就使复制 Master 端的,Binary Log日志,以及解析这些日志,然后再在自身执行的这个过程成为一个串行的过程,性能自然会受到较大的限制,这种架构下的 Replication 的延迟自然就比较长了。

 

  其次,Slave 端的这个复制线程从 Master 端获取 Binary Log 过来之后,需要接着解析这些内容,还原成 Master 端所执行的原始 Query,然后在自身执行。在这个过程中,Master端很可能又已经产生了大量的变化并生成了大量的 Binary Log 信息。如果在这个阶段 Master 端的存储系统出现了无法修复的故障,那么在这个阶段所产生的所有变更都将永远的丢失,无法再找回来。这种潜在风险在Slave 端压力比较大的时候尤其突出,因为如果 Slave 压力比较大,解析日志以及应用这些日志所花费的时间自然就会更长一些,可能丢失的数据也就会更多。

 

   所以,在后期的改造中,新版本的 MySQL 为了尽量减小这个风险,并提高复制的性能,将 Slave 端的复制改为两个线程来完成,也就是前面所提到的 SQL 线程和 IO 线程。最早提出这个改进方案的是Yahoo!的一位工程师“Jeremy Zawodny”。通过这样的改造,这样既在很大程度上解决了性能问题,缩短了异步的延时时间,同时也减少了潜在的数据丢失量。

 

  当然,即使是换成了现在这样两个线程来协作处理之后,同样也还是存在 Slave 数据延时以及数据丢失的可能性的,毕竟这个复制是异步的。只要数据的更改不是在一个事务中,这些问题都是存在的。

 

  如果要完全避免这些问题,就只能用 MySQL 的 Cluster 来解决了。不过 MySQL的 Cluster 知道笔者写这部分内容的时候,仍然还是一个内存数 据库的解决方案,也就是需要将所有数据包括索引全部都 Load 到内存中,这样就对内存的要求就非常大的大,对于一般的大众化应用来说可实施性并不是太大。当然,在之前与 MySQL 的 CTO David 交流的时候得知,MySQL 现在正在不断改进其 Cluster 的实现,其中非常大的一个改动就是允许数据不用全部 Load 到内存中,而仅仅只是索引全部 Load 到内存中,我想信在完成该项改造之后的 MySQL Cluster 将会更加受人欢迎,可实施性也会更大。

 
 
 
 

二、Replication 实现级别

  由于MySQL Replication 是基于 Binary Log 实现的,所以Replication 的实现级别实际上是由Binary Log 的存储格式所决定。Binary Log 中记录 Eent 的方式可以是基于一条语句(Statement Level),也可以是基于一条记录(Row level),这可以在 MySQL 的配置参数(—binlog-format)中设定这个格式。

 

  1. Row Level:Binary Log 中会记录成每一行数据被修改的形式,然后在 Slave 端再对相同的数据进行修改。

   优点:在 Row Level 模式下,Binary Log 中可以不记录执行的sql语句的上下文相关的信息,仅仅只需要记录那一条记录被修改了,修改成什么样了。所以 Row Level 的日志内容会非常清楚的记录下每一行数据修改的细节,非常容易理解。而且不会出现某些特定情况下的存储过程,或function,以及trigger的调 用和触发无法被正确复制的问题。

  缺点:Row Level下,所有的执行的语句当记录到 Binary Log 中的时候,都将以每行记录的修改来记录,这样可能会产生大量的日志内容,比如有这样一条update语句:UPDATE group_message SET group_id = 1 where group_id = 2,执行之后,日志中记录的不是这条update语句所对应的事件(MySQL以事件的形式来记录 Binary Log 日志),而是这条语句所更新的每一条记录的变化情况,这样就记录成很多条记录被更新的很多个事件。自然,Binary Log 日志的量就会很大。尤其是当执行ALTER TABLE 之类的语句的时候,产生的日志量是惊人的。因为MySQL对于 ALTER TABLE 之类的 DDL 变更语句的处理方式是重建整个表的所有数据,也就是说表中的每一条记录都需要变动,那么该表的每一条记录都会被记录到日志中。

 

  2. Statement Level:每一条会修改数据的 Query 都会记录到 Master的 Binary Log 中。Slave在复制的时候 SQL 线程会解析成和原来 Master 端执行过的相同的 Query 来再次执行。

   优点:Statement Level下的优点首先就是解决了Row Level下的缺点,不需要记录每一行数据的变化,减少 Binary Log 日志量,节约了 IO 成本,提高了性能。因为他只需要记录在Master上所执行的语句的细节,以及执行语句时候的上下文的信息。

  缺 点:由于他是记录的执行语句,所以,为了让这些语句在slave端也能正确执行,那么他还必须记录每条语句在执行的时候的一些相关信息,也就是上下文信 息,以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。另外就是,由于Mysql现在发展比较快,很多的新功能不 断的加入,使mysql得复制遇到了不小的挑战,自然复制的时候涉及到越复杂的内容,bug也就越容易出现。在statement level下,目前已经发现的就有不少情况会造成mysql的复制出现问题,主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现,比 如:sleep()函数在有些版本中就不能真确复制,在存储过程中使用了last_insert_id()函数,可能会使slave和master上得到 不一致的id等等。由于row level是基于每一行来记录的变化,所以不会出现类似的问题。

 

  3. Mixed Level: 从 5.1.8 版本开始,MySQL 提供了除Statement Level和Row Level之外的第三种 Mixed Level,实际上就是前两种模式的结合。在Mixed模式下,MySQL会根据执行的每一条具体的 Query 语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种。除了MySQL认为通过STATEMENT方式可能造成复制过程中 Master与Slave之间产生不一致数据(如特殊Procedure和Function的使用,UUID()函数的使用等特殊情况)的时候MySQL 会选择ROW的模式来记录变更之外,都会使用STATEMENT模式来记录变更。当然,这里需要排除的特殊情况并不仅仅只有上面所描述的这几种,具体请参 考 MySQL 官方的详细手册。

  老版本的 MySQL 一直都只有基于 Statement 的复制模式,直到5.1.5版本的 MySQL 才开始支持Row Level的复制。从5.0开始,MySQL 的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现,给 MySQL 的复制又带来了更大的新挑战。另外,看到官方文档说,从5.1.8版本开始,MySQL 开始提供 Mixed Level,新版本中的Statment level还是和以前一样,仅仅记录执行的语句。而新版本的Mysql中队Row Level模式也被做了优化,并不是所有的修改都会以Row Level来记录,像遇到表结构变更的时候就会以statement模式来记录,如果 Query 语句确实就是 UPDATE 或者 DELETE 等修改数据的语句,那么还是会记录所有行的变更。