繼上一期月報，MySQL5.7新特性之一介紹了一些新特性及兼容性問題后，本期繼續進行學習。 ### 1\. 系統變量 5.7以后System and status 變量需要從performance_schema中進行獲取，information_schema仍然保留了GLOBAL_STATUS，GLOBAL_VARIABLES兩個表做兼容。 [兼容性]? 如果希望沿用information_schema中進行查詢的習慣，5.7提供了show_compatibility_56參數，設置為ON可以兼容5.7之前的用法，否則就會報錯： ~~~ ERROR 3167 (HY000): The 'INFORMATION_SCHEMA.GLOBAL_STATUS' feature is disabled; see the documentation for 'show_compatibility_56' ~~~ 5.7.6之后，在performance_schema新增了如下的表： ~~~ performance_schema.global_variables performance_schema.session_variables performance_schema.variables_by_thread performance_schema.global_status performance_schema.session_status performance_schema.status_by_thread performance_schema.status_by_account performance_schema.status_by_host performance_schema.status_by_user ~~~ 5.7.9之前，需要有SELECT_ACL權限才能進行show查詢，但5.7.9之后，默認這些表是不需要任何權限就可以訪問了。 ### 2\. sys schema 新增了sys數據庫，主要是performance_schema收集的信息，幫助DBA和開發人員方便診斷問題。 sys下的一共包括三種對象：1\. view，2\. procedure 3 function 這些對象都是基于performance_schema下的表，進行了可讀性的聚合，沒有真正存儲數據，只存儲了定義。 [兼容性]? mysql_install_db可以選擇–skip-sys-schema跳過安裝過程， 但默認mysql_upgrade會幫你創建sys下面的對象。不存在兼容性的問題 ### 3\. 異常棧 5.7開始支持異常診斷棧信息，通過GET STACKED DIAGNOSTICS可以獲取棧內的信息。 具體的使用方法參考：https://dev.mysql.com/doc/refman/5.7/en/diagnostics-area.html ### 4\. Triggers 支持在一個table對象上建多個trigger。 ### 5\. Generated Columns 5.7.6開始，支持生成列，這個列可以是虛擬的列，也可以是實體存儲數據的列。 比如： ~~~ CREATE TABLE triangle ( sidea DOUBLE, sideb DOUBLE, sidec DOUBLE AS (SQRT(sidea * sidea + sideb * sideb)) ); ~~~ VIRTUAL： 表示這個字段是虛擬列，并不進行存儲，查詢的時候，通過計算得到? STORED： 需要存儲空間，并且可以被索引的列 ### 6\. exchange partition不驗證 這個是在oracle分區表上支持的功能，dba在做大表維護的時候，非常有用。 ~~~ 語法： ALTER TABLE ... EXCHANGE PARTITION WITHOUT VALIDATION ~~~ 如果不驗證，那么只有元數據信息的更改，就可以完成exchange，否則，就需要讀取每一行數據進行驗證，維護時間將根據這個表大小有關系。 ### 7\. dump線程增強 5.7.2之前，master dump線程需要持有LOCK_log鎖去讀取binlog然后發送到備庫，而這時會阻塞client端去寫入binlog。5.7.2之后，dump線程只需要持有LOCK_binlog_end_pos這個鎖去讀取binlog的當前的位置，來決定是否發送到備庫去，這樣就可以做到不阻塞任何binlog的寫入。 ### 8\. 多源復制 多源復制可以從多個master復制到一個slave端，在數據庫集群進行擴容和縮容的時候，非常有用。我們會在后面的系列單獨來介紹。 ### 9\. 在線更改replication master 可以不用stop slave，然后在線更改replication master信息。 但這里并不是不需要slave停掉， 而是change master涉及到幾個動作： 1\. 如果只是更改當前relay的信息，那么只需要sql線程是不工作的就可以了，IO thread可以繼續 2\. 如果只是更改主庫的信息，那么只需要IO線程不工作就可以了。 sql thread可以繼續 3\. 如果需要重新啟動主庫和備庫的恢復信息，比如master_auto_positioin=1，那么就需要IO和sql線程都停掉。 ### 10\. Group Replication 并行復制支持按照主庫組提交的形式在備庫進行回放。下一個系列進行單獨來介紹 下面單獨介紹一下MySQL 5.7對臨時表進行的改動。 ### 1\. 背景 MySQL包括兩類臨時表，一類是通過create temporary table創建的臨時表，一類是在query過程中using temporary而創建的臨時表。 5.7之前，using temporary創建的臨時表，默認只能使用myisam引擎，而在5.7之后，可以選擇InnoDB引擎來創建。 臨時表的引擎選擇使用下面的這兩個參數來決定： ~~~ mysql> show global variables like '%tmp%'; +----------------------------------+---------------------------------------+ | Variable_name | Value | +----------------------------------+---------------------------------------+ | default_tmp_storage_engine | InnoDB | | internal_tmp_disk_storage_engine | InnoDB | ~~~ ### 2\. 臨時表空間 5.7之后，使用了獨立的臨時表空間來存儲臨時表數據，但不能是壓縮表。臨時表空間在實例啟動的時候進行創建，shutdown的時候進行刪除。 例如如下的配置： ~~~ mysql> show global variables like '%innodb_temp%'; +----------------------------+-----------------------+ | Variable_name | Value | +----------------------------+-----------------------+ | innodb_temp_data_file_path | ibtmp1:12M:autoextend | +----------------------------+-----------------------+ ~~~ create temporary table和using temporary table將共用這個臨時表空間。 ### 3\. 臨時表優化 臨時表會伴隨著大量的數據寫入和讀取，尤其是internal_tmp_table。所以，InnoDB專門對臨時表進行了優化。? InnoDB使用如下兩個標示臨時表： ~~~ dict_tf2_temporary： 表示普通臨時表 dict_tf2_intrinsic： 表示內部臨時表 ~~~ 這兩個標示，會在IBD文件的segment header占用兩個bit位。intrinsic一定是temproary，也就是temproary上進行的優化 完全適用于intrinsic表上。 下面來看下具體的優化： ### 3.1\. redo 臨時表在連接斷開或者數據庫實例關閉的時候，會進行刪除，所以，臨時表的數據不需要redo來保護，即recovery的過程中 不恢復臨時表，只有臨時表的metadata使用了redo保護，保護元數據的完整性，以便異常啟動后進行清理工作。 臨時表的元數據，5.7之后，使用了一個獨立的表進行保存，這樣就不要使用redo保護，元數據也只保存在內存中。 但這有一個前提，必須使用共享的臨時表空間，如果使用file-per-table，仍然需要持久化元數據，以便異常恢復清理。 ### 3.2 undo temporary table仍然需要語句級的回滾，所以，需要為數據生成undo。但intrinsic table不需要回滾，所以，intrinsic table 減少了undo的生成，性能更高。 ### 3.3 lock 因為臨時表只有本線程可以看見，所以減少了InnoDB的加鎖過程。 可以看下insert的時候，進行的分支判斷： ~~~ row_insert_for_mysql( const byte* mysql_rec, row_prebuilt_t* prebuilt) { /* For intrinsic tables there a lot of restrictions that can be relaxed including locking of table, transaction handling, etc. Use direct cursor interface for inserting to intrinsic tables. */ if (dict_table_is_intrinsic(prebuilt->table)) { return(row_insert_for_mysql_using_cursor(mysql_rec, prebuilt)); } else { return(row_insert_for_mysql_using_ins_graph( mysql_rec, prebuilt)); } } ~~~ row_insert_for_mysql_using_cursor直接跳過了加鎖的lock_table過程。 然后，如果是intrinsic table，就直接插入，減少了undo的生成。? 如果不是，需要加lock，并生成undo信息。 ~~~ if (dict_table_is_intrinsic(index->table)) { index->rec_cache.rec_size = rec_size; *rec = page_cur_tuple_direct_insert( page_cursor, entry, index, n_ext, mtr); } else { /* Check locks and write to the undo log, if specified */ err = btr_cur_ins_lock_and_undo(flags, cursor, entry, thr, mtr, &inherit); ~~~ 插入的時候，如果是臨時表。就關閉redo的生成。如下面的代碼所示： ~~~ if (dict_table_is_temporary(index->table)) { /* Disable REDO logging as the lifetime of temp-tables is limited to server or connection lifetime and so REDO information is not needed on restart for recovery. Disable locking as temp-tables are local to a connection. */ ut_ad(flags & BTR_NO_LOCKING_FLAG); ut_ad(!dict_table_is_intrinsic(index->table) || (flags & BTR_NO_UNDO_LOG_FLAG)); mtr.set_log_mode(MTR_LOG_NO_REDO); } ~~~ 未完待續，下一個系列，我們將介紹一下undo的新特性，包括online truncated undo。