【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
