1.安装mysql过程中，出现丢失MSVCP140.DLL报错


MySQL 错误异常处理备忘录 - 图1

解决方案
下载并安装VC++2015运行库

2.安装VC++2015运行库失败
MySQL 错误异常处理备忘录 - 图2
解决方案
控制面板-》Windows更新，更新到最新补丁

3.还原数据库时，failed on open file
原句

  1. source c:testdata.sql

解决方法

  1. source c:\\testdata.sql

windows里面的遇到地址都改\

主从同步相关

从库同步状态报错：Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND

从库执行

  1. SHOW SLAVE STATUS;

发现 Slave_SQL_Running 字段值为 NO ,在 Last_Error 字段下显示如下具体错误：

Could not execute Update_rows event on table demo.table1; Can’t find record in ‘table1’, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event’s master log binlog.000024, end_log_pos 65969402

解决方法

  1. stop slave ;
  2. change master to 
  3. master_host='192.168.1.18',master_port=30000,
  4. master_user='root',master_password='123456',
  5. master_log_file='binlog.000024',master_log_pos=66589813;
  6. start slave ;

master and slave have equal MySQL server UUIDs

相关资料

slave的中继日志relay-log损坏

错误信息

发现从库和主库的信息有错误，执行show slave status; 发现主从同步异常，异常信息如下：

Error initializing relay log position: I/Oerror reading event at position 4

分析

出现这样的原因是slave出现宕机，或者非法关机，例如电源故障、主板烧了等，造成中继日志损坏，同步停掉。
下面要做的就是恢复主从备份

解决方案

  • 手动恢复

在主库上找到同步的binlog和POS点，然后重新做同步，这样就可以有新的中继日志了。

  1. stop slave;
  2. change master to master_log_file='mysql-relay-bin.000010',master_log_pos=283;
  3. start slave;
  • 自动恢复

mysql5.5考虑到slave宕机中继日志损坏这一问题，只要在slave的的配置文件my.cnf里增加一个参数relay_log_recovery=1即可。
salve的重要参数：relay_log_recovery=1

注：上面两种方式都可能会有主从的旧数据不一致的问题，如果想要完全一致目前的方法是重做从库。

相关资料

MySQL在处理新的线程连接请求时，会尝试进行DNS解析，如果在host cache和Hosts里找不到，处理起来就会很慢，因此最直接简便的方法就是禁用该反向解析功能，可以通过修改MySQL的配置文件实现，Linux下是my.cnf文件，windows下是my.ini文件，在配置文件[mysqld]下新增如下一行代码：
skip-name-resolve
然后重启MySQL服务，再次连接发现已是秒连了。这个方案的不足之处就是，以后在使用grant对用户进行授权时只能使用IP格式，而不能使用主机名称了。
通过修改系统hosts文件也可以实现，举例来说，我想解决192.168.1.100远程连接MySQL服务器缓慢的问题，只需要在MySQL库所在服务器的hosts文件中新增一条记录如下：
192.168.1.100 test.com
保存退出，再次远程连接该MySQL库，同样很快。之所以说绝，是因为这样设置，你添加记录的192.168.1.100远程连接速度变快了，其他主机连接速度跟之前一样慢。该方法同样可以解决ssh远程连接某主机响应很慢的问题，原理一样。

查询视图无权限，用户已经赋值了show view的权限

原因：
视图的安全性设置导致的这个问题，当视图的安全性为DEFINER时，数据库中存在DEFINER指定的用户，也就是图中的定义者所填写的。并且该用户拥有对应的权限，才能执行。与当前用户是否有权限无关。
当视图的安全性为INVOKER时，只要执行者有执行权限，就可以成功执行。
上图时我修改后问题解决的图了,因为当时写的是‘root@192.168.%.%’且视图的安全性为DEFINER引起的。当然，如果开发不是指定帐号只读的话，也可以将安全性定义INVOKER，这样只要有对这个视图有权限的都可以查看了。