Mysql Errors

1 ERROR 1044

1.1 42000

錯誤信息css

MariaDB [mysql]>  grant select on information_schema.* to 'test'@'%';
ERROR 1044 (42000): Access denied for user 'root'@'localhost' to database 'information_schema'

緣由html

information_schema是一個視圖庫，裏面全部對象都是以視圖的形式存在的,並且是在實例啓動時自動加載和建立的。 Mariadb 不容許對該庫進行任何的操做。java
解決python

對於information_schema庫的問題，咱們能夠針對其源表進行受權。informat_schema庫的源表是 mysql庫。只要讓test用戶擁有查詢mysql庫的權限,天然就能夠查詢information_schema庫了。mysql
```
grant select on mysql.* to 'test'@'%';
```

2 ERROR 1045

2.1 28000

2.1.1 無登陸權限

錯誤信息sql
```
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
```
在有些狀況下，mysql 使用root 用戶登陸時，會出現這種狀況。具體緣由不明。咱不會讀源碼, 否則這個問題必定給它搞清楚。蛋疼。shell

解決方法 解決這個問題的方法,不一樣的版本中操做方法也不同。主要是經過修改mysql.user 中保存的密碼 , 可是不一樣的版本還會有些小的區別,早期版本，只要更新mysql.user表就能夠,可是mysql 5.6 / 5.7，除了手動更新mysql.user，還要另外執行一個操做。下面是主要操做流程：數據庫

# 修改參數實現免認證登陸數據庫
將/etc/my.cnf 中的[mysqld] 下面加上一行skip-grant-tables,保存退出編譯文件。

# 重啓mysql，不一樣版本的操做系統中命令不同,此處以CentOS 7 爲例
systemctl restart mysqld

# 手動更新mysql.user.authentication_string 或者 mysql.user.password 字段
update mysql.user set authentication_string=password('您的密碼') where user='root';
flush privileges;

# 5.5 以前的版本中，到這一步，再重啓Mysql,就能夠了。可是5.六、5.7之後還要額外操做:
# 關閉mysql
systemctl stop mysqld

# 取消免密登陸，修改/etc/my.cnf 將skip-grant-tables 參數註釋或者刪除。

# 編譯文件initfile.txt,在文件中添加以下一句SQL:
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('密碼');

# 啓動mysql 指定--init-file參數,參數值即在上一步中編譯的文件名,在啓動時執行腳本中的命令
# 若是不經過這種方式，仍會遇到錯誤。
mysqld --init-file=initfile.txt

# 重啓mysql
systemctl restart mysqld

2.1.2 無文件訪問權限

錯誤信息

MySQL [ypsx_order0]> select * into outfile '/tmp/a.xls' from order0;
ERROR 1045 (28000): Access denied for user 'order_read'@'%' (using password: YES)

當將一張表中的數據經過 select outfile 方式將數據備份至文件系統時出現。sass

分析緣由

其實這個問題也並無跳出圈外。仍舊是權限問題，只不過是是否有訪問文件的權限。 Mysql.user表中列出了一個用戶所能夠擁有的全部權限，其中包含一個 File_Priv 字段，這個字段表明用戶是否有寫文件的權限。只有擁有這個權限，纔有可能進行下一步–> 寫文件，固然寫文件前還要判斷Mysql用戶是否有文件路徑有寫權限等。ruby

解決方法

update mysql.user set File_priv=’Y’ where user=’xxxx’;

3 ERROR 1055

錯誤信息

[Err] 1055 - Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column
'information_schema.PROFILING.SEQ' which is not functionally dependent on columns in GROUP BY clause;
this is incompatible with sql_mode=only_full_group_by

緣由分析
Mysql 中的SQL 語法並是嚴格按照SQL 95 標準的。在聚合操做時，group by 容許不包含全部select的非聚合列. mysql 提供了一個參數可使SQL 嚴格按照SQL 95標準編寫，可是同時此參數是存在缺陷的。一些delete 等非聚合操做，從java 客戶端發起時，有可能會引發錯誤：[err] 1055.

解決方案
簡單的解決方案就是取消此參數設置。參數的設置方法以下:

# 臨時調整
set @@sql_mode='參數列表,以逗號分隔'
或者
set global sql_mode='參數列表,以逗號分隔'
# 永久調整  修改參數配置文件my.cnf
sql_mode = '參數列表，不一樣參數之間以逗號分隔'

操做示例
在Mysql 裏大部分的參數是分爲全局和會話級別，全局分爲臨時與永久。通常臨時調整就是經過set 命令調整。全局調整，須要在參數文件中修改，通常爲/etc/my.cnf

臨時修改示例

mysql> set global sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
Query OK, 0 rows affected (0.00 sec)
mysql> exit
Bye
[root@test ~]# mysql -D
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1814164
Server version: 5.7.17 MySQL Community Server (GPL)

Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select @@sql_mode;
+------------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                             |
+------------------------------------------------------------------------------------------------------------------------+
| STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

永久修改示例

# 修改以前
sql_mode='ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
# 修改以後
sql_mode='NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'

4 ERROR 1201

error code:ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log

Reason:

  出現這個問題的緣由是以前曾作過主從複製!須要reset slave後再change

Solve:
```
reset slave;
```

5 ERROR 1292

5.1 22007

錯誤信息

ERROR 1292 (22007): Truncated incorrect DOUBLE value: ''

分析

