一、Can't connect to MySQL server on 'localhost' (10061)
翻译：不能连接到 localhost 上的mysql
分析：这说明“localhost”计算机是存在的，但在这台机器上却没提供MySQL服务。
需要启动这台机器上的MySQL服务,如果机子负载太高没空相应请求也会产生这个错误。
解决:既然没有启动那就去启动这台机子的mysql。如果启动不成功，多数是因为你的my.ini配置的有问题。重新配置其即可。
如果觉得mysql负载异常，可以到mysql/bin 的目录下执行mysqladmin -uroot -p123 processlist来查看mysql当前的进程。
二、Unknown MySQL Server Host 'localhosadst' (11001)
翻译：未知的MySQL服务器 localhosadst
分析：服务器 localhosasdst 不存在。或者根本无法连接
解决：仔细检查自己论坛下面的 ./config.inc. 找到$dbhost重新设置为正确的mysql 服务器地址。
三、Access denied for user: 'roota@localhost' (Using password: YES)
翻译：用户 roota 访问 localhost 被拒绝（没有允许通过）
分析：造成这个错误一般数据库用户名和密码相对mysql服务器不正确
解决：仔细检查自己论坛下面的 ./config.inc.php 找到$dbuser、$dbpw核实后重新设置保存即可。
四、Access denied for user: 'red@localhost' to database 'newbbs'
翻译：用户 red 在localhost 服务器上没有权限操作数据库newbbs
分析：这个提示和问题三是不同的。那个是在连接数据库的时候就被阻止了，而这个错误是在对数据库进行操作时引起的。比如在select
update等等。这个是因为该用户没有操作数据库相应的权力。比如select 这个操作在mysql.user.Select_priv里记录 Y
可以操作N 不可以操作。
解决：如果是自己的独立主机那么更新mysql.user 的相应用户记录，比如这里要更新的用户为red 。或者直接修改 ./config.inc.php 为其配置一个具有对数据库操作权限的用户
或者通过如下的命令来更新授权grant all privileges on dbname.* to 'user'@'localhost' identified by 'password’
提示：更新了mysql库中的记录一定要重启mysql服务器才能使更新生效
FLUSH PRIVILEGES;
五、No Database Selected
翻译：没有数据库被选择上
分析：产生的原因有两种
config.inc.php 里面$dbname设置的不对。致使数据库根本不存在，所以在 $db-&select_db($dbname); 时返回了false
和上面问题四是一样的，数据库用户没有select权限，同样会导致这样的错误。当你发现config.inc.php的设置没有任何问题，但还是提示这个错误，那一定就是这种情况了。
解决：对症下药
打开config.inc.php 找到$dbname核实重新配置并保存
同问题四的解决方法
六、Can't open file: 'xxx_forums.MYI'. (errno: 145)
翻译：不能打开xxx_forums.MYI
问题分析：
这种情况是不能打开 cdb_forums.MYI 造成的，引起这种情况可能的原因有：
1、服务器非正常关机，数据库所在空间已满，或一些其它未知的原因，对数据库表造成了损坏。
2、类 unix 操作系统下直接将数据库文件拷贝移动会因为文件的属组问题而产生这个错误。
解决方法：
1、修复数据表
可以使用下面的两种方式修复数据表：（第一种方法仅适合独立主机用户）
1）使用 myisamchk ，MySQL 自带了专门用户数据表检查和修复的工具 —— myisamchk 。更改当前目录到 MySQL/bin
下面，一般情况下只有在这个下面才能运行 myisamchk 命令。常用的修复命令为：myisamchk -r 数据文件目录/数据表名.MYI；
2）通过 phpMyAdmin 修复， phpMyAdmin 带有修复数据表的功能，进入到某一个表中后，点击“操作”，在下方的“表维护”中点击“修复表”即可。
注意：以上两种修复方式在执行前一定要备份数据库。
2、修改文件的属组（仅适合独立主机用户）
1）复制数据库文件的过程中没有将数据库文件设置为 MySQL 运行的帐号可读写（一般适用于
和 FreeBSD 用户）。
七、Table 'test.xxx_sessions' doesn't exist
翻译：xxxxx表不存在
分析：在执行sql语句时没有找到表，比如：SELECT * FROM xxx_members WHERE uid=’XX’ 这里如果表xxx_members不存在于$dbname库里，那么就会提示这个错误。具体可分为以下三种情况来讨论：
安装插件或者hack时修改了程序文件，而忘记了对数据库作相应的升级。
后台使用了不完全备份，导入数据时没有导入到已经安装了相应版本的论坛的数据库中。
解决： 同样对症下药，不同的原因不同的处理方法。
仔细对照插件作者提供的安装说明，把遗漏的对数据库的操作补上，如果仍然不能解决问题，那么应该怀疑该插件的可用性了。去咨询一下插件作者，或者将其卸载。
不要张冠李戴，多大的脚就穿多大的鞋。总之使得程序文件和数据库配套即可.
八、Unknown column 'column_name' in 'field list'
翻译：未知的字段名 column_name
分析：在执行sql语句是出现了指定表中没有的字段名称，就会出现这个错误。具体导致的原因可分为以下两种
安装插件或者hack时修改了程序文件，而忘记了对数据库作相应的升级。
程序文件和数据库不配套，比如d2.5的数据库配置给d4.1的程序来用肯定会出现这个错误。
解决： 导致的原因和问题八的1和 3是相同的，所以解决方法也一样。
九、You have an error in your SQL syntax
翻译：有一个语法错误在你的sql中
分析：论坛标准的程序是没有sql语法错误的。所以造成这个错误的原因一般就两类
安装插件或擅自修改程序。
不同的数据库版本数据库导出导入，比如MySQL4.1的数据在导出的语句包含了MySQL4.0没有的功能，像字符集的设定，这时如果将这些sql导入到MySQL4.0的时候就会产生sql语法错误。
仔细检查看到底是哪里的错误，将其修正，实在不行就用标准程序把出错的程序替换。
在数据库备份的时候要留意，如果不打算倒入到其他版本的mysql中则不用特殊考虑，反之要特殊的设定。使用DZ4.1的后台数据备份，可以按照提示去设定想要的格式。独立主机的也可以在到处的时候将其导出为mysql4.0的格式。
mysqldump -uroot -p --default-character-set=latin1 --set-charset=gbk --skip-opt databse & test.sql
十、Duplicate entry 'xxx' for key 1
翻译：插入 xxx 使索引1重复
分析：索引如果是primary unique这两两种，那么数据表的数据对应的这个字段就必须保证其每条记录的唯一性。否则就会产生这个错误。
一般发生在对数据库写操作的时候，例如Discuz!4.1论坛程序要求所有会员的用户名username必须唯一，即username的索引是
unique，这时如果强行往cdb_members表里插入一个已有的username的记录就会发上这个错误，或者将一条记录的username更新
为已有的一个username。
改变表结构的时候也有可能导致这个错误。例如 Discuz!4.0论坛的数据库中cdb_members.username
的索引类型是index这个时候是允许有相同username的记录存在的，在升级到4.1的时候，因为要将username的索引由原来的index变
为unique。如果这时cdb_members里存在有相同的username的记录，那么就会引发这个错误。
导出数据据时有时会因为一些原因（作者目前还不清楚）导致同一条记录被重复导出，那么这个备份数据在导入的时候出现这个错误是在所难免的了。
修改了auto_increment的值，致使“下一个 Autoindex”为一条已经存在的记录
解决： 两种思路，一是破坏掉唯一性的索引。二是把重复的数据记录干掉，只保留一条。很显然第一种思路是不可取的。那么按照二的思路我们得出以下几种解决方法，对应上面的i ii iii
按照错误提示里的信息到数据库中将重复的记录删除，仅保留一条即可。之后继续执行升级操作。
这种情况发生的概率很小，可以用文本编辑器打开备份文档，查找重复的信息。将其多余的拿掉，仅保留一条即可。
查询出表中auto_increment最大的一条记录，设置auto_incerment比其大一即可。
PS：repaire table "表名“，可以暂时解决问题。
十一、 Duplicate key name 'xxx'
翻译：索引名重复
分析：要创建的索引已经存在了，就会引发这个错误，这个错误多发生在升级的时候。可能是已经升级过的，重复升级引起的错误。也有可能是之前用户擅自加的索引，刚好与升级文件中的所以相同了。
解决： 看看已经存在的索引和要添加的索引是否一样，一样的话可以跳过这条sql语句，如果不一样那么现删除已存在的所以，之后再执行。
十二、 Duplicate column name 'xxx'
翻译：字段名xxx重复
分析：添加的字段xxx已经存在，多发生在升级过程中，与问题十二的产生是一样的。
解决： 看一下已经存在的字段是否和将要添加的字段属性完全相同，如果相同则可以跳过不执行这句sql，如果不一样则删除掉这个字段。之后继续执行升级程序。
十三、 Table 'xxx' already exists
翻译：数据表xxx已经存在
分析：xxx表已经存在于库中，再次试图创建这个名字的表就会引发这个错误。同样多发生在论坛的升级中。类似于问题十二。
解决： 看看已经存在的表是否和将要创建的表完全一样，一样的话可以跳过不执行这个sql，否则请将存在的表先删除，之后继续执行升级文件。
十四、 Can't create database 'xxx'. Database exists
翻译：不能创建数据库xxx，数据库已经存在
分析：一个mysql下面的数据库名称必须保证唯一性，否则就会有这个错误。
解决：把已经存在的数据库改名或者把将要创建的数据库改名，总之不让他们的名称冲突。
十五、 小结（针对问题 11\12\13\14\15）
此类问题错误提示中都暗藏一个关键词duplicate（重复）
那么对于mysql数据库来说什么东西是不能重复的呢？
数据库 database
同一个数据库下数据表 table
同一个数据表下字段 column
同一个数据表下索引 key
同一个数据表在索引唯一（UNIQUE PRIMARY）的情况下记录中的这些字段不可以重复
十六、Unknown system variable 'NAMES'
翻译：未知的系统变量NAMES
分析：Mysql版本不支持字符集设定，此时强行设定字符集就会出现这个错误。
解决： 将sql语句中的SET NAMES ‘xxx’ 语句去掉
十七、 Lost connection to MySQL server during query
翻译：MySQL服务器失去连接在查询期间
分析：远程连接数据库是有时会有这个问题。MySQL服务器在执行一条sql语句的时候失去了连接造成的。
解决： 一般不需要怎么去处理，如果频繁的出现那么考虑改善硬件环境。
十八、User 'red' has exceeded the 'max_updates' resource (current value: 500)
翻译：msql用户red已经超过了'max_updates'（最大更新次数），'max_questions'（最大查询次数），'max_connections'（最大连接数），当前设定为500
分析：在mysql数据库的下有一个库为mysql，它其中有一个表为user这里面的纪录每一条都对应为一个mysql用户的授权。其中字段
max_questions max_updates max_connections分别记录着最大查询次数 最大更新数
最大连接数，当目前的任何一个参数大于任何一个设定的值就会产生这个错误。
解决： 独立主机用户可以直接修改授权表。修改完之后重启mysql或者跟新授权表，进入mysql提示符下执行
FLUSH PRIVILEGES;
记得后面要有分号’;’
虚拟主机的用户如果总是出现这个问题可找空间商协商解决。
十九、Too many connections (1040)链接过多
翻译：达到最大连接数
问题分析：
连接数超过了mysql设置的值，与max_connections 和wait_timeout 都有关系。wait_timeout的值越大，连接的空闲等待就越长，这样就会造成当前连接数越大
解决方法：
1.虚拟主机用户请联系空间商优化 MySQL 服务器的配置；
2.独立主机用户请联系服务器管理员优化 MySQL 服务器的配置，可参考：
修改 MySQL 配置文件 my.ini 或者 my.cnf 中的参数：
max_connections= 1000
wait_timeout = 10
修改后重启 MySQL ，如果经常性的报此错误，请做一下服务器的整体优化。
二十、There is no such grant defined for user '%s' on host '%s'
错误编号：1141
问题分析：
MySQL 当前用户无权访问数据库。
解决方法：
1、虚拟主机用户请联系空间商，确认给你提供的帐号是否有授权数据库的权限。
2、独立主机用户请联系服务器管理员，确认给您提供的数据库帐号是否有管理此数据库的权限。
二十一、Error on rename of '%s' to '%s' (errno: %d)
error.:1025
问题分析：
请检查一下您的程序是否有修改数据库表名的语句。
解决方法：
1.请检查您的程序中哪些地方需要修改数据库表名；
2.如果您的实际应用确实需要修改到数据库表名的话，请联系空间商或者服务器管理员给您开放修改库名的权限和服务器本身是否正常。
二十二、Error reading file '%s' (errno: %d)
error.:1023
问题分析：
数据库文件不能被读取。
解决方法：
1.虚拟主机用户请联系空间商查看数据库是否完好。
2.独立主机用户请联系服务器管理员检查一下 MySQL 本身是否正常， MySQL 是否可以读取文件，Linux 用户可以检查一下 MySQL 的数据库文件的属主是否正确以及本身的文件是否损坏。
二十三、Host '*****' is blocked because of ma unblock with 'mysqladmin flush-hosts'
error.:1129
问题分析：
数据库出现异常，请重启数据库。
解决方法：
1. 由于存在很多连接错误，主机'****'被屏蔽，虚拟主机用户请联系空间商处理，独立主机用户请联系服务器管理员，在 MySQL 的命令控制台下执行'mysqladmin flush-hosts'解除屏蔽即可，或者重启 MySQL 数据库
二十四、dropping database (can't delete '%s', errno: %d)
error.:1009
问题分析：
不能删除数据库文件，导致删除数据库失败。
解决方法：
1.检查您使用的数据库管理帐号是否有权限删除数据。
2.检查数据库是否存在。
二十五、Got error 28 from table handler
error.:1030
问题分析：
数据库所在磁盘空间已满。
解决方法：
1.虚拟主机用户请联系空间商增加 MySQL 所在的磁盘空间或者清理一些无用文件；
2.独立主机用户请联系服务器管理员增加 MySQL 所在的磁盘空间或者清理一些无用文件
二十六、Can't if you are not out of
available memory, you can consult the manual for a possible OS-dependent
error.:11/35
问题分析：
数据库服务器问题，数据库操作无法创建新线程。一般是两个原因：
1.服务器系统内存溢出。
2.环境软件损坏或系统损坏。
解决方法：
1.虚拟主机用户请联系下空间商数据库服务器的内存和系统是否正常。
2.独立主机用户请联系服务器管理员检查服务器的内存和系统是否正常，如果服务器内存紧张，请检查一下哪些进程消耗了服务器的内存，同时考虑是否增加服务器的内存来提高整个的负载能力。
二十七、Error: Client does not support authentication protocol consider upgrading MySQL client
error.:1251
问题分析：
如果你升级 MySQL 到 4.1 以上版本后遇到以上问题,请先确定你的 MySQL Client 是 4.1 或者更高版本(
下有问题你就直接跳到下面看解决方法了，因为 MySQL 在 Windows 是 client 和 server 一起装上了的)。
解决方法：
1. Windows 平台
主要是改变连接 MySQL 的帐户的加密方式，MySQL 4.1/5.0 是通过 PASSWORD 这种方式加密的。可以通过以下两种方法得到解决：
1) mysql-&SET PASSWORD FOR 'some_user'@'some_host'=OLD_PASSWORD('new_password');
2) mysql-&UPDATE mysql.user SET Password=OLD_PASSWORD('new_password') WHERE Host='some_host' AND User='some_user';
2. Linux/Unix 平台
Linux 平台下首先确定是否安装过 MySQL 的客户端，这个用 rpm 安装很简单，Linux 代码为：
rpm -ivh MySQL-client-4.1.15-0.i386.rpm
然后在编译 php 的时候要加上：
--with-mysql=/your/path/to/mysql
一般情况下都可以解决。如果还出现这种错误，可以按照下面的方法来做：
mysql-&SET PASSWORD FOR 'some_user'@'some_host'=OLD_PASSWORD('new_password');
mysql-&UPDATE mysql.user SET Password=OLD_PASSWORD('new_password') WHERE Host='some_host' AND User='some_user';
二十八、Error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'
error.:2002
问题分析：
出现这个错误一般情况下是因为下面两个原因：
1.MySQL 服务器没有开启。
2.MySQL 服务器开启了，但不能找到 socket 文件。
解决方法：
1.虚拟主机用户，请联系空间商确认数据库是否正常启动。
2.独立主机用户，请检查一下 MySQL 服务是否已经开启，没有开启，请启动 MySQL 服务；如果已经开启，并且是 Linux 系统，请检查一下 MySQL 的 socket 的路径，然后打开 config.inc.php 找到
$dbhost = 'localhost'; 在 hostname 后面加冒号‘:’和 MySQL 的 socket 的路径。
比如 MySQL 服务器为 localhost
MySQL 的 socket 的路径为 /tmp/mysql.sock
那么就改成如下：
$dbhost = 'localhost:/temp/mysql.sock';
二十九、Can't connect to MySQL server on 'localhost'
error.:2003
问题分析：
MySQL 服务没有启动，一般是在异常的情况下 MySQL 无法启动导致的，比如无可用的磁盘空间，my.ini 里 MySQL 的 basedir 路径设置错误等。
解决方法：
1.检查磁盘空间是否还有剩余可用空间，尽量保持有足够的磁盘空间可用。
2.检查 my.ini 里的 basedir 等参数设置是否正确，然后重新启动下 MySQL 服务。
三十、Lost connection to MySQL server during query
error.:2013
问题分析：
数据库查询过程中丢失了与 MySQL 服务器的连接。
解决方法：
1.请确认您的程序中是否有效率很低的程序，比如某些插件，可以卸载掉插件，检查一下服务器是否正常；
2.服务器本身资源紧张，虚拟主机用户请联系空间商确认，独立主机用户请联系服务器管理员，检查一下服务器是否正常。
三十一、Got a packet bigger than \'max_allowed_packet\' bytes
错误编号：1153
问题分析：调整了 Mantis 的上传附件的大小却没有调整 MySQL 的配置文件。
解决办法：
1、独立主机用户请按照以下方法调整：
查找 MySQL 的配置文件（my.cnf 或者 my.ini）
在 [mysqld] 部分添加一句（如果存在，调整其值就可以）：
max_allowed_packet=10M
重启 MySQL 服务就可以了。这里设置的是 10MB。
2、虚拟主机用户请联系空间商调整此参数。
阅读(...) 评论()苹果/安卓/wp
积分 43283, 距离下一级还需 12612 积分
权限: 自定义头衔, 签名中使用图片, 隐身, 设置帖子权限, 设置回复可见, 签名中使用代码
道具: 涂鸦板, 彩虹炫, 雷达卡, 热点灯, 显身卡, 匿名卡, 金钱卡, 抢沙发, 变色卡, 提升卡, 沉默卡, 千斤顶, 置顶卡
购买后可立即获得
权限: 隐身
道具: 金钱卡, 变色卡, 彩虹炫, 雷达卡, 热点灯, 涂鸦板
【数据库】MySQL 高可用架构在业务层面的研究分析
　　前言：　　相对于传统行业的相对服务时间9x9x6或者9x12x5，因为互联网电子商务以及互联网游戏的实时性，所以服务要求7*24小时，业务架构不管是应用还是数据库，都需要容灾互备，在mysql的体系中，最好通过在最开始阶段的数据库架构阶段来实现容灾系统。所以这里从业务宏观角度阐述下mysql架构的方方面面。　　一. MySQL架构设计—业务分析　　（1）读多写少　　虚线表示跨机房部署，比如电子商务系统，一个Master既有读也有些写，对读数据一致性需要比较重要的，读要放在Master上面。　　M(R)仅仅是一个备库，只有M(WR)挂了之后，才会切换到M(R)上，这个时候M(R)就变成了读写库。比如游戏系统，有很多Salve会挂载后面一个M(R)上面。　　（2）读多写少MMS-电商　　如果是电子商务类型的，这种读多写少的，一般是1个master拖上4到6个slave，所有slave挂载在一个master也足够了。　　切换的时候，把M1的读写业务切换到M2上面，然后把所有M1上的slave挂到M2上面去，如下所示：　　（3）读多写少MMSS-游戏　　如果是游戏行业的话，读非常多蛮明显的，会出现一般1个Master都会挂上10个以上的Slave的情况，所以这个时候，可以把一部分Slave挂载新的M(R)上面。至少会减少一些压力，这样至少服务器挂掉的时候，不会对所有的slave有影响，还有一部分在M(R)上的slave在继续，不会对所有的slave受到影响，见图3，图3　　（4）读少写多　　意味着读并不会影响写的效率，所以读写都可以放在一个M1(WR)，而另外一个不提供读也不提供写，只提供standby冗余异地容灾。　　这个异地容灾是非常重要的，否则如果是单机的，单边的业务，万一idc机房故障了，一般就会影响在线业务的，这种 造成业务2小时无法应用，对于在线电子商务交易来说，影响是蛮大的，所以为了最大限度的保证7*24小时，必须要做到异地容灾，MM要跨idc机房。虽然对资源有一些要求，但是对HA来说是不可缺少的，一定要有这个MM机制。　　做切换的时候，把所有的读写从M1直接切换到M2上就可以了。　　（5）读写平分秋色　　读和写差不多，但是读不能影响写的能力，把读写放在M1(WR)上，然后把一部分读也放在M2(R)上面，当然M1和M2也是跨机房部署的。　　切换的时候，把一部分读和全部写从M1切换到M2上就可以了。　　二. MySQL架构设计—常见架构　　（1）强一致性　　对读一致性的权衡，如果是对读写实时性要求非常高的话，就将读写都放在M1上面，M2只是作为standby，就是采取和上面的一（4）的读少写多的一样的架构模式。　　比如，订单处理流程，那么对读需要强一致性，实时写实时读，类似这种涉及交易的或者动态实时报表统计的都要采用这种架构模式　　（2）弱一致性　　如果是弱一致性的话，可以通过在M2上面分担一些读压力和流量，比如一些报表的读取以及静态配置数据的读取模块都可以放到M2上面。比如月统计报表，比如首页推荐商品业务实时性要求不是很高，完全可以采用这种弱一致性的设计架构模式。　　（3）中间一致性　　如果既不是很强的一致性又不是很弱的一致性，那么我们就采取中间的策略，就是在同机房再部署一个S1(R)，作为备库，提供读取服务，减少M1(WR)的压力，而另外一个idc机房的M2只做standby容灾方式的用途。　　当然这里会用到3台数据库服务器，也许会增加采购压力，但是我们可以提供更好的对外数据服务的能力和途径，实际中尽可能两者兼顾。　　（4）统计业务　　比如PV、UV操作、页数的统计、流量的统计、数据的汇总等等，都可以划归为统计类型的业务。　　数据库上做大查询的统计是非常消耗资源的。统计分为实时的统计和非实时的统计，由于mysql主从是逻辑sql的模式，所以不能达到100%的实时，如果是online要严格的非常实时的统计比如像火车票以及金融异地结算等的统计，mysql这块不是它的强项，就只有查询M1主库来实现了。　　A，但是对于不是严格的实时性的统计，mysql有个很好的机制是binlog，我们可以通过binlog进行解析Parser，解析出来写入统计表进行统计或者发消息给应用端程序来进行统计。这种是准实时的统计操作，有一定的短暂的可接受的统计延迟现象，如果要100%实时性统计只有查询M1主库了。　　通过binlog的方式实现统计，在互联网行业，尤其是电商和游戏这块，差不多可以解决90%以上的统计业务。有时候如果用户或者客户提出要实时read-time了，大家可以沟通一下为什么需要实时，了解具体的业务场景，有些可能真的不需要实时统计，需要有所权衡，需要跟用户和客户多次有效沟通，做出比较适合业务的统计架构模型。　　B，还有一种offline统计业务，比如月份报表年报表统计等，这种完全可以把数据放到数据仓库里面或者第三方Nosql里面进行统计。　　（5）历史数据迁移　　历史数据迁移，需要尽量不影响现在线上的业务，尽量不影响现在线上的查询写入操作，为什么要做历史数据迁移？因为有些业务的数据是有时效性的，比如电商中的已经完成的历史订单等，不会再有更新操作了，只有很简单的查询操作，而且查询也不会很频繁，甚至可能一天都不会查询一次。　　如果这时候历史数据还在online库里面或者online表里面，那么就会影响online的性能，所以对于这种，可以把数据迁移到新的历史数据库上，这个历史数据库可以是mysql也可以是nosql，也可以是数据仓库甚至hbase大数据等。　　实现途径是通过slave库查询出所有的数据，然后根据业务规则比如时间、某一个纬度等过滤筛选出数据，放入历史数据库(History Databases)里面。迁移完了，再回到主库M1上，删除掉这些历史数据。这样在业务层面，查询就要兼顾现在实时数据和历史数据，可以在filter上面根据迁移规则把online查询和history查询对接起来。比如说一个月之内的在online库查询一个月之前的在history库查询，可以把这个规则放在DB的迁移filter层和应用查询业务模块层。如果可以的话，还可以配置更细化，通过应用查询业务模块层来影响DB的迁移filter层，比如以前查询分为一个月为基准，现在查询业务变化了，以15天为基准，那么应用查询业务模块层变化会自动让DB的filter层也变化，实现半个自动化，更加智能一些。　　（6）MySQL Sharding　　像oracle这种基于rac基于共享存储的方式，不需要sharding只需要扩从rac存储就能实现了。但是这种代价相对会比较高一些，共享存储一般都比较贵，随着业务的扩展数据的爆炸式增长，你会不停累计你的成本，甚至达到一个天文数字。　　目前这种share disk的方式，除了oracle的业务逻辑层做的非常完善之外其他的解决方案都还不是很完美。　　Mysql的sharding也有其局限性，sharding之后的数据查询访问以及统计都会有很大的问题，mysql的sharding是解决share nothing的存储的一种分布式的方法，大体上分为垂直拆分和水平拆分。　　（6.1）垂直拆分　　可以横向拆分，可以纵向拆分，可以横向纵向拆分，还可以按照业务拆分。　　6.1.1横向拆分　　Mysql库里面的横向拆分是指，每一个数据库实例里面都有很多个db库，每一个db库里面都有A表B表，比如db1库有A表B表，db2库里也有A表和B表，那么我们把db1、db2库的A表B表拆分出来，把一个库分成2个，就拆分成db1、db2、db3、db4，其中db1库和db2库放A表数据，db3库和db4库放B表的数据，db1、db2库里面只有A表数据，db3、db4库里面只有B表的数据。　　打个比方，作为电商来说，每个库里面都有日志表和订单表，假如A表是日志表log表，B表是订单表Order表，一般说来写日志和写订单没有强关联性，我们可以讲A表日志表和B表订单表拆分出来。那么这个时候就做了一次横向的拆分工作，将A表日志表和B表订单表拆分开来放在不同的库，当然A表和B表所在的数据库名也可以保持一致(PS：在不同的实例里面)，如下图所示：　　PS：这种拆分主要针对于不同的业务对表的影响不大，表之间的业务关联很弱或者基本上没有业务关联。拆分的好处是不相关的数据表拆分到不同的实例里面，对数据库的容量扩展和性能提高的均衡来说，都是蛮有好处的。　　6.1.2纵向拆分　　把同一个实例上的不同的db库拆分出来，放入单独的不同实例中。这种拆分的适应场景和要求是db1和db2是没有多少业务联系的，类似6.1.2里面的A表和B表那样。如果你用到了跨库业务同时使用db1和db2的话，个人建议要重新考虑下业务，重新梳理下尽量把一个模块的表放在一个库里面，不要垮库操作。　　这种库纵向拆分里面，单独的库db1，表A和表B是强关联的。如下图所示：　　PS：看到很多使用mysql的人，总是把很多没有业务关联性的表放在一个库里面，或者总是把很多个的db库放在同一个实例里面，就像使用oracle那样就一个instance的概念而已。Mysql的使用一大原则就是简单，尽量单一，简单的去使用mysql，库要严格的分开；表没有关系的，要严格拆分成库。这样的话扩展我们的业务就非常方便简单了，只需要把业务模块所在的db拆分出来，放入新的数据库服务器上即可。　　6.1.3横向纵向拆分　　有些刚起步的，开始为了快速出产品，就把所以的库所有的表都放在一个实例上，等业务发展后，就面临着数据拆分，这里就会把横向纵向拆分结合起来，一起实现，如下图所示：　　6.1.4业务拆分　　跟水平拆分有点类似，但是有不同的地方。比如一个供应商，可能整个网站上有10个供应商，一个网站上面每一个供应商都有一定的量，而且供应商之间的数据量规模都差不多的规模，那么这个时候就可以使用供应商的纬度来做拆分。　　比如usern库中，a、b、c表都是强关联的，都有完整的业务逻辑存在，这里只有用户（供应商）纬度是没有关联的，那这个时候就可以把数据以用户的纬度来进行拆分。　　就是用户1和用户2各自都有一套完整的业务逻辑，而且彼此之间不关联，所以就可以把用户1和用户2数据拆分到不同的数据库实例上面。目前很多互联网公司或者游戏公司有很多业务都是以用户纬度进行拆分的，比如qunaer、sohu game、sina等。　　（6.2） 水平拆分　　水平拆分相对要简单一些，但是难度偏大，会导致分布式的情况、跨数据的情况、跨事务的情况可以分为大概三类，1是历史数据和实时数据拆分，2是单库多表拆分，3是多库多表拆分。　　6.2.1实时数据历史数据的拆分　　和历史数据迁移是一样的逻辑，就是要将online库的数据迁移到listory的数据库里面，对于实时的读写来说，数据是放在online db库里面，对于时间较远的数据来说，是放在历史History DB记录库里面的，这里的历史库可以是mysql也可以是别的nosql库等。　　6.2.2单库多表拆分　　主要不是解决容量问题，而是解决性能问题而扩展的，加入当前实例只有一个DB，有一个大表，一个大表就把整个实例占满了，这个时候就不能拆分db了，因为只有一个单表，这个时候我们就只能拆表了，拆表的方式主要是解决性能问题，因为单个表越大，对于mysql来说遍历表的树形结构遍历数据会消耗更多的资源，有时候一个简单的查询就可能会引起整个db的很多叶子节点都要变动。表的insert、update、delete操作都会引起几乎所有节点的变更，此时操作量会非常大，操作的时候读写性能都会很低，这个时候我们就可以考虑把大表拆分成多个小表，工作经历中是按照hash取模打散成16个小表，也有按照id主键/50取模打散到50个小表当中，下图实例是打散成2个小表。　　6.2.3多库多表拆分　　在单库多表的基础上，如果单库空间资源已经不足以提供业务支撑的话，可以考虑多库多表的方式来做，解决了空间问题和性能问题，不过会有一个问题就是跨库查询操作，查询就会有另外的策略，比如说加一个logic db层来实现跨库跨实例自动查询，简单如下图所示：　　6.2.4水平拆分小结　　水平拆分原则：　　-- a.尽量均匀的拆分维度。　　-- b.尽量避免跨库事务。　　-- c.尽量避免跨库查询。　　设计：　　--a根据拆分维度，做mod进行数据表拆分，大部分都是取模的拆分机制，比如hash的16模原则等。　　--b根据数据容量，划分数据库拆分　　数据操作　　--a跨事务操作：分布式事务，通过预写日志的方式来间接地实现。　　--b跨库查询：数据汇总or消息服务　　6.2.5案例说明　　u 案例：　　– 按照用户维度进行拆分成64个分库，1024个分表　　?user_id%1024拆分到1024张分表中　　? 每个分库中存放1024/64张分表　　? 取模的时候，可以用id的最后4位数据或者3位数字来取模就可以了。　　u 操作1：采用Configure DB　　– 拆分之后的查询操作，做一个Configure DB，这个DB存放的是所有实例的库表的映射关系，当我APP发来有一个请求查询user1的数据，那么这个user1的数据是存放在上千个实例中的哪一个库表呢？这个关联信息就在Configure DB里面，APP先去Configure DB里面取得user1的关联系信息(比如是存放在d_01库上的t_0016表里面)，然后APP根据关联信息直接去查询对应的d_01实例的t_0016表里面取得数据。　　u 操作2：采用Proxy　　– 拆分之后的查询操作，做一个Proxy，APP访问Proxy，Proxy根据访问规则就可以直接路由到具体的db实例，生成新的sql去操作对应的db实例，然后通过Proxy协议进行操作把操作结果返回给APP。　　– 优势是Proxy和db实例是在一个网段，这样Proxy与db实例的操作的时间是非常短的。　　u 操作3：采用Data Engine　　– 拆分之后的查询操作，有一个Data Engine Service，这个DES里面配置了所有数据库实例的映射关系，需要在APP应用端安装一个Agent，是同步逻辑，在JDBC层实现，DES可以实现读写分离，原理可以参考TDDL的实现。　　6.3集群管理　　纵向扩容：一个实例拆分成多个实例，纵向拆分比较简单，修改的东西比较少，拆分的时候要通知到Configure DB或者DES，以免拆分之后查询不到数据或者数据录入不到新的db上面，如下图所示：　　横向扩容：比较复杂，在纵向扩容成2个库的基础之上，再一次对库的表进行扩容，所以需要及时通知Configure DB和DES更细库和表的路由连接信息。
http://www.cda.cn/
高薪就业·数据分析人才·牛人聚集圈
&nbsp&nbsp|
&nbsp&nbsp|
&nbsp&nbsp|
&nbsp&nbsp|
&nbsp&nbsp|
&nbsp&nbsp|
如有投资本站或合作意向，请联系（010-）；
邮箱：service@pinggu.org
投诉或不良信息处理：（010-）
论坛法律顾问：王进律师}