目录
- 0、mysql查看binlog
- 一般情况，大多数人都搞不清楚这些内容的区别。
- 1、my.cnf中的mysql,mysqld,client代表什么
- 2、本机登录mysql，不识别中文是什么情况。
- 系统本身查看是否支持中文。
- 3、外键创建报错：1215——mysql的error1215原因_MySQL数据报1215错误如何解诀?
- 4、mysql中的角色是如何赋予的
- 5、binlog日志突然增大的解决方法
- 6、为什么MySQL的事务隔离级别是RR（Read-Repeatable-重复读），而不是RC（Read-Comitted都提交）？
- 7、清理之前的日志
- 8、初始化数据库
- 9、初始密码修改--修改 root密码（3种）
- 10、修改普通用户的密码
0、mysql查看binlog
mysql> show binlog events; #只查看第一个binlog文件的内容
mysql> show binlog events in 'mysql-bin.000002';#查看指定binlog文件的内容
mysql> show binary logs; #获取binlog文件列表
mysql> show master status； #查看当前正在写入的binlog文件
一般情况，大多数人都搞不清楚这些内容的区别。
1、my.cnf中的mysql,mysqld,client代表什么
（1）[client]—客户端工具默认设置内容；
比如mysqldump,mysqlpump在运行时，就会读取[client]的参数，或[mysqldump]/[mysqlpump]等。
（2）[mysql] —使用mysql命令登录数据库时的默认的设置；
--案例：my.cnf位置在/mysql/data/3306/my.cnf，且[mysql]设置为：
[mysql] no-beep prompt="\u@mysql51 \R:\m:\s [\d]> " #no-auto-rehash auto-rehash default-character-set=utf8 socket = /mysql/data/3306/mysql.sock
--如下登录使用的就是这个my.cnf下的内容，因为登录后，显示的prompt为：
[root@mysql51 3306]# mysql --defaults-file=/mysql/data/3306/my.cnf -uroot -p 因为my.cnf中指定了socket的位置，所以使用不会报错/tmp/mysql.sock。
--如果不指定my.cnf的位置，则使用默认的[mysql]的值，则会报错，/tmp/mysql.sock，软连接即可
（3）[mysqld]— 数据库服务端的默认设置；
2、本机登录mysql，不识别中文是什么情况。
系统本身查看是否支持中文。
3、外键创建报错：1215——mysql的error1215原因_MySQL数据报1215错误如何解诀?
估计使用外键出错了，检查一下外键表和这个表
（1）两个字段的类型或者大小不严格匹配。
例如，如果一个是int(10)，那么外键也必须设置成int(10)，而不是int(11)，也不能是tinyint。另外，你还必须确定两个字段是否都为signed或者unsigned，这两字段必须严格地一致匹配。
（2） 设置外键的字段没有建立起索引，或者不是一个primary key(主键)。
一般，需要建立外键的数据表称为子表，而相关联的数据表称为父表。建立外键时所对应的父表的字段必须要创建索引primary key。
（3）其中一个或者两个表是MyISAM引擎的表。
若想要使用外键约束，表必须是InnoDB引擎(实际上，如果两个表都是MyISAM 引擎的，这个错误根本不会发生，但也不会产生外键，只会建立索引)你需要检查表的引擎类型。
（4）外键的名字不能重复。
检查该数据库确保外健名字是唯一的，或者你可以在键名后面加上几个随机的字符以测试是否为此原因。
（5）设置了ON DELETE SET NULL，但是相关的键的字段设置成了NOT NULL值。
通过修改外键的属性值或者把字段属性设置成allow null来解决。
（6）确保你的Charset和Collate选项在表级和字段级上的一致。
（7）两字段设置的默认值不一致。一个字段设置default为0，一个设置default为null，也是不可行的。
（8）ALTER声明中有语法错误。
4、mysql中的角色是如何赋予的
mysql 5.7和mysql 8.0的区别
5.7是模拟角色，将用户A的权限授予给用户B,C,D，用户A充当角色的意思；后期只对用户A进行权限更改即可。
8.0是和oracle一样的真正role.
5、binlog日志突然增大的解决方法
6、为什么MySQL的事务隔离级别是RR（Read-Repeatable-重复读），而不是RC（Read-Comitted都提交）？
详细分析见:
https://blog.csdn.net/srs1995/article/details/117821805
历史原因和bug
（1）历史原因
早阶段Mysql(5.1版本之前)的Binlog类型Statement是默认格式，即依次记录系统接受的SQL请求；
5.1及以后，MySQL提供了Row，Mixed，statement 3种Binlog格式， 当binlog为statement格式，使用RC隔离级别时，会出现BUG；因此Mysql将可重复读(Repeatable Read)作为默认的隔离级别！
（2）bug是什么
binlog为STATEMENT格式，且隔离级别为读已提交(Read Commited)时，有什么bug呢？ 测试结果：
在master上执行的顺序为先删后插！而此时binlog为STATEMENT格式，是基于事务记录，在事务未提交前，二进制日志先缓存，提交后再写入记录的,因此顺序为先插后删！slave同步的是binglog，因此从机执行的顺序和主机不一致！slave在插入后删除了所有数据.
解决方案有两种！
(1)隔离级别设为可重复读(Repeatable Read),在该隔离级别下引入间隙锁。当Session 1执行delete语句时，会锁住间隙。那么，Ssession 2执行插入语句就会阻塞住！
(2)将binglog的格式修改为row格式，此时是基于行的复制，自然就不会出现sql执行顺序不一样的问题！奈何这个格式在mysql5.1版本开始才引入。
因此由于历史原因，mysql将默认的隔离级别设为可重复读(Repeatable Read)，保证主从复制不出问题！
7、清理之前的日志
purge binary logs to 'llldb-binlog.000004';
8、初始化数据库
mysqld --defaults-file=/mysql/data/3306/my.cnf --initialize --user=mysql --basedir=/mysql/app/mysql --datadir=/mysql/data/3306/data
9、初始密码修改--修改 root密码（3种）
（1）方法1：mysqladmin处理
mysqladmin -u root -h localhost -p password 'rootroot';
（2）方法2：修改mysql.user表
use mysql;
update mysql.user set authentication_string=PASSWORD('root') where user='root';
flush privileges;
（3）方法3：set语句
set password=PASSWORD('rootroot');
flush privileges;
（4）方法4：使用alter user
alter user 'root'@'localhost' identified by 'rootroot'; alter user 'root'@'%' identified by 'rootroot';
10、修改普通用户的密码
（1）方法1：修改mysql.user表
use mysql;
update mysql.user set authentication_string=PASSWORD('123') where user='test' and host='localhost';
flush privileges;
（2）方法2：grant方式修改
grant usage on *.* to 'test'@'%' identified by '123'; grant usage on *.* to 'test'@'localhost' identified by '123'; flush privileges;
（3）方法3：set语句
set password=PASSWORD('123');
（4）使用alter user(推荐)
alter user "test'@'localhost" identified by '123'; alter user 'test'@'%' identified by '123';
