【dbdao.com MySQL OCP認證專題\】- MySQL 5.6 - OCP 考題講解
1. A simple master-to-slave replication is currently being used. The following information is extracted from the SHOW SLAVE STATUS output:
Last_SQL_Error: Error 'Duplicate entry '8' for key 'PRIMARY'' on query. Default database: 'mydb'.
Query: 'insert into mytable VALUES ('8', 'George')'
Skip_Counter: 0
Retrieved_Gtid_Set: 38f32e23480a7-32a1-c323f78067fd37821: 1-8
Auto_Position: 1
You execute a "SHOW CREATE TABLE mytable" on the slave:
CREATE TABLE 'mytable' (
'ID' int(11) NOT NULL DEFAULT '0',
'name' char(10) DEFAULT NULL,
PRIMARY KEY ('ID')
)
The table mytable on the slave contains the following:
You have issued a STOP SLAVE command. One or more statements are required before you can
issue a START SLAVE command to resolve the duplicate key error.
Which statement should be used?
A) SET GLOBAL SQL_SKIP_SLAVE_COUNTER=1
B) SET GTID_NEXT="CONSISTENCY";
BEGIN; COMMIT;
SET GTID_NEXT=" AUTOMATIC’;
C) SET GLOBAL enforce_gtid_consistency=ON
D) SET GTID_EXECUTED="38f32e23480a7-32a1-c323f78067fd37821 : 9";
E) SET GTID_NEXT="38f32e23480a7-32a1-c323f78067fd37821 : 9";
BEGIN; COMMIT;
SET GTID_NEXT="AUTOMATIC";
--------------------------------------------------------------------
答案：E
分析：此題中使用的Replication是通過GTID實現的，因此
A錯，因此GLOBAL SQL_SKIP_SLAVE_COUNTER=1對使用GTID進行的Replication無效
C錯，因爲GLOBAL enforce_gtid_consistency=ON是實現的前提。
由於GTID_NEXT的有效值爲：
AUTOMATIC / ANONYMOUS / <UUID>:<NUMBER>
因此 B錯
由於Retrieved_Gtid_Set: 38f32e23480a7-32a1-c323f78067fd37821: 1-8
因此已經收到主庫事務1-8，因此報錯是從第9個事務重複記錄導致的，很有可能slave上的第8行被人爲錄入了，導致同步問題。
D錯，因爲GTID_EXECUTED表示已經執行完成的事務。
爲了臨時繞過這個問題，使用注入空事務(BEGIN; COMMIT; ) 代替完成第9個事務.完成後GTID_EXECUTED纔會變爲"38f32e23480a7-32a1-c323f78067fd37821 : 9"
這時候重新SET GTID_NEXT="AUTOMATIC"; 重啓slave後，開始從第10個事務開始同步。
1. #GTID需要開啓的參數
gtid_mode = on
enforce_gtid_consistency = 1
log_slave_updates = 1
2. gtid = source_id:transaction_id
sorce_id 是mysql實例的唯一標識，transaction_id是事務的唯一標識
3. mysql> select @@server_uuid;
查詢當前mysql實例的uuid
4. 使用5.6之前的主從change：
change master to master_host='127.0.0.1',master_user='rep',master_password='rep',
master_log_file='mysql-bin3306.000001',
master_log_pos=151,/*master_auto_position=1*/;
ERROR 1776 (HY000): Parameters MASTER_LOG_FILE, MASTER_LOG_POS, RELAY_LOG_FILE and RELAY_LOG_POS cannot be set when MASTER_AUTO_POSITION is active.
當使用 MASTER_AUTO_POSITION 參數的時候，MASTER_LOG_FILE，MASTER_LOG_POS參數不能使用。
5. 使用5.6之後的主從change：
mysql> change master to master_host='127.0.0.1',master_user='rep',master_password='rep',master_port=3306,master_auto_position=1;
詳見：
https://www.cnblogs.com/zhoujinyi/p/4717951.html
6. 跳過複製錯誤：gtid_next、gtid_purged
在MySQL5.6之前，只需要執行：
mysql> set global sql_slave_skip_counter=1;
跳過一個錯誤的事務，就可以繼續進行復制了。但在MySQL5.6之後則不行：
show slave status裏的信息裏可以找到在執行Master裏的POS:151
Exec_Master_Log_Pos: 151
的時候報錯，所以通過mysqlbinlog找到了GTID：
# at 151
#150810 22:57:45 server id 1 end_log_pos 199 CRC32 0x5e14d88f GTID [commit=yes]
SET @@SESSION.GTID_NEXT= '4e659069-3cd8-11e5-9a49-001c4270714e:1'/*!*/;
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)
mysql> set session gtid_next='4e659069-3cd8-11e5-9a49-001c4270714e:1'; #在session裏設置gtid_next，即跳過這個GTID
Query OK, 0 rows affected (0.01 sec)
mysql> begin; #開啓一個事務
Query OK, 0 rows affected (0.00 sec)
mysql> commit;
Query OK, 0 rows affected (0.01 sec)
mysql> SET SESSION GTID_NEXT = AUTOMATIC; #把gtid_next設置回來
Query OK, 0 rows affected (0.00 sec)
mysql> start slave; #開啓複製
Query OK, 0 rows affected (0.01 sec)
2. Consider the following statement on a RANGE partitioned table:
ALTER TABLE orders DROP PARTITION p1, p3;
What is the outcome of executing the above statement?
A.Only the first partition (p1) will be dropped as only one can be dropped at any time.
B.All data in p1 and p3 partitions are removed, but the table definition remains unchanged.
C.A syntax error will result as you cannot specify more than one partition in the same statement.
D.All data in pi and p3 partitions are removed and the table definition is changed.
--------------------------------------------------------------------
答案：D
在刪除部分分區後，可以使用show create table查看其定義也一併改變了
參考：
http://dev.mysql.com/doc/refman/5.7/en/alter-table-partition-operations.html
1. 創建範圍分區
root@t0epms 16:01:11 [jh_test]> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`id` int(11) DEFAULT NULL,
`year_col` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
/*!50100 PARTITION BY RANGE (year_col)
(PARTITION p0 VALUES LESS THAN (1991) ENGINE = InnoDB,
PARTITION p1 VALUES LESS THAN (1995) ENGINE = InnoDB,
PARTITION p2 VALUES LESS THAN (1999) ENGINE = InnoDB) */
1 row in set (0.01 sec)
2. 刪除部分範圍分區
root@t0epms 16:01:22 [jh_test]> ALTER TABLE t1 DROP PARTITION p0, p1;
Query OK, 0 rows affected (0.01 sec)
Records: 0 Duplicates: 0 Warnings: 0
root@t0epms 16:01:35 [jh_test]> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`id` int(11) DEFAULT NULL,
`year_col` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
/*!50100 PARTITION BY RANGE (year_col)
(PARTITION p2 VALUES LESS THAN (1999) ENGINE = InnoDB) */
1 row in set (0.00 sec)
3.You inherit a legacy database system when the previous DBA, Bob, leaves the company. You are notified that users are getting the following error:
mysql> CALL film_in_stock (40, 2, @count);
ERROR 1449 (HY000): The user specified as a definer ('bob'@'localhost') does not exist
How would you identify all stored procedures that pose the same problem?
A.Execute SELECT * FROM mysql.routines WHERE DEFINER='bob@localhost';.
B.Execute SHOW ROUTINES WHERE DEFINER='bob@localhost'.
C.Execute SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE DEFINER='bob@localhost';.
D.Execute SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER='bob' and HOST='localhost';.
E.Examine the Mysql error log for other ERROR 1449 messages.
----------------------------------------------------------------------------------
答案：C
分析：routines表在庫INFORMATION_SCHEMA下，因此A錯。
可以登陸MySQL後，使用? show命令查看show語法。可知show無routine語句，B錯。
可使用以下命令來查看routines:
pager less; -- 翻頁
select * from information_schema.routines\G
可知C正確
INFORMATION_SCHEMA.PROCESSLIST表中僅顯示了當前正在運行的線程信息,D錯。
Mysql error log是對報錯信息的記錄，並不會有所有存儲過程的記錄，E錯。
4. When designing an InnoDB table, identify an advantage of using the BIT datatype Instead of one of the integer datatypes.
A. BIT columns are written by InnoDB at the head of the row, meaning they are always the first to be retrieved.
B. Multiple BIT columns pack tightly into a row, using less space.
C. BIT(8) takes less space than eight TINYINT fields.
D. The BIT columns can be manipulated with the bitwise operators &, |, ~, ^, <<, and >>. The other integer types cannot.
------------------------------------------------
答案：C
分析：關於數據類型的存儲，可查看http://dev.mysql.com/doc/refman/5.7/en/storage-requirements.html
A, B都沒有特別在guide中提到。
BIT(8)大致長度爲1個Byte, 8個tinyint的存儲長度相當於一個bigint了, 請注意並不是說tinyint(8)，括號中爲可顯示的長度，由於一個tinyint爲1個Byte，因此8個自然要更長。因此C正確。
D錯，int類型值夜可以進行bit操作符的操作
Manipulated 熟練操作 investigate 調查 interfering 干涉
5. ROW-based replication has stopped working. You investigate the error log file and find the following entries:
2013-08-27 14:15:47 9056 [ERROR] Slave SQL: Could not execute Delete_rows event on table test.t1; Can’t find record in ‘t1’, Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event’s master log 56_master-bin.000003, end_log_pos 851, Error_code: 1032
2013-08-27 14:15:47 9056 [warning] Slave: Can’t find record in ‘t1’ Error_code: 1032
2013-08-27 14:15:47 9056 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with “SLAVE START”. We stopped at log ‘56_masterbin.000003’ position 684
Why did you receive this error?
A. The slave SQL thread does not have DELETE privileges to execute on test.t1 table.s
B. The table definition on the slave litters from the master.
C. Multi-threaded replication slaves can have temporary errors occurring for cross database updates.
D. The slave SQL thread attempted to remove a row from the test.t1 table, but the row did not exist.
-------------------------------------------------------------------------------------------
答案：D
分析：報錯中說的非常明確Could not execute Delete_rows event on table test.t1; Can’t find record in ‘t1’，
這說明slave上這條記錄已經被人爲刪除了，導致Row-Based Replication進行同步刪除的時候，找不到這條記錄。ABC選項都和此報錯以及所問問題無關。
6. mysqldump was used to create a single schema backup;
Shell> mysqldump –u root –p sakila > sakila2013.sql
Which two commands will restore the sakila database without interfering with other running
database?
A. Mysql> USE sakila; LOAD DATA INFILE 'sakila2013.sql';
B. Shell> mysql –u root –p sakila < sakila2013.sql
C. Shell> mysqlimport –u root –p sakila sakila2013.sql
D. Shell> mysql –u root -p –e 'use sakila; source sakila2013.sql'
E. Shell> mysql –u root –p –silent < sakila2013.sql
--------------------------------------------------------------------------------
答案：B
分析：
A錯，load data infile針對的是select ... into oufile輸出的表數據文件，其文件中不含有插入執行語句，僅含有數據。而mysqldump導出的文件包含的數據是以可執行sql語句實現的。
C錯，因此mysqlimport是類似於load data infile語句功能的shell命令行工具，因此對應倒入的文件都應該是非sql語句執行的純表數據文件。
我們看到mysqldump在未使用--database項導出時，並未在文件中使用create database語句。
當導入數據庫dump文件，你需要在命令中指定數據庫名，即use db_name進入此庫：
shell> mysql db_name < dump.sql
因此B正確
mysql -e 可用於執行語句，但是mysql客戶端語句需要使用分號作爲終止符發給服務端，因此每個語句後都需要使用分號，D錯誤。
如果D爲Shell> mysql –u root -p –e 'use sakila; source sakila2013.sql;' 則正確。
E錯. mysql命令項使用中，短項使用單橫槓，長命令項使用雙橫槓 -silent項應該時候雙橫槓，因此錯。
參考：
http://dev.mysql.com/doc/refman/5.7/en/load-data.html
http://dev.mysql.com/doc/refman/5.7/en/mysqlimport.html
http://dev.mysql.com/doc/refman/5.7/en/mysql.html
woson_wang: D也是對的
2017-2-28 19:48回覆
7. Consider the Mysql Enterprise Audit plugin.
You are checking user accounts and attempt the following query:
Mysql> SELECT user, host, plugin FROM mysql.users;
ERROR 1146 (42S02): Table ‘mysql.users’ doesn’t exist
Which subset of event attributes would indicate this error in the audit.log file?
A.
NAME=”Query”
STATUS=”1146”
SQLTEXT=”select user,host from users”/>
B.
NAME=”Error”
STATUS=”1146”
SQLTEXT=”Error 1146 (42S02): Table ‘mysql.users’ doesn’t exist”/>
C.
NAME=”Query”
STATUS=”1146”
SQLTEXT=” Error 1146 (42S02): Table ‘mysql.users’ doesn’t exist”/>
D.
NAME=”Error”
STATUS=”1146”
SQLTEXT=”select user,host from users”/>
E.
NAME=”Error”
STATUS=”0”
SQLTEXT=”Error 1146 (42S02): Table ‘mysql.users’ doesn’t exist”/>
---------------------------------------------------------
答案：A
分析：
注意：MySQL Enterprise Audit是包含在MySQL企業版中的一個擴展插件，因此如果你在學習時使用的是社區版的MySQL,那你是無法實驗的。
因爲它需要在環境變量plugin_dir對應目錄下存在audit_log.so插件文件。
從選擇答案中可知，Audit log中使用的是舊格式進行的記錄。
由於SQLTEXT僅在NAME爲Query或Execute時，纔會有出現，且NAME不存在Error狀態。因此B,D,E錯。
而SQLTEXT僅存放所使用的SQL語句。而返回的狀態存放在STATUS下，0爲成功，非0爲報錯號，因此A對C錯。
參考：
http://dev.mysql.com/doc/refman/5.7/en/audit-log-plugin.html
http://dev.mysql.com/doc/refman/5.7/en/audit-log-file.html
8. Which query would you use to find connections that are in the same state for longer than 180 seconds?
A. SHOW FULL PROCESSLIST WHERE Time > 180;
B. SELECT * FROM INFORMATION_SCHEMA.EVENTS SHERE STARTS < (DATE_SUB(NOW(), INTERVAL 180 SECOND));
C. SELECT * FROM INFORMATION_SCHEMA.SESSION_STATUS WHERE STATE < (DATE_SUB(NOW(), INTERVAL 180 SECOND));
D. SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE TIME > 180;
-------------------------------------------------
答案：D
分析：
你可以使用 help show;命令來查看其語法可知：
SHOW [FULL] PROCESSLIST
此語法後面不可以跟where語句，因此A錯。
INFORMATION_SCHEMA.EVENTS表顯示的是計劃的作業，和連接保持的狀態時間無關，B錯。
INFORMATION_SCHEMA.SESSION_STATUS表顯示的是當前會話的變量及其變量值，和狀態信息無關，C錯。
INFORMATION_SCHEMA.PROCESSLIST顯示了當前的連接情況，狀態，以及狀態保持的時間，實際上show processlist也是查看的這張表，不過直接使用select可以使用where語句，D正確。
參考：
http://dev.mysql.com/doc/refman/5.7/en/information-schema.html
Intensive 加強的 periodically 週期性地 pruning 修剪
9. A database exists as a read-intensive server that is operating with query_cache_type =DEMAND.
The database is refreshed periodically, but the resultset size of the queries does not fluctuate.
—-Note the following details about this environment:
A web application uses a limited set of queries.
The Query Cache hit rate is high.
All resultsets fit into the Query Cache.
All queries are configured to use the Query Cache successfully.
The response times for queries have recently started to increase. The cause for this has correctly been identified as the increase in the number of concurrent users accessing the web service.
Based solely on the information provided, what is the most likely cause for this slowdown at the database level?
A. The Query Cache is pruning queries due to an increased number of requests.
B. Query_cache_min_res_unit has been exceeded, leading to an increased performance overhead due to additional memory block lookups.
C. Mutex contention on the Query Cache is forcing the queries to take longer due to its singlethreaded nature.
D. The average resultset of a query is increasing due to an increase in the number of users requiring SQL statement execution.
---------------------------------------------------------------------------------------------------------
答案：C
分析：這是一個讀密集型數據庫，數據庫會在一段時間後刷新，但是其查詢的結果集大小波動不大。而所有結果集都在Query Cache中，且網頁應用使用一套有限的查詢語句。且Query Cache hit rate很高。
因此A，D錯，請求通過的應用查詢，查詢語句數量有限，結果集都能放在Query Cache中，相同查詢語句的請求不會增多Query Cache中的資源的佔用，因此清理查詢並非主要矛盾。
B也錯，因此Query_cache_min_res_unit設置過大，僅會造成Query Cache中碎片過多。如果請求的結果集都能在Query Cache中，這就和碎片沒什麼關係了。
C正確，儘管官方文檔中未大量解釋Query Cache Mutex爭用問題，在線程運行查詢語句時，會在Query Cache中先獲取Mutex鎖，之後開始查詢匹配的查詢語句和結果集。如果找到後返回結果。
如果未找到匹配，在執行查詢後，需要將查詢語句和結果集插入Query Cache中，這也會需要獲取鎖。儘管這個時間所需非常短，但是在讀密集的情況下，資源爭用會導致線程排隊等待現象。
參考：
http://dev.mysql.com/doc/refman/5.7/en/query-cache.html
http://dev.mysql.com/doc/refman/5.7/en/query-cache-configuration.html
1. query_cache_type = 0,1,2，分別代表了off、on、demand
如果是1，那麼查詢總是先到查詢緩存中查找，即使使用了sql_no_cache仍然查詢緩存，因爲sql_no_cache只是不緩存查詢結果，而不是不使用查詢結果。
如果是2，DEMAND。在my.ini中增加一行,query_cache_type=2,重啓mysql服務
使用sql_cache查詢時間也一樣，因爲sql_cache只是將查詢結果放入緩存，沒有使用sql_cache查詢也會先到查詢緩存中查找數據
2. mysql使用總內存 = global_buffers + all_thread_buffers
global_buffers ( 全局內存分配總和 ) =
innodb_buffer_pool_size -- InnoDB高速緩衝，行數據、索引緩衝，以及事務鎖、自適應哈希等
+innodb_additional_mem_pool_size -- InnoDB數據字典額外內存，緩存所有表數據字典
+innodb_log_buffer_size -- InnoDB REDO日誌緩衝，提高REDO日誌寫入效率
+key_buffer_size -- MyISAM表索引高速緩衝，提高MyISAM表索引讀寫效率
+query_cache_size -- 查詢高速緩存，緩存查詢結果，提高反覆查詢返回效率
+table_cahce -- 表空間文件描述符緩存，提高數據表打開效率
+table_definition_cache -- 表定義文件描述符緩存，提高數據表打開效率
all_thread_buffers (會話/線程級內存分配總和) =
max_threads(當前活躍連接數) * (
read_buffer_size -- 順序讀緩衝，提高順序讀效率
+read_rnd_buffer_size -- 隨機讀緩衝，提高隨機讀效率
+sort_buffer_size -- 排序緩衝，提高排序效率
+join_buffer_size -- 表連接緩衝，提高表連接效率
+binlog_cache_size -- 二進制日誌緩衝，提高二進制日誌寫入效率
+tmp_table_size -- 內存臨時表，提高臨時表存儲效率
+thread_stack -- 線程堆棧，暫時寄存SQL語句/存儲過程
+thread_cache_size -- 線程緩存，降低多次反覆打開線程開銷
+net_buffer_length -- 線程持連接緩衝以及讀取結果緩衝
+bulk_insert_buffer_size ) -- MyISAM表批量寫入數據緩衝
3. 內存碎片
query_cache_min_res_unit 查詢緩存分配的最小塊的大小(字節)，默認爲4k
query_alloc_block_size 爲查詢分析和執行過程中創建的對象分配的內存塊大小
Qcache_free_blocks 代表內存自由塊的多少，反映了內存碎片的情況
==========================
1）當查詢進行的時候，Mysql把查詢結果保存在qurey cache中，但如果要保存的結果比較大，超過query_cache_min_res_unit的值 ，這時候mysql將一邊檢索結果，一邊進行保存結果，所以，有時候並不是把所有結果全部得到後再進行一次性保存，而是每次分配一塊 query_cache_min_res_unit 大小的內存空間保存結果集，使用完後，接着再分配一個這樣的塊，如果還不不夠，接着再分配一個塊，依此類推，也就是說，有可能在一次查詢中，mysql要 進行多次內存分配的操作。
2）內存碎片的產生。當一塊分配的內存沒有完全使用時，MySQL會把這塊內存Trim掉，把沒有使用的那部分歸還以重 複利用。比如，第一次分配4KB,只用了3KB，剩1KB，第二次連續操作，分配4KB，用了2KB，剩2KB，這兩次連續操作共剩下的 1KB+2KB=3KB，不足以做個一個內存單元分配， 這時候，內存碎片便產生了。
3）使用flush query cache，可以消除碎片
4）如果Qcache_free_blocks值過大，可能是query_cache_min_res_unit值過大，應該調小些
5）query_cache_min_res_unit的估計值：(query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache
