如何将mysql数据库分开导出

如何将mysql数据库分开导出

mysql数据库分开导出mysql是我们学习过程中经常要用到的数据库，与此同时，如何导出数据也是一个必须要学习的技能工具/原料mysqlNavicat For MySql连接数据库1双击打开Navicat,点击“连接”，在弹出框中输入连接名（连接名可随便定义，只要能识别清楚，例如conn），输入用户名，密码，点击“连接测试”，弹出“连接成功”，则表示用户名，密码输入正确，点击“确定”，创建连接END导出一个数据库中所有表的数据双击连接名conn，双击要打开的数据库，在右边看到该数据库中的所有表选中数据库，右键选中“转存Sql文件”，选择“结构与数据”，（结构与数据导出的是表结构和表中数据，结构导出的则只是表结构）。

mysql怎么分离数据库

mys

MySQL数据库性能优化之分区分表分库

分表是分散数据库压力的好方法。 分表，最直白的意思，就是将一个表结构分为多个表，然后，可以再同一个库里，也可以放到不同的库。

当然，首先要知道什么情况下，才需要分表。

个人觉得单表记录条数达到百万到千万级别时就要使用分表了。 分表的分类 **1、纵向分表** 将本来可以在同一个表的内容，人为划分为多个表。（所谓的本来，是指按照关系型数据库的第三范式要求，是应该在同一个表的。） 分表理由：根据数据的活跃度进行分离，（因为不同活跃的数据，处理方式是不同的） 案例： 对于一个博客系统，文章标题，作者，分类，创建时间等，是变化频率慢，查询次数多，而且最好有很好的实时性的数据，我们把它叫做冷数据。

而博客的浏览量，回复数等，类似的统计信息，或者别的变化频率比较高的数据，我们把它叫做活跃数据。所以，在进行数据库结构设计的时候，就应该考虑分表，首先是纵向分表的处理。 这样纵向分表后： 首先存储引擎的使用不同，冷数据使用MyIsam 可以有更好的查询数据。

活跃数据，可以使用Innodb ,可以有更好的更新速度。 其次，对冷数据进行更多的从库配置，因为更多的操作时查询，这样来加快查询速度。对热数据，可以相对有更多的主库的横向分表处理。

其实，对于一些特殊的活跃数据，也可以考虑使用memcache ,redis之类的缓存，等累计到一定量再去更新数据库。或者mongodb 一类的nosql 数据库，这里只是举例，就先不说这个。 **2、横向分表** 字面意思，就可以看出来，是把大的表结构，横向切割为同样结构的不同表，如，用户信息表，user_1,user_2等。

表结构是完全一样，但是，根据某些特定的规则来划分的表，如根据用户ID来取模划分。 分表理由：根据数据量的规模来划分，保证单表的容量不会太大，从而来保证单表的查询等处理能力。 案例：同上面的例子，博客系统。当博客的量达到很大时候，就应该采取横向分割来降低每个单表的压力，来提升性能。

例如博客的冷数据表，假如分为100个表，当同时有100万个用户在浏览时，如果是单表的话，会进行100万次请求，而现在分表后，就可能是每个表进行1万个数据的请求（因为，不可能绝对的平均，只是假设），这样压力就降低了很多很多。 延伸：为什么要分表和分区？ 日常开发中我们经常会遇到大表的情况，所谓的大表是指存储了百万级乃至千万级条记录的表。这样的表过于庞大，导致数据库在查询和插入的时候耗时太长，性能低下，如果涉及联合查询的情况，性能会更加糟糕。分表和表分区的目的就是减少数据库的负担，提高数据库的效率，通常点来讲就是提高表的增删改查效率。

什么是分表？ 分表是将一个大表按照一定的规则分解成多张具有独立存储空间的实体表，我们可以称为子表，每个表都对应三个文件，MYD数据文件，.MYI索引文件，.frm表结构文件。这些子表可以分布在同一块磁盘上，也可以在不同的机器上。app读写的时候根据事先定义好的规则得到对应的子表名，然后去操作它。 什么是分区？ 分区和分表相似，都是按照规则分解表。

不同在于分表将大表分解为若干个独立的实体表，而分区是将数据分段划分在多个位置存放，可以是同一块磁盘也可以在不同的机器。分区后，表面上还是一张表，但数据散列到多个位置了。app读写的时候操作的还是大表名字，db自动去组织分区的数据。

