《轉》MySQL 5.7版本新特性連載

 

MySQL 5.7版本新特性連載(一)

本文將和你們一塊兒分享下5.7的新特性,不過咱們要先從即將被刪除的特性以及建議再也不使用的特性提及。根據這些狀況,咱們在新版本及之後的版本中,應該再也不使用,避免將來產生兼容性問題。html

本文是基於MySQL-5.7.7-rc版本,將來可能 還會發生更多變化。mysql

一、即將刪除的特性
1.一、InnoDB monitoring features,詳見:WL#7377(訪問地址:http://dev.mysql.com/worklog/task/?id=7377,下面的其餘WL,能夠自行替換)
【建議】能夠動態修改 innodb_status_output、innodb_status_output_locks 兩個參數的值打印相關信息,或者直接查看INFORMATION_SCHEMA下的相關表。linux

1.二、old-password,4.1以前的就密碼認證模式已經禁用,old_passwords參數不可用,WL#8006
【建議】儘快升級舊密碼串,同時升級MySQL版本,不要告訴我,你還在用4.1甚至更早的版本。算法

1.三、部分SQL語法不可用
1.3.一、ALTER TABLE … IGNORE。
1.3.二、INSERT DELAY特性,但保留這個語法。WL#6073
1.3.三、ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, NO_ZERO_IN_DATE SQL MODES 等幾個SQL MODE合併到STRICT中。不過可能會致使replication失敗,因此還在考慮中。WL#7467
1.3.四、再也不支持YEAR(2),建議儘快升級成YEAR(4)。WL#6263
【建議】儘量使用標準SQL語法,再也不使用MySQL特有的,或者不是那麼嚴格要求的語法,避免之後版本升級遇到更多麻煩。sql

1.四、一些參數不可用
1.4.一、再也不支持一些指令的簡短寫法,必需要求寫全了,例如mysqldump –compr表示 mysqldump –compress,之後必須將整個參數寫完整。WL#6978
1.4.二、刪除timed_mutexes。WL#7436
1.4.三、不能再禁用InnoDB引擎,由於系統表也都改爲InnoDB了。WL#7976
1.4.四、性能提高有限,刪除innodb_use_sys_malloc、innodb_additional_mem_pool_size。WL#7628
1.4.五、意義不大,刪除innodb_mirrored_log_groups。WL#6808
1.4.六、已經有新的系統參數代替了,刪除innodb_file_io_threads。WL#7149
1.4.七、刪除系統參數storage_engine,改用default_storage_engine。WL#7148
1.4.八、刪除mysql_upgrade中的–basedir和–datadir系統參數。WL#7010shell

1.五、一些客戶端工具
mysqlaccess、mysql_convert_table_format、mysql_fix_extensions、mysql_find_rows.sh、mysql_setpermission、msql2mysql、mysqlbug、mysql_zap and mysql_waitpid、mysqlhotcopy將再也不使用。
【建議】沒什麼好說的,順應潮流跟上新版本吧,該放棄的就放棄,不要抱殘守缺了,這些工具也基本上都用不上的。bootstrap

下一期,咱們講講5.7中再也不建議使用的特性, 也就是將來可能會被刪除的特性。安全

 

 

 

MySQL 5.7版本新特性連載(二)

本文將和你們一塊兒分享下5.7的新特性,不過咱們要先從即將被刪除的特性以及建議再也不使用的特性提及。根據這些狀況,咱們在新版本及之後的版本中,應該再也不使用,避免將來產生兼容性問題。服務器

本文是基於MySQL-5.7.7-rc版本,將來可能 還會發生更多變化。session

二、預計取消的特性
2.一、客戶端交互協議中,EOF協議包不建議再使用了,建議改爲OK協議包。WL#7766
2.二、不建議使用SHOW PROFILE指令,或直接從INFORMATION_SCHEMA.PROFILING中查看,建議利用PERFORMANCE_SCHEMA中的幾個視圖查看。WL#6802
2.二、基於DES算法的加解密函數不建議使用, 取而代之的是用基於AES的加解密函數。WL#8126
2.四、同上,還不建議使用ENCODE()/DECODE()函數。WL#6984
2.五、採用ALTER USER來爲用戶修改密碼,不建議再使用SET PASSWORD修改密碼。WL#6409
2.六、和InnoDB相關的4個系統參數innodb_large_prefix、innodb_file_format、innodb_file_format_check、innodb_file_format_max再也不建議使用。WL#7703
2.七、再也不建議在EXPLAIN後面加上EXTENDED/PARTITIONS關鍵字。WL#7027
2.八、再也不建議使用collation_database、character_set_database系統參數。WL#2.11
2.九、再也不建議使用sync_frm系統參數。WL#8216
2.十、再也不建議使用@@session.gtid_executed系統變量。WL#7518

 

 

 