該錯誤是因爲 MySQL 對字符值是否符合字段要求進行了嚴格的檢查，可是有時候，這個檢查的結果倒是錯誤的。就像下面示例：

MariaDB [(none)]> update test.test set status=NULL where status=6;

ERROR 1292 (22007): Truncated incorrect DOUBLE value: ''

MariaDB [(none)]> desc test.test;
+---------------------+--------------+------+-----+---------+----------------+
| Field               | Type         | Null | Key | Default | Extra          |
+---------------------+--------------+------+-----+---------+----------------+
| id                  | bigint(20)   | NO   | PRI | NULL    | auto_increment |
| status              | varchar(30)  | YES  |     | NULL    |                |
+---------------------+--------------+------+-----+---------+----------------+
2 rows in set (0.02 sec)

從上面的查詢結果來看，status 字段容許爲空, 默認爲空。我將該字段值更新爲空字段並沒有違反該字段的約束條件。可是，錯誤就是麼離奇的發生了。明明沒有問題，卻提示爲錯誤數據。

查看SQL_MODE

  MariaDB [(none)]> show variables like 'sql_mode';
+---------------+-------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                     |
+---------------+-------------------------------------------------------------------------------------------+
| sql_mode      | STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+-------------------------------------------------------------------------------------------+

解決主要是把sql_mode中的strict_trans_tables去掉便可。

set [global | session] variables sql_mode = 'ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

6 ERROR 1293

6.1 HY000

6.1.1 錯誤信息

ERROR 1293 (HY000) at line 35: Incorrect table definition; there can be only one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause

6.1.2 緣由

MySQL功能上的缺陷,不容許同一張表中的多個timestamp字段同時具備 on update current_timestamp() 的功能，建表語句中只有第一個timestamp字段能夠有這種屬性，後面的不能夠。在5.5及以前的版本中都有這樣的限制。5.6.5 之後取消了這種限制並擴展到了datetime類型字段上。官方文檔中有以下描述

MySQL 5.5

One TIMESTAMP column in a table can have the current timestamp as the default value for initializing the column, as the auto-update value, or both. It is not possible to have the current timestamp be the default value for one column and the auto-update value for another column.

MySQL 5.6.5

Previously, at most one TIMESTAMP column per table could be automatically initialized or updated to the current date and time. This restriction has been lifted. Any TIMESTAMP column definition can have any combination of DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP clauses. In addition, these clauses now can be used with DATETIME column definitions. For more information, see Automatic Initialization and Updating for TIMESTAMP and DATETIME.

6.1.3 解決方法

升級mysql 到 5.6.5 及以上版本。
修改建表語句，只保留第一個timestamp字段使用current_timestamp()。

7 ERROR 1548

錯誤信息:

Cannot load from mysql.proc. The table is probably corrupted.

內部表結構不對。須要升級更新:

mysql_upgrade -uroot -p

8 ERROR 1872

8.1 錯誤信息

ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

8.2 分析緣由

配置了參數 log_slave_updates . 配置此參數後，數據庫相應的須要生成中繼日誌，若是沒有配置，則不會生成，也就是說，log_slave_updates 依賴於relay_log。
所以，在這種狀況下，要求 配置relay_log 參數
master.info 文件中的信息有誤
slave 信息變更 slave 信息發生變更，使用reset slave. 可是內存中的信息沒有被清空。要清空內存與配置中的信息，須要執行reset slave all;
…. 未知.

9 ERROR 2003

error code:ERROR 2003 (HY000): Can't connect to MySQL server on 'ip_address' (111)
Reason:

10 ERROR 2013

10.1 錯誤提示

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `xxxxx` at row: 7114978

10.2 緣由1

緣由

mysqldump來不及接受mysql server端發送過來的數據，Server端的數據就會積壓在內存中等待發送，
這個等待不是無限期的，當Server的等待時間超過net_write_timeout（默認是60秒）時它就失去了耐心，
mysqldump的鏈接會被斷開，同時拋出錯誤Got error: 2013: Lost connection.

增長net_write_timeout能夠解決上述的問題的。在實踐中發現，在增大 net_write_timeout後，
Server端會消耗更多的內存，有時甚至會致使swap的使用（並不肯定是否是修改 net_write_timeout所至）。
建議在mysqldump以前修改net_write_timeout爲一個較大的值（如1800），在 mysqldump結束後，
在將這個值修改到默認的60。

解決方法

在sql命令行裏面設置臨時全局生效用相似以下命令：
SET GLOBAL net_write_timeout=1800;

10.3 緣由2

緣由
因爲MySQL沒法解析ip地址，而報出的錯誤:
解決方法
在參數配置文件(默認爲/etc/my.cnf) 中[mysqld] 下添加 skip-name-resove . 重啓 MySQL便可。

Mysql Errors

Mysql Errors

Table of Contents

1 ERROR 1044

1.1 42000

2 ERROR 1045

2.1 28000

2.1.1 無登陸權限

2.1.2 無文件訪問權限

3 ERROR 1055

4 ERROR 1201

5 ERROR 1292

5.1 22007

6 ERROR 1293

6.1 HY000

6.1.1 錯誤信息

6.1.2 緣由

6.1.3 解決方法

7 ERROR 1548

8 ERROR 1872

8.1 錯誤信息

8.2 分析緣由

9 ERROR 2003

10 ERROR 2013

10.1 錯誤提示

10.2 緣由1

10.3 緣由2