**MySQL分表和分区有什么联系呢？** 1、都能提高mysql的性高，在高并发状态下都有一个良好的表现。 2、分表和分区不矛盾，可以相互配合的，对于那些大访问量，并且表数据比较多的表，我们可以采取分表和分区结合的方式（如果merge这种分表方式，不能和分区配合的话，可以用其他的分表试），访问量不大，但是表数据很多的表，我们可以采取分区的方式等。 3、分表技术是比较麻烦的，需要手动去创建子表，app服务端读写时候需要计算子表名。

采用merge好一些，但也要创建子表和配置子表间的union关系。 4、表分区相对于分表，操作方便，不需要创建子表。 我们知道对于大型的互联网应用，数据库单表的数据量可能达到千万甚至上亿级别，同时面临这高并发的压力。Master-Slave结构只能对数据库的读能力进行扩展，写操作还是集中在Master中，Master并不能无限制的挂接Slave库，如果需要对数据库的吞吐能力进行进一步的扩展，可以考虑采用分库分表的策略。

**1、分表** 在分表之前，首先要选中合适的分表策略（以哪个字典为分表字段，需要将数据分为多少张表），使数据能够均衡的分布在多张表中，并且不影响正常的查询。在企业级应用中，往往使用org_id(组织主键)做为分表字段，在互联网应用中往往是userid。在确定分表策略后，当数据进行存储及查询时，需要确定到哪张表里去查找数据， 数据存放的数据表 = 分表字段的内容 % 分表数量 **2、分库** 分表能够解决单表数据量过大带来的查询效率下降的问题，但是不能给数据库的并发访问带来质的提升，面对高并发的写访问，当Master无法承担高并发的写入请求时，不管如何扩展Slave服务器，都没有意义了。

我们通过对数据库进行拆分，来提高数据库的写入能力，即所谓的分库。分库采用对关键字取模的方式，对数据库进行路由。 数据存放的数据库=分库字段的内容%数据库的数量 **3、即分表又分库** 数据库分表可以解决单表海量数据的查询性能问题，分库可以解决单台数据库的并发访问压力问题。 当数据库同时面临海量数据存储和高并发访问的时候，需要同时采取分表和分库策略。

一般分表分库策略如下： 中间变量 = 关键字%（数据库数量*单库数据表数量） 库 = 取整（中间变量/单库数据表数量） 表 = （中间变量%单库数据表数量） 实例： 1、分库分表 很明显，一个主表（也就是很重要的表，例如用户表）无限制的增长势必严重影响性能，分库与分表是一个很不错的解决途径，也就是性能优化途径，现在的案例是我们有一个1000多万条记录的用户表members,查询起来非常之慢，同事的做法是将其散列到100个表中，分别从members0到members99，然后根据mid分发记录到这些表中，牛逼的代码大概是这样子： 代码如下: 2、不停机修改mysql表结构 同样还是members表，前期设计的表结构不尽合理，随着数据库不断运行，其冗余数据也是增长巨大，同事使用了下面的方法来处理： 先创建一个临时表： /*创建临时表*/ CREATE TABLE members_tmp LIKE members 然后修改members_tmp的表结构为新结构，接着使用上面那个for循环来导出数据，因为1000万的数据一次性导出是不对的，mid是主键，一个区间一个区间的导，基本是一次导出5万条吧，这里略去了 接着重命名将新表替换上去： /*这是个颇为经典的语句哈*/ RENAME TABLE members TO members_bak,members_tmp TO members; 就是这样，基本可以做到无损失，无需停机更新表结构，但实际上RENAME期间表是被锁死的，所以选择在线少的时候操作是一个技巧。经过这个操作，使得原先8G多的表，一下子变成了2G多。

SpringBoot项目中实现MySQL读写分离

但我们仔细观察我们会发现，当我们的项目都是用的单体数据库时，那么就可能会存在如下问题： 为了解决上述提到的两个问题，我们可以准备两 (多) 台MySQL，一台主( Master )服务器，一台从( Slave )服务器，主库的 数据变更 (写、更新、删除这些操作) ，需要 同步 到从库中 (主从复制) 。而用户在访问我们项目时，如果是 写操作 (insert、update、delete)，则直接操作 主库 ；如果是 读操作 (select) ，则直接操作从库，这种结构就是 读写分离 啦。

