日常使用mysql數據庫遇到的一些問題，做下記錄，會持續更新。
一、MySql Host is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts' 解決方法
環境：linux，mysql5.6
錯誤：Host is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'
原因：
同一個ip在短時間內產生太多（超過mysql數據庫max_connect_errors的最大值）中斷的數據庫連接而導致的阻塞；默認max_connect_errors是10
解決方法：
1、提高允許的max_connection_errors數量（治標不治本）：
① 進入Mysql數據庫查看max_connect_errors： show variables like '%max_connection_errors%';
② 修改max_connection_errors的數量為1000： set global max_connect_errors = 1000;
③ 查看是否修改成功：show variables like '%max_connection_errors%';
2、使用mysqladmin flush-hosts 命令清理一下hosts文件（不知道mysqladmin在哪個目錄下可以使用命令查找：whereis mysqladmin）；
① 在查找到的目錄下使用命令修改：/usr/bin/mysqladmin flush-hosts -h192.168.1.1 -P3306 -uroot -prootpwd;
注意：
其中端口號，用戶名，密碼都可以根據需要來添加和修改；
配置有master/slave主從數據庫的要把主庫和從庫都修改一遍的；
第二步也可以在數據庫中進行，命令如下：flush hosts;
150422 14:10:01 [Warning] IP address '172.17.1.69' could not be resolved: Name or service not known 150422 14:10:01 [Warning] IP address '192.168.120.1' could not be resolved: Name or service not known 150422 14:10:02 [Warning] IP address '192.168.80.1' could not be resolved: Name or service not known
mysql> set global skip_name_resolve=ON; mysql> show variables like '%skip%'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | skip_external_locking | ON | | skip_name_resolve | ON | | skip_networking | OFF | | skip_show_database | OFF | | slave_skip_errors | OFF | | sql_slave_skip_counter | 0 | +------------------------+-------+ 6 rows in set (0.00 sec)
設置好變量值后，flush hosts;生效
mysql>flush hosts;
二、sql_mode=only_full_group_by問題，this is incompatible with sql_mode=only_full_group_by錯誤
錯誤：
在使用MySQL命令行進行分組時報錯：
ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'database_tl.emp.id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
原因：
看一下group by的語法：
select 選取分組中的列+聚合函數 from 表名稱 group by 分組的列
從語法格式來看，是先有分組，再確定檢索的列，檢索的列只能在參加分組的列中選。
解決：
查看mysql版本命令：select version();
查看sql_model參數命令：
SELECT @@GLOBAL.sql_mode;
SELECT @@SESSION.sql_mode;
發現：
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
第一項默認開啟ONLY_FULL_GROUP_BY，
解決方法：
1.只選擇出現在group by后面的列，或者給列增加聚合函數；
2.命令行輸入：
set sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'; 如果上面設置完成后依然報錯，這里執行下面的SQL，將全局設置更改，然后必須關閉現有的連接，重新打開連接后查詢即可 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';
默認關掉ONLY_FULL_GROUP_BY！
3.直接運行下面的設置命令（我最常用的方式）
將ONLY_FULL_GROUP_BY設置為空
SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));
更改完之后可以查看sql_mode：
SELECT @@GLOBAL.sql_mode; SELECT @@SESSION.sql_mode;
注意：
這點在數據庫服務進行遷移時尤其要注意，遷移后的數據庫如果忘記設置會報錯。
三、開啟binlog后異常：impossible to write to binary log since BINLOG_FORMAT = STATEMENT
{ [Error: ER_BINLOG_STMT_MODE_AND_ROW_ENGINE: Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.]
code: 'ER_BINLOG_STMT_MODE_AND_ROW_ENGINE',
errno: 1665,
sqlState: 'HY000',
index: 0 }
原因：
mysql默認的binlog_format是STATEMENT。
從 MySQL 5.1.12 開始，可以用以下三種模式來實現：基於SQL語句的復制(statement-based replication, SBR)，基於行的復制(row-based replication, RBR)，混合模式復制(mixed-based replication, MBR)。相應地，binlog的格式也有三種：STATEMENT，ROW，MIXED。
如果你采用默認隔離級別REPEATABLE-READ，那么建議binlog_format=ROW。如果你是READ-COMMITTED隔離級別，binlog_format=MIXED和binlog_format=ROW效果是一樣的，binlog記錄的格式都是ROW，對主從復制來說是很安全的參數。
解決：
mysql> SET SESSION binlog_format = 'ROW'; mysql> SET GLOBAL binlog_format = 'ROW';
注意： 若手動修改linux下面/etc/my.cnf : binlog_format = row , 需要重啟mysql，且是永久生效。
相關文檔參考：
MySQL binlog_format (Mixed,Statement,Row) MySQL 5.5 中對於二進制日志 (binlog) 有 3 種不同的格式可選：Mixed,Statement,Row，默認格式是 Statement。總結一下這三種格式日志的優缺點。 MySQL Replication 復制可以是基於一條語句 (Statement Level) ，也可以是基於一條記錄 (Row Level)，可以在 MySQL 的配置參數中設定這個復制級別，不同復制級別的設置會影響到 Master 端的 bin-log 日志格式。 1. Row 日志中會記錄成每一行數據被修改的形式，然后在 slave 端再對相同的數據進行修改。 優點：在 row 模式下，bin-log 中可以不記錄執行的 SQL 語句的上下文相關的信息，僅僅只需要記錄那一條記錄被修改了，修改成什么樣了。所以 row 的日志內容會非常清楚的記錄下每一行數據修改的細節，非常容易理解。而且不會出現某些特定情況下的存儲過程或 function ，以及 trigger 的調用和觸發無法被正確復制的問題。 缺點：在 row 模式下，所有的執行的語句當記錄到日志中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日志內容，比如有這樣一條 update 語句： 執行之后，日志中記錄的不是這條 update 語句所對應的事件 (MySQL 以事件的形式來記錄 bin-log 日志) ，而是這條語句所更新的每一條記錄的變化情況，這樣就記錄成很多條記錄被更新的很多個事件。自然，bin-log 日志的量就會很大。尤其是當執行 alter table 之類的語句的時候，產生的日志量是驚人的。因為 MySQL 對於 alter table 之類的表結構變更語句的處理方式是整個表的每一條記錄都需要變動，實際上就是重建了整個表。那么該表的每一條記錄都會被記錄到日志中。 2. Statement 每一條會修改數據的 SQL 都會記錄到 master 的 bin-log 中。slave 在復制的時候 SQL 進程會解析成和原來 master 端執行過的相同的 SQL 再次執行。 優點：在 statement 模式下，首先就是解決了 row 模式的缺點，不需要記錄每一行數據的變化，減少了 bin-log 日志量，節省 I/O 以及存儲資源，提高性能。因為他只需要記錄在 master 上所執行的語句的細節，以及執行語句時候的上下文的信息。 缺點：在 statement 模式下，由於他是記錄的執行語句，所以，為了讓這些語句在 slave 端也能正確執行，那么他還必須記錄每條語句在執行的時候的一些相關信息，也就是上下文信息，以保證所有語句在 slave 端杯執行的時候能夠得到和在 master 端執行時候相同的結果。另外就是，由於 MySQL 現在發展比較快，很多的新功能不斷的加入，使 MySQL 的復制遇到了不小的挑戰，自然復制的時候涉及到越復雜的內容，bug 也就越容易出現。在 statement 中，目前已經發現的就有不少情況會造成 MySQL 的復制出現問題，主要是修改數據的時候使用了某些特定的函數或者功能的時候會出現，比如：sleep() 函數在有些版本中就不能被正確復制，在存儲過程中使用了 last_insert_id() 函數，可能會使 slave 和 master 上得到不一致的 id 等等。由於 row 是基於每一行來記錄的變化，所以不會出現類似的問題。 3. Mixed 從官方文檔中看到，之前的 MySQL 一直都只有基於 statement 的復制模式，直到 5.1.5 版本的 MySQL 才開始支持 row 復制。從 5.0 開始，MySQL 的復制已經解決了大量老版本中出現的無法正確復制的問題。但是由於存儲過程的出現，給 MySQL Replication 又帶來了更大的新挑戰。另外，看到官方文檔說，從 5.1.8 版本開始，MySQL 提供了除 Statement 和 Row 之外的第三種復制模式：Mixed，實際上就是前兩種模式的結合。在 Mixed 模式下，MySQL 會根據執行的每一條具體的 SQL 語句來區分對待記錄的日志形式，也就是在 statement 和 row 之間選擇一種。新版本中的 statment 還是和以前一樣，僅僅記錄執行的語句。而新版本的 MySQL 中對 row 模式也被做了優化，並不是所有的修改都會以 row 模式來記錄，比如遇到表結構變更的時候就會以 statement 模式來記錄，如果 SQL 語句確實就是 update 或者 delete 等修改數據的語句，那么還是會記錄所有行的變更。 其他參考信息 除以下幾種情況外，在運行時可以動態改變 binlog 的格式： . 存儲流程或者觸發器中間； . 啟用了 NDB； . 當前會話使用 row 模式，並且已打開了臨時表； 如果 binlog 采用了 Mixed 模式，那么在以下幾種情況下會自動將 binlog 的模式由 statement 模式變為 row 模式： . 當 DML 語句更新一個 NDB 表時； . 當函數中包含 UUID() 時； . 2 個及以上包含 AUTO_INCREMENT 字段的表被更新時； . 執行 INSERT DELAYED 語句時； . 用 UDF 時； . 視圖中必須要求運用 row 時，例如建立視圖時使用了 UUID() 函數； 設定主從復制模式： 也可以在運行時動態修改 binlog 的格式。例如： 兩種模式的對比： Statement 優點 歷史悠久，技術成熟； 產生的 binlog 文件較小； binlog 中包含了所有數據庫修改信息，可以據此來審核數據庫的安全等情況； binlog 可以用於實時的還原，而不僅僅用於復制； 主從版本可以不一樣，從服務器版本可以比主服務器版本高； Statement 缺點： 不是所有的 UPDATE 語句都能被復制，尤其是包含不確定操作的時候； 調用具有不確定因素的 UDF 時復制也可能出現問題； 運用以下函數的語句也不能被復制： * LOAD_FILE() * UUID() * USER() * FOUND_ROWS() * SYSDATE() (除非啟動時啟用了 –sysdate-is-now 選項) INSERT … SELECT 會產生比 RBR 更多的行級鎖； 復制須要執行全表掃描 (WHERE 語句中沒有運用到索引) 的 UPDATE 時，須要比 row 請求更多的行級鎖； 對於有 AUTO_INCREMENT 字段的 InnoDB 表而言，INSERT 語句會阻塞其他 INSERT 語句； 對於一些復雜的語句，在從服務器上的耗資源情況會更嚴重，而 row 模式下，只會對那個發生變化的記錄產生影響； 存儲函數(不是存儲流程 )在被調用的同時也會執行一次 NOW() 函數，這個可以說是壞事也可能是好事； 確定了的 UDF 也須要在從服務器上執行； 數據表必須幾乎和主服務器保持一致才行，否則可能會導致復制出錯； 執行復雜語句如果出錯的話，會消耗更多資源； Row 優點 任何情況都可以被復制，這對復制來說是最安全可靠的； 和其他大多數數據庫系統的復制技能一樣； 多數情況下，從服務器上的表如果有主鍵的話，復制就會快了很多； 復制以下幾種語句時的行鎖更少： * INSERT … SELECT * 包含 AUTO_INCREMENT 字段的 INSERT * 沒有附帶條件或者並沒有修改很多記錄的 UPDATE 或 DELETE 語句 執行 INSERT，UPDATE，DELETE 語句時鎖更少； 從服務器上采用多線程來執行復制成為可能； Row 缺點 生成的 binlog 日志體積大了很多； 復雜的回滾時 binlog 中會包含大量的數據； 主服務器上執行 UPDATE 語句時，所有發生變化的記錄都會寫到 binlog 中，而 statement 只會寫一次，這會導致頻繁發生 binlog 的寫並發請求； UDF 產生的大 BLOB 值會導致復制變慢； 不能從 binlog 中看到都復制了寫什么語句(加密過的)； 當在非事務表上執行一段堆積的 SQL 語句時，最好采用 statement 模式，否則很容易導致主從服務器的數據不一致情況發生； 另外，針對系統庫 MySQL 里面的表發生變化時的處理准則如下： 如果是采用 INSERT，UPDATE，DELETE 直接操作表的情況，則日志格式根據 binlog_format 的設定而記錄； 如果是采用 GRANT，REVOKE，SET PASSWORD 等管理語句來做的話，那么無論如何都要使用 statement 模式記錄； 使用 statement 模式后，能處理很多原先出現的主鍵重復問題；
四、mysql創建新記錄時，id步增為2解釋
這不算個bug，但是step為2感覺浪費id，呵呵～
查看auto_increment變量：
mysql> show variables like '%auto_inc%'; +------------------------------+-------+ | Variable_name | Value | +------------------------------+-------+ | auto_increment_increment | 2 | | auto_increment_offset | 2 | | wsrep_auto_increment_control | ON | +------------------------------+-------+ 3 rows in set (0.01 sec) mysql>
# 查看session變量 mysql> show session variables like '%auto_inc%'; +------------------------------+-------+ | Variable_name | Value | +------------------------------+-------+ | auto_increment_increment | 2 | | auto_increment_offset | 2 | | wsrep_auto_increment_control | ON | +------------------------------+-------+ 3 rows in set (0.01 sec) #查看全局變量 mysql> show global variables like '%auto_inc%'; +------------------------------+-------+ | Variable_name | Value | +------------------------------+-------+ | auto_increment_increment | 2 | | auto_increment_offset | 2 | | wsrep_auto_increment_control | ON | +------------------------------+-------+ 3 rows in set (0.00 sec)
可以看到auto_increment_increment的step是2，可以如下設置成1
#這兩種方法等價，mysql重啟可能不生效 SET @auto_increment_increment = 1 ; SET session auto_increment_increment=1; #修改全局 SET global auto_increment_increment=1;
那么什么時候會設置offset為2呢？
- auto_increment_offset表示自增長字段從那個數開始，他的取值范圍是1 .. 65535
- auto_increment_increment表示自增長字段每次遞增的量，其默認值是1，取值范圍是1 .. 65535
五、mysql binlog無法自動刪除導致磁盤滿程序掛掉
最開始機器上的程序一並掛掉，以為是由於重啟機器引起的，但是du -sh *發現系統盤大小使用率為100%，原來是磁盤空間不夠了。du -sh *逐個從根目錄往下查找，發現是/data/mysql/占了18個G
原來是mysql-binlog占用很大空間，刪除幾個程序恢復運行了。
解決方法：
當開啟mysql數據庫主從時，會產生大量如mysql-bin.00000* log的文件，這會大量耗費您的硬盤空間。
在/etc/my.cnf中設置expire_logs_days，默認為0，即不清理binlog
1.查看binlog過期時間：
show global variables like 'expire_logs_days'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | expire_logs_days | 0 | +------------------+-------+ 1 row in set (0.01 sec)
2.查看binlog最大值設置，大小為512M。
show variables like 'max_binlog_size'; +-----------------+-----------+ | Variable_name | Value | +-----------------+-----------+ | max_binlog_size | 536870912 | +-----------------+-----------+ 1 row in set (0.00 sec)
3.查看binlog文件
show binary logs; +------------------+------------+ | Log_name | File_size | +------------------+------------+ | mysql-bin.000004 | 536872787 | | mysql-bin.000005 | 536873559 | | mysql-bin.000006 | 536872037 | | mysql-bin.000007 | 536871022 | ....
sql的binlog自動刪除發生在：
1.手工執行flush logs;
2.binlog文件大小超過max_binlog_size的設置大小;
3.重啟mysql
手工刪除binlog方法：
方法一：
purge binary logs to 'binlog.000058'; ----（刪除mysql bin-log日志，刪除binlog.000058之前的，不包括binlog.000058）
方法二：
PURGE binary LOGS BEFORE '2008-06-22 13:00:00'; //清除2008-06-22 13:00:00前binlog日志
PURGE binary LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY); //清除3天前binlog日志BEFORE，變量的date自變量可以為'YYYY-MM-DD hh:mm:ss'格式。
六、failed with error number 1065 Query was empty SQL
待更新..
參考：
https://blog.csdn.net/zengxuewen2045/article/details/52995916