MySQL 5.7版本新特性連載(三)

本文是基於MySQL-5.7.7-rc版本,將來可能 還會發生更多變化。本節開始講5.7版本中的新特性。

一、安全性
a. 用戶表 mysql.user 的 plugin字段不容許爲空, 默認值是 mysql_native_password,而不是 mysql_old_password,再也不支持舊密碼格式;
b. 增長密碼過時機制,過時後須要修改密碼,不然可能會被禁用,或者進入沙箱模式;
c. 使用 mysql_install_db 初始化時,默認會自動生成隨機密碼,而且不建立除 root@localhost 外的其餘帳號,也不建立 test 庫;

【新特性實踐】

執行 mysql_install_db 進行新實例初始化:

[yejr@imysql.com]# ./bin/mysql_install_db --user=mysql --datadir=/data/mysql/

2015-06-24 13:55:29 [WARNING] mysql_install_db is deprecated. Please consider switching to mysqld --initialize
2015-06-24 13:55:38 [ERROR]   Child process: /opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/bin/mysqld terminated prematurely with errno= 32
2015-06-24 13:55:38 [ERROR]   Failed to execute /opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/bin/mysqld --bootstrap --datadir=/data/mysql --lc-messages-dir=/usr/share/mysql --lc-messages=en_US
-- server log begin --
mysqld: [Warning] --bootstrap is deprecated. Please consider using --initialize instead
-- server log end --

能夠看到提示 mysql_install_db 已經再也不推薦使用了,建議改爲 mysqld –initialize 完成實例初始化。

改爲 mysqld –initialize 後,若是 datadir 指向的目標目錄下已經有數據文件,則會有相似提示:

[yejr@imysql.com]#./bin/mysqld --user=mysql --basedir=/opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/ --datadir=/data/mysql --initial --initialize-insecure

2015-06-24T06:05:05.533588Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
2015-06-24T06:05:05.533627Z 0 [ERROR] Aborting

所以,須要先確保 datadir 目標目錄下是空的,避免誤操做破壞已有數據。

另外,在初始化時若是加上 –initial-insecure,則會建立空密碼的 root@localhost 帳號,不然會建立帶密碼的 root@localhost 帳號,密碼直接寫在 log-error 日誌文件中(在5.6版本中是放在 ~/.mysql_secret 文件裏,更加隱蔽,不熟悉的話可能會無所適從)

[yejr@imysql.com]#./bin/mysqld --user=mysql --basedir=/opt/17173_install/mysql-5.7.7-rc-linux-glibc2.5-x86_64/ --datadir=/data/mysql --initial

2015-06-24T06:14:31.458905Z 0 [Warning] Insecure configuration for --secure-file-priv: Current value does not restrict location of generated files. Consider setting it to a valid, non-empty path.

初始化完畢後,若是沒使用新版本的客戶端登入,還會報告相似下面的錯誤:

mysql -uroot -p
Enter password:
ERROR 1862 (HY000): Your password has expired. To log in you must change it using a client that supports expired passwords.

上面的錯誤提示意思是須要用當前版本的客戶端登入,由於新用戶登入後須要馬上修改密碼,不然沒法繼續後續的工做:

[(root@imysql.com)]>use mysql
ERROR 1820 (HY000): You must SET PASSWORD before executing this statement

[(root@imysql.com)]>set password = password('abcd');
Query OK, 0 rows affected, 1 warning (0.00 sec)

修改完密碼後,就能夠繼續使用舊版本的客戶端工具了。

 

 

MySQL 5.7版本新特性連載(四)

本文是基於MySQL-5.7.7-rc版本,將來可能 還會發生更多變化。

一、SQL MODE變化
a. 默認啓用 STRICT_TRANS_TABLES 模式;
b. 對 ONLY_FULL_GROUP_BY 模式實現了更復雜的特性支持,而且也被默認啓用;
c. 其餘被默認啓用的sql mode還有 NO_ENGINE_SUBSTITUTION;

【iMySQL建議】
對廣大MySQL使用者而言,以往不是那麼嚴格的模式仍是很方便的,在5.7版本下可能會以爲略爲不適,慢慢習慣吧。好比向一個20字符長度的VARCHAR列寫入30個字符,在之前會自動截斷並給個提示告警,而在5.7版本下,則直接拋出錯誤了。我的認爲這卻是一個好的作法,避免各類奇葩的寫法。