在这种读写分离的结构中，从库是可以有多个的 MySQL主从复制是一个 异步 的复制过程，底层是基于Mysql数据库自带的 二进制日志 功能。

就是一台或多台MySQL数据库（slave，即 从库 ）从另一台MySQL数据库（master，即 主库 ）进行日志的复制，然后再解析日志并应用到自身，最终实现 从库 的数据和 主库 的数据保持一致。MySQL主从复制是 MySQL数据库自带功能，无需借助第三方工具。 二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但是不包括数据查询语句。此日志对于灾难时的数据恢复起着极其重要的作用，MySQL的主从复制， 就是通过该binlog实现的。

默认MySQL是未开启该日志的。 在环境搭建之前，我们需要准备好两台服务器，如果生活富裕使用的是两台云服务器的时候记得要开放安全组，即防火墙；如果是比狗子我生活好点但也是用的虚拟机的话，记得别分这么多内存启动蓝屏了（别问怎么知道的） 这里就不给大家展示数据库的安装和防火墙的操作了，这个我感觉网上好多资源都能够满足遇到的问题，在搭建主从库的时候有在网上见到过说MySQL版本要一致的，我也没太留意直接就在之前的MySQL上操作了，大家可以自己去验证一下。 服务器：192.168.150.100（别试了黑不了的，这是虚拟机的ip） 这里有三个方法都能重启MySQL，最简单的无疑就是一关一开： 登录进去MySQL之后才能够执行下面的命令，因为这是SQL命令，Linux不认识这玩意是啥。

这个时候还 不用退出MySQL ，因为下面的命令还是SQL命令，执行下面的SQL，可以拿到我们后面需要的两个重要参数。 执行完这一句SQL之后，==不要再操作主库！不要再操作主库！不要再操作主库！==重要的事情说三遍，因为再操作主库之后可能会导致红框中的 两个属性值会发生变化 ，后面如果发生了错误可能就和这里有那么两毛钱关系了。 服务器：192.168.150.101（别试了黑不了的，这也是虚拟机的ip） 这里要注意server-id和主库以及其他从库都不能相同，否则后面将会配置不成功。

这里有三个方法都能重启MySQL，最简单的无疑就是一关一开： 登录进去MySQL之后才能够执行下面的命令，因为这是SQL命令 参数说明： 这个时候还 不用退出MySQL ，因为下面的命令还是SQL命令，执行下面的SQL，可以看到从库的状态信息。通过状态信息中的 Slave_IO_running 和 Slave_SQL_running 可以看出主从同步是否就绪，如果这两个参数全为 Yes ，表示主从同步已经配置完成。 这可能是由于linux 是复制出来的，MySQL中还有一个 server_uuid 是一样的，我们也需要修改。

vim /var/lib/mysql/auto.cnf 这应该就是各位大牛设置server_id的时候不小心设置相同的id了，修改过来就行，步骤在上面的配置中。 这是狗子在操作过程中搞出来的一个错误…… 出错的原因是在主库中删除了用户信息，但是在从库中同步的时候失败导致同步停止，下面记录自己的操作（是在进入MySQL的操作且是从库）。 在数据库中操作时，一定要注意当前所在的数据库是哪个，作为一个良好的实践：在SQL语句前加 USE dbname 。 Sharding-JDBC定位为 轻量级Java框架 ，在Java的JDBC层提供的额外服务。

它使用客户端直连数据库，以 jar包 形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动， 完全兼容JDBC和各种ORM框架 。 使用Sharding-JDBC可以在程序中轻松的实现数据库 读写分离 。 Sharding-JDBC具有以下几个特点： 下面我们将用ShardingJDBC在项目中实现MySQL的读写分离。 在pom.xml文件中导入ShardingJDBC的依赖坐标 在application.yml中增加数据源的配置 这时我们就可以对我们项目中的配置进行一个测试，下面分别调用一个更新接口和一个查询接口，通过查看日志中记录的数据源来判断是否能够按照我们预料中的跑。

搞定！！！程序正常按照我们预期的成功跑起来了，成功借助ShardingJDBC在我们项目中实现了数据库的读写分离。