简介面向正在备考MySQL 5.7数据库管理员认证1z0-888的DBA、运维工程师和数据库学习者这份docx题库文档提供了针对认证考试典型选择题的深度解析。内容覆盖MyISAM存储引擎在磁盘空间不足时的处理机制、mysql_config_editor登录路径管理、数据目录初始化步骤、明文密码认证插件等核心考点每题均结合正确答案逐项说明选项差异便于快速掌握解题逻辑并巩固相关实践经验。通过研读这些解析读者可以理解MySQL服务器在资源限制下的容错行为学会安全保存登录凭据的方法并掌握新实例初始化及安全认证配置的管理思路对实际运维工作同样有参考价值。压缩包内包含1个docx文件整体大小约1.25MB文字内容紧凑清晰适合在电脑端阅读、检索与打印复习。目前已有357人学习下载适合作为备考后期查漏补缺和考前冲刺的参考资料。1. 1z0-888 这道 MySQL 5.7 认证值得每个 DBA 认真拆解刚拿到一份 MySQL 5.7 的认证题库时最容易产生的错觉是背完就能过。1z0-888 全称是 MySQL 5.7 Database Administrator对应的不是一两条命令而是 DBA 从建库到救库的完整职责架构选型、安全管控、备份恢复、复制高可用、性能调优和故障排查。真正的价值在于题里默认了你不只记命令还要知道它为什么这样运行。工作三五年的人拿它梳理知识边界新入行的 DBA 则把它当学习地图。这篇按 1z0-888 的常考范围把概念、命令和验证步骤放在一起能直接在本地 5.7 实例上复现。2. 1z0-888 考试范围与 MySQL 5.7 架构先立好概念再进题库2.1 1z0-888 的考试域和题量分布1z0-888 的题目量一般在 75 道上下答题时间 150 分钟具体通过条件以注册时的官方考试说明为准。题量分布并不平均复习时别按章节顺序平推先把权重高的部分做厚。官方考纲覆盖的大致范围如下复习权重按实际生产经验标注考试域主要考察内容复习权重MySQL 架构与安装存储引擎、配置文件、5.7 安装与升级路径中安全管理账号、授权、认证插件、连接加密中备份恢复逻辑备份、物理备份、binlog、时间点恢复高复制与高可用主从、GTID、半同步、故障切换高性能优化索引、慢查询、缓冲池、sys schema高监控与排错状态变量、错误日志、锁等待中从这张表能得出两个结论。第一备份恢复、复制高可用、性能优化三块通常占一半以上单选题会问“选哪个参数”多选和拖拽题则会把几种方案摆在一起让判断。第二这些内容在生产环境里都有对应物答案记不住时按“生产上哪样做最不容易丢数据”去排除正确率也不会太低。题库里偶尔会出现比较偏的参数记忆题比如多线程复制从库参数叫什么这类题丢分不可惜不要在偏门上耗太多时间。2.2 MySQL 5.7 架构中 DBA 必须记住的关键对象5.7 的架构题不考画图但会把架构细节藏进选项里。第一个必须分清的是 InnoDB 的缓冲池与 redo/undo 之间的关系。已提交事务即使脏页没刷到磁盘也能靠 redo log 重放未提交事务则用 undo 回滚。选项常把两者反着写比如“用 undo log 保证已提交事务不丢失”这类一看到就可以排除。第二个重点是 InnoDB 与 binlog 的一致性。5.7 通过内部 XA 机制把存储引擎提交和二进制日志写盘绑定在一起避免主库有事务、binlog 却没有记录导致从库追不上。这也是复制和 PITR 的前提。第三个差异点是物理形态5.7 仍然用 .frm 文件保存表定义数据字典重构到 8.0 才完成所以判断“5.7 支持原子 DDL”要打问号。第四个坑在字符集5.7 的 utf8 实际上是 utf8mb3真正能存完整 emoji 的是 utf8mb4建表题里看到中文或表情符号场景优先选 utf8mb4。再补充一个版本差异记忆点5.7 中事务隔离级别变量名是 tx_isolation同时兼容 transaction_isolation8.0 只认后者。看到选项里只有旧变量名时先想一下题干是不是 5.6 时代的题。2.3 本地跑通 MySQL 5.7 的最小安装配置教程备考不需要很强的服务器一个 Docker 实例就够。下面这段是比较常见的 MySQL 5.7 安装配置教程的 Docker 版最小步骤复习时直接复制运行即可docker run -d --name mysql57 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDrootpass \ -e MYSQL_DATABASEexamdb \ mysql:5.7 \ --character-set-serverutf8mb4 \ --collation-serverutf8mb4_general_ci参数拆开看并不复杂-p 3306:3306把容器内 3306 映射到本机MYSQL_ROOT_PASSWORD是容器初始化时设置的 root 密码只适合开发环境MYSQL_DATABASEexamdb会在首次初始化时自动建库镜像名后面跟的--character-set-serverutf8mb4和--collation-serverutf8mb4_general_ci会变成 mysqld 启动参数确定实例默认字符集和排序规则。注意这两个参数必须一起给否则建表默认排序规则可能不符合预期。容器起来后连库先确认基础变量docker exec -it mysql57 mysql -uroot -prootpass examdb mysql SELECT VERSION(), default_storage_engine, tx_isolation, query_cache_type;看到tx_isolation返回REPEATABLE-READ说明实例正常。之后建立备份恢复和复制环境都可以在这台实例上操作需要模拟主从时再起一个容器端口映射成 3307。如果习惯用物理机或云主机同样是一份 my.cnf 加一条初始化命令的事效果一致区别只是 Docker 能让你随时删掉重来对验证易错题更友好。3. 1z0-888 的备份恢复与复制题用命令把答案验证出来备份恢复和复制放在一起复习是因为它们的核心都落在 binlog 上备份要记录 binlog 坐标复制要消费 binlog题库里很多题会把这两块交叉出。我的做法是在本地建一个小库把这些命令实际跑过答案自然记得住。3.1 备份题先看清引擎mysqldump 参数不是乱加的mysqldump 是 1z0-888 备份题绝对的高频对象。不少选项看起来都对但放到 MyISAM 或 InnoDB 场景下就有明确对错。先记住下面这张对照表场景推荐写法原因InnoDB 联机全备--single-transaction --master-data2一致性快照不锁业务写入MyISAM 或混合引擎--lock-all-tables备份期间统一锁表保证一致从库上做备份--dump-slave2 --single-transaction记录从库自己的执行位点要保留存储对象--routines --triggers --events默认不包含存储过程、触发器、事件本地执行一轮 InnoDB 全备mysqldump -uroot -p \ --single-transaction \ --master-data2 \ --routines --triggers --events \ --databases examdb examdb_$(date %F).sql逻辑说明--single-transaction对 InnoDB 开启一致性快照让导出过程中读到的是一致点不阻塞写--master-data2会把主库当前 binlog 文件名和坐标以注释形式写进 SQL 文件方便后续做时间点恢复--routines等三个参数补上默认不含的存储对象--databases让 dump 文件包含 CREATE DATABASE恢复时不用先手工建库。MyISAM 表不吃事务快照光加--single-transaction并不能保证 MyISAM 表一致所以混合引擎环境要用--lock-all-tables。备份之后一定要验证恢复路径。先读出备份文件里的位点再重放 binloghead -50 examdb_2025-01-01.sql | grep -m1 CHANGE MASTER mysqlbinlog --start-position154 \ --stop-datetime2025-01-01 10:30:00 \ /var/lib/mysql/mysql-bin.000008 | mysql -uroot -p先用 grep 从备份文件里读出 MASTER_LOG_POS再把该位置之后的 binlog 重放过去就能恢复到指定时间点。题目如果问“全备加密”或“物理备份”mysqldump 不适用要往 MySQL Enterprise Backup 或 Percona XtraBackup 方向想区分逻辑备份与物理备份本身也是一类送分题。3.2 GTID 复制题5.7 与 5.6 的配置差异是高频失分点GTID 在 MySQL 5.6 出现5.7 里已经可以稳妥用在生产。1z0-888 的复制题经常把 5.6 的实验参数和 5.7 的稳定参数混在一起复习时先背一组最小配置[mysqld] server-id101 gtid_modeON enforce_gtid_consistencyON log-binmysql-bin binlog_formatROW log-slave-updatesONgtid_modeON开启 GTIDenforce_gtid_consistencyON禁止 CREATE TABLE ... SELECT 这类会让 GTID 出现空洞的写法log-slave-updatesON在链式复制时必须开否则从库不会把执行过的事务写进自己的 binlogbinlog_formatROW在 5.7 里已是默认行为写进配置更明确。注意如果实例里已有历史事务开启 GTID 前要先做全量备份并确认事务一致性否则切换过程会出各种复制异常。主从配置用自动定位CHANGE MASTER TO MASTER_HOST192.168.1.101, MASTER_USERrepl, MASTER_PASSWORDRepl123, MASTER_AUTO_POSITION1; START SLAVE; SHOW SLAVE STATUS\G用MASTER_AUTO_POSITION1时主从自动交换已执行的 GTID 集合不需要手工填MASTER_LOG_FILE和MASTER_LOG_POS。查看复制状态时别只盯Seconds_Behind_Master更可靠的是对比Retrieved_Gtid_Set和Executed_Gtid_Set两个字段差集越大说明从库延迟越多如果 IO 或 SQL 线程不是 Yes直接看Last_IO_Error和Last_SQL_Error定位。这条排查顺序在考试和现场都适用。3.3 半同步复制和高可用题怎么理解参数半同步复制是复制题里另一个高频点。普通异步复制主库提交后不等从库确认半同步要求至少一个从库返回 ACK主库才认为提交完成。5.7 默认使用 AFTER_SYNC 语义主库已写 binlog、等待从库 ACK 之后才提交。参数配置如下[mysqld] plugin-loadrpl_semi_sync_mastersemisync_master.so;rpl_semi_sync_slavesemisync_slave.so rpl_semi_sync_master_enabledON rpl_semi_sync_slave_enabledON rpl_semi_sync_master_timeout1000rpl_semi_sync_master_enabled和rpl_semi_sync_slave_enabled必须成对出现只有主库开、从库不开实际不会进入半同步。rpl_semi_sync_master_timeout单位是毫秒这里等于 1 秒超过这个时间没有 ACK自动降级成异步复制避免主库提交卡死。生产环境里我习惯把超时调到 3000 毫秒给网络抖动留余量但考试题要看题干给的参数值。高可用题常问“failover 前要确认什么”回答里通常包含两个 GTID 集合一致、半同步是否降级、relay log 是否有积压把这些点和参数对应起来比死记步骤更稳。4. 1z0-888 性能优化考点慢查询、explain 和 sys schema 一起看性能优化在 1z0-888 里通常以“变慢 → 怎么查 → 怎么改”的链路出题。先开启慢查询日志拿到慢语句再用 EXPLAIN 分析路径最后用 sys schema 验证等待和锁信息这条顺序在生产环境同样成立。4.1 开启慢查询日志定位问题语句先在会话里开慢查询不用重启实例SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1; SET GLOBAL log_queries_not_using_indexes ON;这组参数把超过 1 秒的语句记入慢日志并且把没有走索引的语句也记下来。相关参数对照如下参数默认值用途slow_query_logOFF慢查询日志总开关long_query_time10阈值单位秒调优阶段常用 1log_queries_not_using_indexesOFF没走索引也记录适合清理低效 SQLmin_examined_row_limit0扫描行数低于该值不记录排查全表扫时常用 1000注意 5.7 没有SET PERSIST这些动态参数重启后会丢验证出问题后记得写回 my.cnf。生产库上开启慢日志后要及时关掉避免日志增长过快。日志积累一段时间后用官方自带的 mysqldumpslow 汇总mysqldumpslow -t 10 -s at /var/lib/mysql/*-slow.log-t 10只显示前 10 条-s at按平均查询时间倒序想看执行次数用-s c。题库如果问“哪条命令分析慢查询”mysqldumpslow 是 5.7 自带答案pt-query-digest 也常用但那是 Percona 工具注意区分。4.2 explain 输出里 DBA 必须看的几个字段EXPLAIN 是分析执行计划不真正执行语句。5.7 还支持EXPLAIN FORMATJSON会给出更细的成本估算。先把常规列的含义记清楚列含义判断方法type访问路径从好到差const、eq_ref、ref、range、index、ALLkey实际选定的索引NULL 表示没走索引rows估算扫描行数与真实行数差距大时先 ANALYZE TABLEExtra附加执行信息Using temporary / Using filesort 通常需要改写 SQL实际跑一条EXPLAIN FORMATJSON SELECT o.id, o.amount FROM orders o JOIN users u ON u.id o.user_id WHERE u.city Shanghai AND o.status 0;返回是嵌套 JSON挑几个关键字段看。截取后的片段大致如下{ access_type: ALL, rows_examined_per_scan: 1000, attached_condition: (examdb.u.city Shanghai) }access_type: ALL说明这条 SQL 在扫描全表数据量大时应该考虑在city上建二级索引。许多人把key和possible_keys搞混前者是优化器真正用的索引后者只是候选列表选择题里经常把只在 possible_keys 中的索引写成“已使用”看到别急着选。4.3 5.7 的 sys schema 与 query cache 差别题sys schema 是 performance_schema 的视图层把难读的原始表包装成 DBA 常用的查询5.7 默认开启 performance_schema所以 sys schema 可以直接用。下面三个查询覆盖常见排障场景SELECT * FROM sys.table_io_waits_summary_by_table WHERE object_schema examdb ORDER BY total_latency DESC LIMIT 5; SELECT query, exec_count, rows_examined, rows_sent FROM sys.statements_with_full_table_scans ORDER BY exec_count DESC LIMIT 5; SELECT * FROM sys.innodb_lock_waits\G第一条找哪张表的 IO 等待最长第二条直接列出正在做全表扫描的语句第三条在锁等待或死锁排障时看阻塞源头。题库如果问 5.7 有哪些优化工具选项里出现 sys schema 的视图名通常是正确项。另一类容易错的题是 query cache。5.7 已经默认关闭并标记废弃8.0 直接移除凡是“开 query cache 提升写多读少性能”的说法都不要选。看到SHOW VARIABLES LIKE query_cache_type返回 OFF 的题想表达的其实是这个机制已经不该依赖。5. 1z0-888 考前自测在 MySQL 5.7 实例上验证每个为什么题库 docx 里的题分两类一类背参数名就能答另一类必须理解行为。对后者我会在本地实例上造一个对照组把答案能复现的都复现出来。这里拿事务隔离级别举例因为它直接关系到备份恢复题也是多选题常客。-- 会话 A建表并写入 CREATE TABLE t_rr(id INT PRIMARY KEY, v INT) ENGINEInnoDB; INSERT INTO t_rr VALUES (1, 10); -- 会话 A开启事务后做一次快照读 START TRANSACTION; SELECT * FROM t_rr WHERE id 1; -- 返回 10 -- 会话 B另一个连接提交更新 UPDATE t_rr SET v 20 WHERE id 1; COMMIT; -- 会话 A再次普通 SELECT仍返回 10 SELECT * FROM t_rr WHERE id 1; -- 会话 A加锁读走当前读返回 20 SELECT * FROM t_rr WHERE id 1 FOR UPDATE; COMMIT;这个实验能解释--single-transaction的原理。REPEATABLE READ 下事务第一次快照读之后的普通 SELECT 都基于同一份快照因此会话 A 看不到会话 B 的已提交更新只有FOR UPDATE这类加锁读走当前读才看到最新值。备份场景正是靠这种一致性快照让长时间导出不影响并发写入也不会导出到一半一半的脏结果。离开实例回到考场把每个题干对照下面几步过一遍能挡掉大部分失分先确认题目版本是 MySQL 5.7。看到 query cache 被推荐基本排除看到 caching_sha2_password 是默认认证插件那不是 5.7 的行为。区分备份对象。混合引擎表要 lock all tables纯 InnoDB 用 single transaction。复制题看主从是否都启用 GTID。配置片段里只有 server-id 没有 gtid_mode说明还在老式位点复制。性能题先看 type 和 key其次看 rows 和 Extra。ALL 且 key 为 NULL 时建索引是优先答案。参数题先把单位圈出来。long_query_time 默认 10 秒rpl_semi_sync_master_timeout 默认 1000 毫秒。最后再给一个实际做法每道题对完答案后在旁边补一句“它正在解决什么场景”。能写清楚场景的选项即使题干换一种问法也能认出来写不出场景的说明只是记住了字面回到实例上补一次验证再继续。本文还有配套的精品资源点击获取 1z0-888 MySQL 5.7 DBA认证核心考点与实战解析
简介面向正在备考MySQL 5.7数据库管理员认证1z0-888的DBA、运维工程师和数据库学习者这份docx题库文档提供了针对认证考试典型选择题的深度解析。内容覆盖MyISAM存储引擎在磁盘空间不足时的处理机制、mysql_config_editor登录路径管理、数据目录初始化步骤、明文密码认证插件等核心考点每题均结合正确答案逐项说明选项差异便于快速掌握解题逻辑并巩固相关实践经验。通过研读这些解析读者可以理解MySQL服务器在资源限制下的容错行为学会安全保存登录凭据的方法并掌握新实例初始化及安全认证配置的管理思路对实际运维工作同样有参考价值。压缩包内包含1个docx文件整体大小约1.25MB文字内容紧凑清晰适合在电脑端阅读、检索与打印复习。目前已有357人学习下载适合作为备考后期查漏补缺和考前冲刺的参考资料。1. 1z0-888 这道 MySQL 5.7 认证值得每个 DBA 认真拆解刚拿到一份 MySQL 5.7 的认证题库时最容易产生的错觉是背完就能过。1z0-888 全称是 MySQL 5.7 Database Administrator对应的不是一两条命令而是 DBA 从建库到救库的完整职责架构选型、安全管控、备份恢复、复制高可用、性能调优和故障排查。真正的价值在于题里默认了你不只记命令还要知道它为什么这样运行。工作三五年的人拿它梳理知识边界新入行的 DBA 则把它当学习地图。这篇按 1z0-888 的常考范围把概念、命令和验证步骤放在一起能直接在本地 5.7 实例上复现。2. 1z0-888 考试范围与 MySQL 5.7 架构先立好概念再进题库2.1 1z0-888 的考试域和题量分布1z0-888 的题目量一般在 75 道上下答题时间 150 分钟具体通过条件以注册时的官方考试说明为准。题量分布并不平均复习时别按章节顺序平推先把权重高的部分做厚。官方考纲覆盖的大致范围如下复习权重按实际生产经验标注考试域主要考察内容复习权重MySQL 架构与安装存储引擎、配置文件、5.7 安装与升级路径中安全管理账号、授权、认证插件、连接加密中备份恢复逻辑备份、物理备份、binlog、时间点恢复高复制与高可用主从、GTID、半同步、故障切换高性能优化索引、慢查询、缓冲池、sys schema高监控与排错状态变量、错误日志、锁等待中从这张表能得出两个结论。第一备份恢复、复制高可用、性能优化三块通常占一半以上单选题会问“选哪个参数”多选和拖拽题则会把几种方案摆在一起让判断。第二这些内容在生产环境里都有对应物答案记不住时按“生产上哪样做最不容易丢数据”去排除正确率也不会太低。题库里偶尔会出现比较偏的参数记忆题比如多线程复制从库参数叫什么这类题丢分不可惜不要在偏门上耗太多时间。2.2 MySQL 5.7 架构中 DBA 必须记住的关键对象5.7 的架构题不考画图但会把架构细节藏进选项里。第一个必须分清的是 InnoDB 的缓冲池与 redo/undo 之间的关系。已提交事务即使脏页没刷到磁盘也能靠 redo log 重放未提交事务则用 undo 回滚。选项常把两者反着写比如“用 undo log 保证已提交事务不丢失”这类一看到就可以排除。第二个重点是 InnoDB 与 binlog 的一致性。5.7 通过内部 XA 机制把存储引擎提交和二进制日志写盘绑定在一起避免主库有事务、binlog 却没有记录导致从库追不上。这也是复制和 PITR 的前提。第三个差异点是物理形态5.7 仍然用 .frm 文件保存表定义数据字典重构到 8.0 才完成所以判断“5.7 支持原子 DDL”要打问号。第四个坑在字符集5.7 的 utf8 实际上是 utf8mb3真正能存完整 emoji 的是 utf8mb4建表题里看到中文或表情符号场景优先选 utf8mb4。再补充一个版本差异记忆点5.7 中事务隔离级别变量名是 tx_isolation同时兼容 transaction_isolation8.0 只认后者。看到选项里只有旧变量名时先想一下题干是不是 5.6 时代的题。2.3 本地跑通 MySQL 5.7 的最小安装配置教程备考不需要很强的服务器一个 Docker 实例就够。下面这段是比较常见的 MySQL 5.7 安装配置教程的 Docker 版最小步骤复习时直接复制运行即可docker run -d --name mysql57 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDrootpass \ -e MYSQL_DATABASEexamdb \ mysql:5.7 \ --character-set-serverutf8mb4 \ --collation-serverutf8mb4_general_ci参数拆开看并不复杂-p 3306:3306把容器内 3306 映射到本机MYSQL_ROOT_PASSWORD是容器初始化时设置的 root 密码只适合开发环境MYSQL_DATABASEexamdb会在首次初始化时自动建库镜像名后面跟的--character-set-serverutf8mb4和--collation-serverutf8mb4_general_ci会变成 mysqld 启动参数确定实例默认字符集和排序规则。注意这两个参数必须一起给否则建表默认排序规则可能不符合预期。容器起来后连库先确认基础变量docker exec -it mysql57 mysql -uroot -prootpass examdb mysql SELECT VERSION(), default_storage_engine, tx_isolation, query_cache_type;看到tx_isolation返回REPEATABLE-READ说明实例正常。之后建立备份恢复和复制环境都可以在这台实例上操作需要模拟主从时再起一个容器端口映射成 3307。如果习惯用物理机或云主机同样是一份 my.cnf 加一条初始化命令的事效果一致区别只是 Docker 能让你随时删掉重来对验证易错题更友好。3. 1z0-888 的备份恢复与复制题用命令把答案验证出来备份恢复和复制放在一起复习是因为它们的核心都落在 binlog 上备份要记录 binlog 坐标复制要消费 binlog题库里很多题会把这两块交叉出。我的做法是在本地建一个小库把这些命令实际跑过答案自然记得住。3.1 备份题先看清引擎mysqldump 参数不是乱加的mysqldump 是 1z0-888 备份题绝对的高频对象。不少选项看起来都对但放到 MyISAM 或 InnoDB 场景下就有明确对错。先记住下面这张对照表场景推荐写法原因InnoDB 联机全备--single-transaction --master-data2一致性快照不锁业务写入MyISAM 或混合引擎--lock-all-tables备份期间统一锁表保证一致从库上做备份--dump-slave2 --single-transaction记录从库自己的执行位点要保留存储对象--routines --triggers --events默认不包含存储过程、触发器、事件本地执行一轮 InnoDB 全备mysqldump -uroot -p \ --single-transaction \ --master-data2 \ --routines --triggers --events \ --databases examdb examdb_$(date %F).sql逻辑说明--single-transaction对 InnoDB 开启一致性快照让导出过程中读到的是一致点不阻塞写--master-data2会把主库当前 binlog 文件名和坐标以注释形式写进 SQL 文件方便后续做时间点恢复--routines等三个参数补上默认不含的存储对象--databases让 dump 文件包含 CREATE DATABASE恢复时不用先手工建库。MyISAM 表不吃事务快照光加--single-transaction并不能保证 MyISAM 表一致所以混合引擎环境要用--lock-all-tables。备份之后一定要验证恢复路径。先读出备份文件里的位点再重放 binloghead -50 examdb_2025-01-01.sql | grep -m1 CHANGE MASTER mysqlbinlog --start-position154 \ --stop-datetime2025-01-01 10:30:00 \ /var/lib/mysql/mysql-bin.000008 | mysql -uroot -p先用 grep 从备份文件里读出 MASTER_LOG_POS再把该位置之后的 binlog 重放过去就能恢复到指定时间点。题目如果问“全备加密”或“物理备份”mysqldump 不适用要往 MySQL Enterprise Backup 或 Percona XtraBackup 方向想区分逻辑备份与物理备份本身也是一类送分题。3.2 GTID 复制题5.7 与 5.6 的配置差异是高频失分点GTID 在 MySQL 5.6 出现5.7 里已经可以稳妥用在生产。1z0-888 的复制题经常把 5.6 的实验参数和 5.7 的稳定参数混在一起复习时先背一组最小配置[mysqld] server-id101 gtid_modeON enforce_gtid_consistencyON log-binmysql-bin binlog_formatROW log-slave-updatesONgtid_modeON开启 GTIDenforce_gtid_consistencyON禁止 CREATE TABLE ... SELECT 这类会让 GTID 出现空洞的写法log-slave-updatesON在链式复制时必须开否则从库不会把执行过的事务写进自己的 binlogbinlog_formatROW在 5.7 里已是默认行为写进配置更明确。注意如果实例里已有历史事务开启 GTID 前要先做全量备份并确认事务一致性否则切换过程会出各种复制异常。主从配置用自动定位CHANGE MASTER TO MASTER_HOST192.168.1.101, MASTER_USERrepl, MASTER_PASSWORDRepl123, MASTER_AUTO_POSITION1; START SLAVE; SHOW SLAVE STATUS\G用MASTER_AUTO_POSITION1时主从自动交换已执行的 GTID 集合不需要手工填MASTER_LOG_FILE和MASTER_LOG_POS。查看复制状态时别只盯Seconds_Behind_Master更可靠的是对比Retrieved_Gtid_Set和Executed_Gtid_Set两个字段差集越大说明从库延迟越多如果 IO 或 SQL 线程不是 Yes直接看Last_IO_Error和Last_SQL_Error定位。这条排查顺序在考试和现场都适用。3.3 半同步复制和高可用题怎么理解参数半同步复制是复制题里另一个高频点。普通异步复制主库提交后不等从库确认半同步要求至少一个从库返回 ACK主库才认为提交完成。5.7 默认使用 AFTER_SYNC 语义主库已写 binlog、等待从库 ACK 之后才提交。参数配置如下[mysqld] plugin-loadrpl_semi_sync_mastersemisync_master.so;rpl_semi_sync_slavesemisync_slave.so rpl_semi_sync_master_enabledON rpl_semi_sync_slave_enabledON rpl_semi_sync_master_timeout1000rpl_semi_sync_master_enabled和rpl_semi_sync_slave_enabled必须成对出现只有主库开、从库不开实际不会进入半同步。rpl_semi_sync_master_timeout单位是毫秒这里等于 1 秒超过这个时间没有 ACK自动降级成异步复制避免主库提交卡死。生产环境里我习惯把超时调到 3000 毫秒给网络抖动留余量但考试题要看题干给的参数值。高可用题常问“failover 前要确认什么”回答里通常包含两个 GTID 集合一致、半同步是否降级、relay log 是否有积压把这些点和参数对应起来比死记步骤更稳。4. 1z0-888 性能优化考点慢查询、explain 和 sys schema 一起看性能优化在 1z0-888 里通常以“变慢 → 怎么查 → 怎么改”的链路出题。先开启慢查询日志拿到慢语句再用 EXPLAIN 分析路径最后用 sys schema 验证等待和锁信息这条顺序在生产环境同样成立。4.1 开启慢查询日志定位问题语句先在会话里开慢查询不用重启实例SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1; SET GLOBAL log_queries_not_using_indexes ON;这组参数把超过 1 秒的语句记入慢日志并且把没有走索引的语句也记下来。相关参数对照如下参数默认值用途slow_query_logOFF慢查询日志总开关long_query_time10阈值单位秒调优阶段常用 1log_queries_not_using_indexesOFF没走索引也记录适合清理低效 SQLmin_examined_row_limit0扫描行数低于该值不记录排查全表扫时常用 1000注意 5.7 没有SET PERSIST这些动态参数重启后会丢验证出问题后记得写回 my.cnf。生产库上开启慢日志后要及时关掉避免日志增长过快。日志积累一段时间后用官方自带的 mysqldumpslow 汇总mysqldumpslow -t 10 -s at /var/lib/mysql/*-slow.log-t 10只显示前 10 条-s at按平均查询时间倒序想看执行次数用-s c。题库如果问“哪条命令分析慢查询”mysqldumpslow 是 5.7 自带答案pt-query-digest 也常用但那是 Percona 工具注意区分。4.2 explain 输出里 DBA 必须看的几个字段EXPLAIN 是分析执行计划不真正执行语句。5.7 还支持EXPLAIN FORMATJSON会给出更细的成本估算。先把常规列的含义记清楚列含义判断方法type访问路径从好到差const、eq_ref、ref、range、index、ALLkey实际选定的索引NULL 表示没走索引rows估算扫描行数与真实行数差距大时先 ANALYZE TABLEExtra附加执行信息Using temporary / Using filesort 通常需要改写 SQL实际跑一条EXPLAIN FORMATJSON SELECT o.id, o.amount FROM orders o JOIN users u ON u.id o.user_id WHERE u.city Shanghai AND o.status 0;返回是嵌套 JSON挑几个关键字段看。截取后的片段大致如下{ access_type: ALL, rows_examined_per_scan: 1000, attached_condition: (examdb.u.city Shanghai) }access_type: ALL说明这条 SQL 在扫描全表数据量大时应该考虑在city上建二级索引。许多人把key和possible_keys搞混前者是优化器真正用的索引后者只是候选列表选择题里经常把只在 possible_keys 中的索引写成“已使用”看到别急着选。4.3 5.7 的 sys schema 与 query cache 差别题sys schema 是 performance_schema 的视图层把难读的原始表包装成 DBA 常用的查询5.7 默认开启 performance_schema所以 sys schema 可以直接用。下面三个查询覆盖常见排障场景SELECT * FROM sys.table_io_waits_summary_by_table WHERE object_schema examdb ORDER BY total_latency DESC LIMIT 5; SELECT query, exec_count, rows_examined, rows_sent FROM sys.statements_with_full_table_scans ORDER BY exec_count DESC LIMIT 5; SELECT * FROM sys.innodb_lock_waits\G第一条找哪张表的 IO 等待最长第二条直接列出正在做全表扫描的语句第三条在锁等待或死锁排障时看阻塞源头。题库如果问 5.7 有哪些优化工具选项里出现 sys schema 的视图名通常是正确项。另一类容易错的题是 query cache。5.7 已经默认关闭并标记废弃8.0 直接移除凡是“开 query cache 提升写多读少性能”的说法都不要选。看到SHOW VARIABLES LIKE query_cache_type返回 OFF 的题想表达的其实是这个机制已经不该依赖。5. 1z0-888 考前自测在 MySQL 5.7 实例上验证每个为什么题库 docx 里的题分两类一类背参数名就能答另一类必须理解行为。对后者我会在本地实例上造一个对照组把答案能复现的都复现出来。这里拿事务隔离级别举例因为它直接关系到备份恢复题也是多选题常客。-- 会话 A建表并写入 CREATE TABLE t_rr(id INT PRIMARY KEY, v INT) ENGINEInnoDB; INSERT INTO t_rr VALUES (1, 10); -- 会话 A开启事务后做一次快照读 START TRANSACTION; SELECT * FROM t_rr WHERE id 1; -- 返回 10 -- 会话 B另一个连接提交更新 UPDATE t_rr SET v 20 WHERE id 1; COMMIT; -- 会话 A再次普通 SELECT仍返回 10 SELECT * FROM t_rr WHERE id 1; -- 会话 A加锁读走当前读返回 20 SELECT * FROM t_rr WHERE id 1 FOR UPDATE; COMMIT;这个实验能解释--single-transaction的原理。REPEATABLE READ 下事务第一次快照读之后的普通 SELECT 都基于同一份快照因此会话 A 看不到会话 B 的已提交更新只有FOR UPDATE这类加锁读走当前读才看到最新值。备份场景正是靠这种一致性快照让长时间导出不影响并发写入也不会导出到一半一半的脏结果。离开实例回到考场把每个题干对照下面几步过一遍能挡掉大部分失分先确认题目版本是 MySQL 5.7。看到 query cache 被推荐基本排除看到 caching_sha2_password 是默认认证插件那不是 5.7 的行为。区分备份对象。混合引擎表要 lock all tables纯 InnoDB 用 single transaction。复制题看主从是否都启用 GTID。配置片段里只有 server-id 没有 gtid_mode说明还在老式位点复制。性能题先看 type 和 key其次看 rows 和 Extra。ALL 且 key 为 NULL 时建索引是优先答案。参数题先把单位圈出来。long_query_time 默认 10 秒rpl_semi_sync_master_timeout 默认 1000 毫秒。最后再给一个实际做法每道题对完答案后在旁边补一句“它正在解决什么场景”。能写清楚场景的选项即使题干换一种问法也能认出来写不出场景的说明只是记住了字面回到实例上补一次验证再继续。本文还有配套的精品资源点击获取