【新特性實踐】

-- 查看默認的 sql_mode
[yejr@imysql.com]> select @@sql_mode;
+-----------------------------------------------------------------------------------+
| @@sql_mode |
+-----------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------+

-- 插入50個字符
[yejr@imysql.com]> insert into t_char select 0, repeat('x',50);
ERROR 1406 (22001): Data too long for column 'uname' at row 1

-- 修改本 session 的 sql_mode
[yejr@imysql.com]> set sql_mode = 'ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
Query OK, 0 rows affected (0.00 sec)

-- 去掉 STRICT_TRANS_TABLES 模式後
[yejr@imysql.com]> select @@sql_mode;
+---------------------------------------------------------------+
| @@sql_mode |
+---------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------------------------------------------------------+

[yejr@imysql.com]> insert into t_char select 0, repeat('x',50);
Query OK, 1 row affected, 1 warning (0.00 sec)  -- 提示有告警信息
Records: 1 Duplicates: 0 Warnings: 1

[yejr@imysql.com]> show warnings;
+---------+------+--------------------------------------------+
| Level | Code | Message |
+---------+------+--------------------------------------------+
| Warning | 1265 | Data truncated for column 'uname' at row 1 |
+---------+------+--------------------------------------------+

由於 uname 字段的長度爲 40 個字符。

二、優化online操做,例如修改buffer pool、修改索引名(非主鍵)、修改REPLICATION FILTER、修改MASTER而無需關閉SLAVE線程 等衆多特性。

能夠在線修改buffer pool對DBA來講實在太方便了,實例運行過程當中能夠動態調整,避免事先分配不合理的狀況,不過 innodb_buffer_pool_instances 不能修改,並且在 innodb_buffer_pool_instances 大於 1 時,也不能將 buffer pool 調整到 1GB 之內,須要稍加註意。

若是是加大buffer pool,其過程大體是:

一、以innodb_buffer_pool_chunk_size爲單位,分配新的內存pages;
二、擴展buffer pool的AHI(adaptive hash index)鏈表,將新分配的pages包含進來;
三、將新分配的pages添加到free list中;

若是是縮減buffer pool,其過程則大體是:

一、重整buffer pool,準備回收pages;
二、以innodb_buffer_pool_chunk_size爲單位,釋放刪除這些pages(這個過程會有一點點耗時);
三、調整AHI鏈表,使用新的內存地址。

實際測試時,發如今線修改 buffer poo 的代價並不大,SQL命令提交完畢後都是瞬間完成,然後臺進程的耗時也並不過久。在一個併發128線程跑tpcc壓測的環境中,將 buffer pool 從32G擴展到48G,後臺線程耗時 3秒,而從 48G 縮減回 32G 則耗時 18秒,期間壓測的事務未發生任何鎖等待。

-- 演示1:從 1G 擴大到 16G
[yejr@imysql.com]> SET GLOBAL innodb_buffer_pool_size = 51539607552; 
Query OK, 0 rows affected (0.00 sec)

-- 看看日誌記錄
09:21:19.460543Z 0 [Note] InnoDB: Resizing buffer pool from 1073741824 to 17179869184. (unit=134217728)
09:21:19.468069Z 0 [Note] InnoDB: disabled adaptive hash index.
09:21:20.760724Z 0 [Note] InnoDB: buffer pool 0 : 60 chunks (491511 blocks) were added.
09:21:21.922869Z 0 [Note] InnoDB: buffer pool 1 : 60 chunks (491520 blocks) were added.
09:21:21.935114Z 0 [Note] InnoDB: buffer pool 0 : hash tables were resized.
09:21:21.947264Z 0 [Note] InnoDB: buffer pool 1 : hash tables were resized.
09:21:22.203031Z 0 [Note] InnoDB: Resized hash tables at lock_sys, adaptive hash index, dictionary.
09:21:22.203062Z 0 [Note] InnoDB: Completed to resize buffer pool from 1073741824 to 17179869184.
09:21:22.203075Z 0 [Note] InnoDB: Re-enabled adaptive hash index.

-- 演示2:從 16G 縮減到 1G
[yejr@imysql.com]> SET GLOBAL innodb_buffer_pool_size = 1073741824;
Query OK, 0 rows affected (0.00 sec)

