mysql 5.6 bug

https://dev.mysql.com/doc/refman/5.6/en/account-management-sql.html

USE mysql;

SELECT Host,User FROM user;

【BUG】
CREATE USER ‘xx‘@‘%‘ IDENTIFIED BY ‘yy‘;GRANT ALL PRIVILEGES ON *.* TO ‘xx‘@‘%‘ WITH GRANT OPTION;
#ERROR 1045 (28000): Access denied for user ‘xx‘@‘localhost‘ (using password: YES)
CREATE USER ‘xx‘@‘localhost‘ IDENTIFIED BY ‘yy‘;GRANT ALL PRIVILEGES ON *.* TO ‘xx‘@‘localhost‘ WITH GRANT OPTION;

DROP USER ‘xx‘@‘%‘;
DROP USER ‘ll‘@‘%‘;

【5.6 无效,在没重启服务的情况下;未测5.7、重启】
UPDATE user SET Password=‘newyy‘ WHERE User=‘xx‘;
#ERROR 1372 (HY000): Password hash should be a 41-digit hexadecimal number
#SET PASSWORD FOR ‘xx‘@‘localhost‘ = ‘123‘;

【有效】
SET PASSWORD FOR ‘xx‘@‘localhost‘ = PASSWORD(‘123‘);

mysql> SELECT Host,User FROM user;
+-------------------+------+
| Host | User |
+-------------------+------+
| % | xx |
| 127.0.0.1 | root |
| ::1 | root |
| bigdata-server-02 | |
| bigdata-server-02 | root |
| localhost | |
| localhost | root |
| localhost | xx |
+-------------------+------+
8 rows in set (0.00 sec)

SET PASSWORD FOR ‘root‘@‘localhost‘ = PASSWORD(‘root123‘);
SET PASSWORD FOR ‘root‘@‘127.0.0.1‘ = PASSWORD(‘root123‘);
SET PASSWORD FOR ‘root‘@‘bigdata-server-02‘ = PASSWORD(‘root123‘);
SET PASSWORD FOR ‘root‘@‘::1‘ = PASSWORD(‘root123‘);

时间: 2024-10-19 22:02:53

mysql 5.6 bug的相关文章

【改变mysql 日志位置Bug】Could not use mysql.log for logging (error 13)

今天手贱,看到mysql 的日志在/var/log/mysql下面.总是觉得别扭,于是就想改变日志的位置, 本人开发环境 vagrant  + ubuntu12.04 ,在/etc/mysql/mysql中修改了general_log的位置,放在/data/logs/mysql下面 然后重启服务,service mysql restart 查看错误日志发现说 /usr/sbin/mysqld: File '/data/logs/mysql/mysql.log' not found (Errcod

【MySQL 线上 BUG 分析】之 多表同字段异常:Column ‘xxx’ in field list is ambiguous

一.生产出错! 今天早上11点左右,我在工作休息之余,撸了一下猫.突然,工作群响了,老大在里面说:APP出错了! 妈啊,这太吓人了,因为只是说了出错,但是没说错误的信息.所以我赶紧到APP上看看. 这果然是出错了,而且还是简单而粗暴的500,太吓人了. 二.本地赶紧调试起来! 既然线上出错了,我们又不能直接进行调试,那当然得马上在本地搞起来了! 1.代码是否有错? 立马启动本地的项目,访问对应的接口,看看是不是代码哪里出错了. 好了,本地的代码和 SQL 都是没错的! 2.SQL 是否有错? 那

悲剧啊!Mysql的上古BUG!!!

导读 这是MySQL8.0修复的上古bug之一,在2003年由Percona的CEO(当时应该还没Percona吧)提出的bug#199,光看这bug号就扑面而来一股上古时代的沧桑气息. 问题的本质在于InnoDB初始化AUTO_INCREMENT的方式,在每次重启时,总是算出表上最大的自增值作为最大值,下一次分配从该值开始.这意味着如果在btree右侧叶节点大量删除记录,重启后,自增值可能被重用.这在很多场景下可能导致问题,包括但不限于:主备切换.历史数据迁移等场景.在bug#199下面一大堆

MySql 参数赋值bug (MySql.Data, Version=6.9.6.0 沙雕玩意)

直接将参数赋值为常量0则参数值为null,出现异常:MySql.Data.MySqlClient.MySqlException (0x80004005): Column 'PayType' cannot be null public static long CreateIntegralPay(long memId, decimal payAmount, decimal buyIntegral) { var id = BitConverter.ToInt64(Guid.NewGuid().ToBy

MySQL upate 之bug 吗?

SELECT VERSION() 5.5.23 SELECT * FROM t20 UPDATE t20 SET a=1AND b=2 SELECT * FROM t20 UPDATE t20 SET a=1AND b=2 明天截图.

MySQL关于exists的一个bug

今天碰到一个很奇怪的问题,关于exists的, 第一个语句如下: SELECT count(1) FROM APPLY t WHERE EXISTS ( SELECT r.APPLY_ID FROM RECORD r WHERE t.APPLY_ID = r.APPLY_ID ); 产生的结果是:89584 第二个语句如下: SELECT count(1) FROM APPLY t WHERE EXISTS ( SELECT max(r.FINISH_TIME) FROM RECORD r WH

MySQL TIMESTAMP 类型加索引时出现的bug

数据库:MySQL,版本:5.1.45 查询语句1: select id, settlement_begin_time , settlement_end_time  from mkt_vendor_settlement_brief where settlement_begin_time >= '2017-09-01 00:00:00.0' and settlement_end_time <=  '2017-09-30 23:59:59.0': 结果: 查询语句2: select id, set

MySQL Bug导致异常宕机的分析流程

原文链接:http://click.aliyun.com/m/42521/ 摘要: 本文主要通过一个bug来记录一下如何分析一个MySQL bug的崩溃信息. 版本:Percona 5.7.17-11 一.数据库重启日志分析 terminate called after throwing an instance of 'std::out_of_range' what(): ... 本文主要通过一个bug来记录一下如何分析一个MySQL bug的崩溃信息. 版本:Percona 5.7.17-11

五大最受欢迎的BUG管理系统

Google在中国大陆遭遇变故做出临时性的退出大陆市场,也使非常多忠实的用户受到小小的挫折,以本公司为例.原本的BUG都是记录在google的 EXCEL在线文档中,由于常常性的打不开.測试和开发组在线上交流不了,都仅仅能通过其他的方式进行沟通和讨论,非常不便. 于是在測试部经理的要求下,寻 找出一些最受大家青睐的BUG管理系统.从中选择出最适合的来作为公司管理BUG的专用系统.经过认真的查找和比較,选出下面五大为比較受欢迎的BUG管理系统. 下面简介一下其功能优缺点和资源获取方式吧: 1. Q