1、打开mysql的客户端 这里使用navicat，连接数据库，等到navicat主页面，双击需要操作的数据库连接。
创新互联公司主要从事网站制作、做网站、网页设计、企业做网站、公司建网站等业务。立足成都服务西工,10余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18980820575
2、登录到数据库主页面后，点击左侧的数据库连接，打开数据库，可以看到可以操作的所有数据库。
3、这时有有两个数据库，目标是将数据1的所有数据同步到数据库2上，需要点击主页面上的。
4、打开工具菜单，选择数据库同步菜单，弹出数据同步的对话框，可以选择数据源，目标数据库。
5、选择数据库源和需要操作的数据库后，然后在选择目标数据库连接，目标数据库，然后在选择需要操作的表，点击开始即可。
当在使用中，查询缓存会存储一个 SELECT 查询的文本与被传送到客户端的相应结果。如果之后接收到一个同样的查询，服务器将从查询缓存中检索结果，而不是再次分析和执行这个同样的查询。
注意：查询缓存绝不返回过期数据。当数据被修改后，在查询缓存中的任何相关词条均被转储清除。
在某些表并不经常更改，而你又对它执行大量的相同查询时，查询缓存将是非常有用的。对于许多 WEB 服务器使用大量的动态信息，这是一个很典型的情况。
下面是查询缓存的一个性能数据。（这些结果的产生，是通过在一个 a Linux Alpha 2 x 500 MHz、2GB RAM 和 64MB 查询缓存上执行 MySQL 基准套件和到的）：
如果你执行的所有查询均是简单的（比如从表中一行一行的选取）；但是仍然是不同的，所以该查询不能被缓冲，查询缓存处于活动时，开销为 13%。这可以被看作是最差的情况。然而，在实际情况下，查询是比我们的简单示例要复杂得多的，所以开销通常显着得低。
在只有一行记录表中搜索一行后，搜索将快 238% 。这可以被认为是接近于对一个被缓冲的查询所期望的最小的加速。
如果你希望禁用查询缓存，设置 query_cache_size=0。禁用了查询缓存，将没有明显的开销。（在配置选项 --without-query-cache 的帮助下，查询缓存可以被排除在外码之外）
查询在分析之前先被比较，因而
SELECT * FROM tbl_name和Select * from tbl_name
对于查询缓存被当作是不同的查询，因而查询需要严格的一致（字节对字节的），才会被认为是同样的。 另外，如果一个客户端使用一个新的连接协议格式或不同于其它客户端的另一个字符集，一个查询将被视为不同的。
使用不同数据库的，使用不同协议版本的，或使用不同的缺省字符串的查询将被认为是不同的查询，并将分别的缓冲。
高速缓冲不对 SELECT CALC_ROWS … 和 SELECT FOUND_ROWS（） … 类型的查询起作用，因为找到的行的数目也是被存储在缓冲里的。
如果查询结果被从查询缓存中返回，那么状态变量 Com_select 将不会被增加，但是 Qcache_hits 却会增加。
查看章节 6.9.4 查询缓存的状态和维护。
如果一个表发生的改变 （INSERT, UPDATE, DELETE, TRUNCATE, ALTER 或 DROP TABLE|DATABASE），那么所有这张表使用的缓冲的查询（可能通过一个 MRG_MyISAM 表！）将被得失效，并从缓冲中移除。
InnoDB 表的事务所做的更改将在一个 COMMIT 被完成时，使数据失效。
如果一个查询包括下面的函数，它将不能被缓冲：
函数 函数 函数
User-Defined Functions CONNECTION_ID FOUND_ROWS
GET_LOCK RELEASE_LOCK LOAD_FILE
MASTER_POS_WAIT NOW SYSDATE
CURRENT_TIMESTAMP CURDATE CURRENT_DATE
CURTIME CURRENT_TIME DATABASE
ENCRYPT （只有一个参数调用） LAST_INSERT_ID RAND
UNIX_TIMESTAMP （无参数调用） USER BENCHMARK
如果一个查询包含用户变量，引用 MySQL 系统数据库，或下列之一的格式，SELECT … IN SHARE MODE, SELECT … INTO OUTFILE …， SELECT … INTO DUMPFILE … 或 SELECT * FROM AUTOINCREMENT_FIELD IS NULL （检索最后一个插入 ID - ODBC 语句），该查询亦不可以被缓存。
然而，FOUND ROWS（） 将返回正确的值，即使先前的查询是从缓存中读取的。
万一一个查询不使用任何表，或使用临时表，或用户对任何相关表有一个列权限，那么查询将不会被缓存。
在一个查询从查询缓存中读取前，MySQL 将检查用户对所有相关的数据库和表有 SELECT 权限。
我们都知道 MySQL 的 Table Cache 是表定义的缓存，江湖上流传着各种对这个参数的调优方法。
table cache 的作用，就是节约读取表结构文件的开销。对于table cache 是否命中，其实table cache 是针对于线程的，每个线程有自己的缓存，只缓存本线程的表结构定义。不过我们发现，strace 中没有关于表结构文件的 open 操作（只有 stat 操作，定位表结构文件是否存在），也就是说 table cache 不命中，不一定需要读取表结构文件。这种感觉好像是：在不命中 table cache 时，命中了另外一个表结构缓存。
运维建议：
我们读一下 MySQL 的文档，关于 table_open_cache 的建议值公式：建议值 = 最大并发数 * join 语句涉及的表的最大个数。
通过实验我们容易理解：table_cache 是针对于线程的，所以需要最大并发数个缓存。另外，一个语句 join 涉及的表，需要同时在缓存中存在。所以最小的缓存大小，等于语句 join 涉及的表的最大个数。将这两个数相乘，就得到了 MySQL 的建议值公式。
可以通过如下命令查看现在缓存的情况
[java] view plain copy
mysql show status like 'qcache%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_free_blocks | 1 |
| Qcache_free_memory | 10475424 |
| Qcache_hits | 1 |
| Qcache_inserts | 1 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 0 |
| Qcache_queries_in_cache | 1 |
| Qcache_total_blocks | 4 |
+-------------------------+----------+
8 rows in set (0.00 sec)
其中各个参数的意义如下：
Qcache_free_blocks：缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。
Qcache_free_memory：缓存中的空闲内存。
Qcache_hits：每次查询在缓存中命中时就增大
Qcache_inserts：每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。
Qcache_lowmem_prunes：缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个 数字在不断增长，就表示可能碎片非常严重，或者内存很少。(上面的 free_blocks和free_memory可以告诉您属于哪种情况)
Qcache_not_cached：不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句或者用了now()之类的函数。
Qcache_queries_in_cache：当前缓存的查询(和响应)的数量。
Qcache_total_blocks：缓存中块的数量。
redis缓存其实就是把经常访问的数据放到redis里面，用户查询的时候先去redis查询，没有查到就执行sql语句查询，同时把数据同步到redis里面。redis只做读操作，在内存中查询速度快。
使用redis做缓存必须解决两个问题，首先就是确定用何种数据结构存储来自mysql的数据；确定数据结构之后就是需要确定用什么标识来作为数据的key。
mysql是按照表存储数据的，这些表是由若干行组成。每一次执行select查询，mysql都会返回一个结果集，这个结果是由若干行组成的。redis有五种数据结构：列表list，哈希hash，字符串string，集合set，sorted set(有序集合)，对比几种数据结构，string和hash是比较适合存储行的数据结构，可以把数据转成json字符串存入redis。
全量遍历键： keys pattern keys *
有人说 KEYS 相当于关系性数据的库的 select * ，在生产环境几乎是要禁用的
不管上面说的对不对， keys 肯定是有风险的。那我们就换一种方案，在存数据的时候。把数据的键存一下，也存到redis里面选hash类型，那么取的时候就可以直接通过这个hash获取所有的值，自我感觉非常好用！