-- 看看日誌記錄
09:22:55.591669Z 0 [Note] InnoDB: Resizing buffer pool from 17179869184 to 1073741824. (unit=134217728)
09:22:55.680836Z 0 [Note] InnoDB: disabled adaptive hash index.
09:22:55.680864Z 0 [Note] InnoDB: buffer pool 0 : start to withdraw the last 491511 blocks.
09:22:55.765778Z 0 [Note] InnoDB: buffer pool 0 : withdrew 489812 blocks from free list. Tried to relocate 1698 pages (491510/491511).
09:22:55.774492Z 0 [Note] InnoDB: buffer pool 0 : withdrew 0 blocks from free list. Tried to relocate 1 pages (491511/491511).
09:22:55.782745Z 0 [Note] InnoDB: buffer pool 0 : withdrawn target 491511 blocks.
09:22:55.782786Z 0 [Note] InnoDB: buffer pool 1 : start to withdraw the last 491520 blocks.
09:22:55.892068Z 0 [Note] InnoDB: buffer pool 1 : withdrew 489350 blocks from free list. Tried to relocate 2166 pages (491517/491520).
09:22:55.900743Z 0 [Note] InnoDB: buffer pool 1 : withdrew 0 blocks from free list. Tried to relocate 2 pages (491519/491520).
09:22:55.908257Z 0 [Note] InnoDB: buffer pool 1 : withdrew 0 blocks from free list. Tried to relocate 0 pages (491519/491520).
09:22:55.915778Z 0 [Note] InnoDB: buffer pool 1 : withdrew 0 blocks from free list. Tried to relocate 1 pages (491520/491520).
09:22:55.923836Z 0 [Note] InnoDB: buffer pool 1 : withdrawn target 491520 blocks.
09:22:56.149172Z 0 [Note] InnoDB: buffer pool 0 : 60 chunks (491511 blocks) were freed.
09:22:56.308997Z 0 [Note] InnoDB: buffer pool 1 : 60 chunks (491520 blocks) were freed.
09:22:56.316258Z 0 [Note] InnoDB: buffer pool 0 : hash tables were resized.
09:22:56.324027Z 0 [Note] InnoDB: buffer pool 1 : hash tables were resized.
09:22:56.393589Z 0 [Note] InnoDB: Resized hash tables at lock_sys, adaptive hash index, dictionary.
09:22:56.393616Z 0 [Note] InnoDB: Completed to resize buffer pool from 17179869184 to 1073741824.
09:22:56.393628Z 0 [Note] InnoDB: Re-enabled adaptive hash index.

 

再來看下在線修改非主鍵索引名,直接用 ALTER TABLE RENAME INDEX 語法便可。

【新特性實踐】

例以下面的SQL語法:

[yejr@imysql.com]> ALTER TABLE orders RENAME INDEX idx1 TO idxxx1; 

Query OK, 0 rows affected (0.11 sec)
Records: 0 Duplicates: 0 Warnings: 0

能夠看到,幾乎瞬間完成,儘管我在執行這個SQL時正跑着64個併發tpcc壓測。

 

 

 

MySQL 5.7版本新特性連載(五)

本文是基於MySQL-5.7.7-rc版本,將來可能 還會發生更多變化。

一、支持多源複製(Multi-source replication),這對採用分庫分表的同窗絕對是個超級重磅福音。能夠把多個MASTER的數據歸併到一個實例上, 有助於提升SLAVE服務器的利用率。不過若是是同一個表的話,會存在主鍵和惟一索引衝突的風險,須要提早作好規劃。

【新特性實踐】
MySQL 5.7的多源複製採用多通道的模式,例如用如下方法能夠建立多個複製通道,將多個MASTER上的數據複製到同一個SLAVE節點中去:

-- 須要先把 MASTER_INFO_REPOSITORY 和 RELAY_LOG_INFO_REPOSITORY 改爲 TABLE 模式
[yejr@imysql.com]> SET GLOBAL MASTER_INFO_REPOSITORY = "TABLE";
Query OK, 0 rows affected (0.00 sec)

[yejr@imysql.com]> SET GLOBAL RELAY_LOG_INFO_REPOSITORY = "TABLE";
Query OK, 0 rows affected (0.00 sec)

-- 建立第一個複製通道
[yejr@imysql.com]> CHANGE MASTER TO MASTER_HOST='1.2.3.4', MASTER_USER='user', MASTER_PASSWORD='repl' FOR CHANNEL 'MASTER-01';
Query OK, 0 rows affected, 2 warnings (0.00 sec)

-- 建立第二個複製通道
[yejr@imysql.com]> CHANGE MASTER TO MASTER_HOST='2.3.4.5', MASTER_USER='user', MASTER_PASSWORD='repl' FOR CHANNEL 'MASTER-02';
Query OK, 0 rows affected, 2 warnings (0.00 sec)

-- 查看第二個複製通道的狀態
[yejr@imysql.com]> SHOW SLAVE STATUS FOR CHANNEL 'MASTER-02';
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 2.3.4.5
                  Master_User: user
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: 
          Read_Master_Log_Pos: 4
               Relay_Log_File: yejr-relay-bin-master@002d02.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: 
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 0
              Relay_Log_Space: 154
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 0
                  Master_UUID: 
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: 
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: f0df162a-1a39-11e5-883a-782bcb65f419:1-11025782
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: master-02
1 row in set (0.00 sec)

其餘和複製相關的SQL指令和以往也基本同樣,只需在加上 FOR CHANNEL ‘CHANNEL-NAME’ 子句便可。

此外,還支持在線修改replication filter規則,不過不是太建議使用filter規則,所以不重點介紹了。執行下面的SQL命令能夠完成filter規則修改:

[yejr@imysql.com]> CHANGE REPLICATION FILTER
 REPLICATE_DO_DB = (d1), REPLICATE_IGNORE_DB = (d2);

 

二、支持多線程複製(Multi-Threaded Slaves, 簡稱MTS),在5.6版本中實現了SCHEMA級別的並行複製,不過意義不大,由於咱們線上大部分實例的讀寫壓力基本集中在某幾個數據表,基本無助於緩解複製延遲問題。卻是MariaDB的多線程並行複製大放異彩,有很多人由於這個特性選擇MariaDB(好比我也是其一,呵呵)。

MySQL 5.7 MTS支持兩種模式,一種是和5.6同樣,另外一種則是基於binlog group commit實現的多線程複製,也就是MASTER上同時提交的binlog在SLAVE端也能夠同時被apply,實現並行複製。關於MTS的更多詳細介紹能夠查看姜承堯的分享 MySQL 5.7 並行複製實現原理與調優,我這裏就不重複說了。

值得一提的是,通過對比測試,5.7採用新的並行複製後,仍然會存在必定程度的延遲,只不過相比5.6版本減小了86%,相比MariaDB的並行複製延遲也小很多。

 

 

MySQL 5.7版本新特性連載(六)

本文是基於MySQL-5.7.7-rc版本,將來可能 還會發生更多變化。

  1. 自動判斷底層I/O設備是否能夠支持原子IO(AIO),檢測到的話,會自動關閉 double write buffer,進一步提高性能。
  2. 支持 innodb_page_cleaners 選項可設置多個page cleaner線程提升髒頁刷新效率。
  3. 可經過設置 innodb_undo_log_truncate 等選項自動刪除不用的 undo log。
  4. 增強InnoDB read-only模式的性能。
  5. 支持一個表上有多個觸發器,這樣一來,原先已有觸發器表也能夠支持用 pt-osc 了。
  6. 新增 log_syslog 選項,可將MySQL日誌打印到系統日誌文件中。
  7. InnoDB和MyISAM引擎的分區表也支持ICP特性。
  8. 支持對在線某個鏈接直接查看執行計劃,好比 EXPLAIN FOR CONNECTION 1024
  9. 支持在線(INPLACE)增長 VARCHAR 列的長度。不過 0-255 長度是一個區間,256 以上是另外一個區間,不能跨越255這個坎,好比把長度從 100 擴展成 1000(由於 255 長度之內額外用1個字節表示,大於 255 長度則須要額外2個字節表示)。另外還不支持在線縮小 VARCHAR 的長度。
  10. 以及更多關於性能上的改善提高,包括客戶端鏈接效率提高批量數據加載效率提高sort buffer中存儲的非排序字段是壓縮模式的(提升內存利用率)、UNION ALL再也不產生臨時表解析器重構、查詢優化器進一步完善(好比增長可控CBO規則)等等。

 

 

 以上內容出自http://imysql.com,感受葉老師的分享!

相關的參考資料:http://mp.weixin.qq.com/s?__biz=MjM5MjIxNDA4NA==&mid=205236417&idx=1&sn=15281c834348911cea106478aa819175&3rd=MzA3MDU4NTYzMw==&scene=6#rd

                      http://dev.mysql.com/doc/refman/5.7/en/mysql-nutshell.html#mysql-nutshell-removals

相關文章
相關標籤/搜索