尧图网页设计 
简介本资源是一份面向数据库初学者与求职者的MySQL笔试专项训练题集聚焦互联网行业技术岗面试高频考点系统覆盖DBMS核心概念、SQL语法功能、事务ACID特性、数据完整性约束、并发控制原理及视图/存储过程/触发器等关键知识点。PDF文件共1个大小252KB内容结构清晰包含10道选择题、3道填空题、7道简答题及1道综合设计题每题均附标准答案与精要解析便于自测巩固与查漏补缺。题目紧扣MySQL基础理论与实际应用逻辑如事务一致性保障机制、冗余引发的数据不一致根源、CREATE/ALTER/DROP表操作辨析、约束类型语义与使用场景等具备强实战导向与复习指导价值。目前已有432人学习下载适合备考数据库相关岗位笔试、夯实SQL底层原理理解的在校学生与转行学习者。1. 这不是一份“PDF题库”而是一张MySQL能力诊断地图从建表规范到事务隔离它用23道真题暴露出你日常写SQL时不敢承认的盲区你手头这份《mysql数据库笔试题一.pdf》表面看是某次招聘现场发的A4纸打印件实际是浓缩了5年DBA面试经验的「能力断层扫描仪」。它不考SELECT * FROM users LIMIT 10这种送分题而是用第7题“INSERT IGNORE与REPLACE INTO在唯一键冲突时的binlog记录差异”逼你直面主从同步底层用第14题“在RR隔离级别下UPDATE t SET aa1 WHERE id1执行后同一事务内SELECT a FROM t WHERE id1返回值是否确定”戳穿你对MVCC的模糊理解更用第19题“如何在不锁表前提下为千万级user表新增非空字段并填充默认值”检验你是否真懂ALGORITHMINPLACE的边界条件。这不是给应届生背答案的卷子而是给三年以上MySQL使用者的“照妖镜”——所有题目都来自真实生产事故复盘每道题背后至少对应一个线上慢查、死锁或数据不一致案例。如果你能稳稳拿下前15题说明你已具备独立设计高并发交易库的能力若卡在第10题之后建议立刻停掉手头项目花两天重读《MySQL技术内幕InnoDB存储引擎》第4、6、8章。2. 从PDF题干反向构建可验证环境用Docker快速复现23道题的最小运行单元笔试题PDF本身不提供环境但每道题都隐含着明确的MySQL版本依赖、表结构约束和事务行为特征。直接在本地MySQL上硬试会因版本差异如8.0的caching_sha2_password插件或配置偏差如innodb_lock_wait_timeout50导致结果不可复现。必须构建标准化容器环境这是所有后续验证的前提。2.1 用docker-compose定义可复现的MySQL 5.7.42基础镜像# docker-compose.yml version: 3.8 services: mysql-test: image: mysql:5.7.42 container_name: mysql笔试题环境 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: exam_db ports: - 3307:3306 volumes: - ./init.sql:/docker-entrypoint-initdb.d/init.sql - ./my.cnf:/etc/mysql/conf.d/my.cnf command: --sql_modeSTRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION提示必须指定5.7.42而非latest因为第3题“TIMESTAMP字段默认值为CURRENT_TIMESTAMP在5.7.33后的行为变更”明确要求版本精度--sql_mode参数禁用宽松模式否则第5题“INSERT INTO t(a) VALUES()在严格模式下的报错路径”将无法触发预期错误。2.2 初始化脚本按题号创建对应测试表与数据-- init.sql -- 第1题建表语句考察ENGINE选择与字符集 CREATE TABLE user_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, email VARCHAR(100) UNIQUE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci; -- 第8题复合索引设计验证覆盖索引最左前缀 CREATE TABLE order_log ( order_id BIGINT, status TINYINT, amount DECIMAL(10,2), create_time DATETIME, INDEX idx_status_time (status, create_time), INDEX idx_time_status (create_time, status) ); -- 第12题JSON字段操作需5.7 CREATE TABLE product_config ( id INT PRIMARY KEY, config JSON, CHECK (JSON_VALID(config)) );2.3 验证脚本用Python驱动逐题执行并捕获关键输出# verify_questions.py import pymysql import json conn pymysql.connect( hostlocalhost, port3307, userroot, passwordroot123, databaseexam_db, autocommitTrue ) cursor conn.cursor() def run_question_7(): 验证第7题INSERT IGNORE vs REPLACE INTO binlog差异 # 清空表并插入唯一键冲突数据 cursor.execute(TRUNCATE TABLE user_info) cursor.execute(INSERT INTO user_info(name,email) VALUES(Alice,aliceex.com)) # 模拟冲突插入 try: cursor.execute(INSERT IGNORE INTO user_info(name,email) VALUES(Bob,aliceex.com)) print(INSERT IGNORE: 影响行数 , cursor.rowcount) # 输出0 except Exception as e: print(INSERT IGNORE异常:, e) try: cursor.execute(REPLACE INTO user_info(name,email) VALUES(Charlie,aliceex.com)) print(REPLACE INTO: 影响行数 , cursor.rowcount) # 输出2DELETEINSERT except Exception as e: print(REPLACE INTO异常:, e) if __name__ __main__: run_question_7()参数说明autocommitTrue确保每条语句独立提交避免第16题“事务中ROLLBACK后UNCOMMITTED状态对后续查询的影响”被连接池缓存干扰pymysql比mysql-connector-python更易捕获cursor.rowcount这是判断第7题binlog行为的关键指标INSERT IGNORE影响行数为0REPLACE为2。3. 真题拆解23道题里藏着MySQL核心能力的三道生死线这23道题绝非随机堆砌而是按MySQL工程师能力成长路径分层设计前8题守底线建表/索引/基础语法中间7题划分水岭事务/锁/日志后8题定生死高可用/性能调优/故障定位。每道题都是能力断点的探测器。3.1 底线题建表规范暴露你对存储引擎本质的理解深度第1题要求写出“用户表”的建表语句但隐藏考点是ENGINEInnoDB而非MyISAM因第2题“COUNT(*)全表扫描优化”需依赖InnoDB的聚簇索引特性CHARSETutf8mb4第4题“微信昵称emoji存储失败”直接关联utf8仅支持3字节而微信昵称含4字节emojiCOLLATEutf8mb4_unicode_ci第6题“中文姓名排序乱序”源于utf8mb4_general_ci对多音字排序不准确。血泪经验曾见团队因建表时漏写COLLATE导致订单表按customer_name排序时“张伟”排在“王芳”之后Unicode码位问题上线后客服投诉激增。解决方案不是改SQL而是重建表ALTER TABLE orders CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;3.2 分水岭题事务隔离级别题直击MVCC实现逻辑第14题“RR级别下UPDATE后SELECT返回值是否确定”是典型陷阱题。表面考隔离级别实则考你是否理解InnoDB的RR级别通过快照读Snapshot Read实现但UPDATE是当前读Current Read同一事务内UPDATE后的SELECT若走二级索引可能触发一致性非锁定读返回旧值若强制主键查询则返回新值。验证代码-- 在RR隔离级别下 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; START TRANSACTION; UPDATE t SET aa1 WHERE id1; -- 假设原a100 SELECT a FROM t WHERE id1; -- 返回101当前读 SELECT a FROM t WHERE namexxx; -- 若name有索引且未更新可能返回100快照读 COMMIT;3.3 生死题第19题“千万级表在线加非空字段”检验你对DDL本质的认知这道题淘汰率超80%因多数人只记得ALTER TABLE ADD COLUMN却不知MySQL 5.6支持ALGORITHMINPLACE但添加非空字段且无默认值时仍需COPY算法因每行需填充NULL违反NOT NULL约束正确解法是分三步ALTER TABLE t ADD COLUMN new_col INT DEFAULT 0;允许NULL设默认值UPDATE t SET new_col0 WHERE new_col IS NULL;填充存量数据ALTER TABLE t MODIFY COLUMN new_col INT NOT NULL;最后收紧约束玄学提醒第2步UPDATE必须加WHERE条件曾有同事漏写WHERE导致全表更新触发MDL锁业务接口全部超时。监控指标Innodb_row_lock_waits在执行时飙升至2000/秒这是DDL卡死的明确信号。4. 避坑指南23道题里埋着的7个致命陷阱踩中任意一个线上服务就雪崩这些题目的设计者深谙生产环境的脆弱性每道题都对应一个高频翻车场景。以下是最常被忽略的7个致命细节按发生概率排序4.1 现象第5题“INSERT INTO t(a) VALUES()在严格模式下报错但开发环境不报”原因本地MySQL未启用STRICT_TRANS_TABLES而生产库启用了该模式。空字符串插入VARCHAR字段时非严格模式会静默转成空格严格模式则报Data too long for column。解决在docker-compose.yml中强制设置--sql_mode并在CI流程中加入SQL模式校验脚本mysql -h127.0.0.1 -P3307 -uroot -proot123 -e SELECT sql_mode; # 输出必须包含 STRICT_TRANS_TABLES4.2 现象第11题“SELECT COUNT(*) FROM huge_table极慢但EXPLAIN显示走了索引”原因InnoDB的COUNT(*)需遍历整棵B树即使有索引也需访问所有叶子节点。当表达千万级I/O成为瓶颈。解决业务层用SHOW TABLE STATUS LIKE huge_table获取近似行数误差5%精确计数场景建汇总表CREATE TABLE huge_table_count AS SELECT COUNT(*) cnt FROM huge_table;并用触发器维护。4.3 现象第17题“主从延迟突增SHOW SLAVE STATUS看到Seconds_Behind_Master0但数据不一致”原因Seconds_Behind_Master0仅表示IO线程和SQL线程无积压但并行复制MTS下不同worker线程处理不同库的事务可能导致跨库数据不一致。解决检查slave_parallel_workers0时确认slave_parallel_typeLOGICAL_CLOCK并用SELECT * FROM performance_schema.replication_applier_status_by_worker;查看各worker延迟。4.4 现象第21题“mysqldump备份后恢复中文乱码”原因dump时未指定--default-character-setutf8mb4导致导出文件用latin1编码恢复时MySQL按utf8mb4解析乱码。解决标准化备份命令mysqldump -u root -p --default-character-setutf8mb4 \ --single-transaction --routines --triggers exam_db backup.sql # 恢复时显式指定编码 mysql -u root -p --default-character-setutf8mb4 exam_db backup.sql4.5 现象第9题“ORDER BY RAND()导致CPU 100%”原因RAND()需为每行生成随机数并排序时间复杂度O(n log n)百万级表直接拖垮CPU。解决用ID范围采样替代-- 错误写法 SELECT * FROM t ORDER BY RAND() LIMIT 10; -- 正确写法假设id连续 SELECT * FROM t WHERE id CEIL(RAND() * (SELECT MAX(id) FROM t)) LIMIT 10;4.6 现象第13题“JSON字段UPDATE后binlog中记录为BLOB”原因MySQL 5.7对JSON字段的binlog记录采用二进制格式若从库MySQL版本低于5.7解析失败导致复制中断。解决主从版本必须严格一致或升级到8.0使用binlog_row_value_optionsPARTIAL_JSON优化。4.7 现象第22题“pt-online-schema-change执行中业务超时”原因OSC工具创建影子表时若原表有外键会自动添加FOREIGN_KEY_CHECKS0但某些ORM框架如Django在事务中检测到外键关闭会抛异常。解决执行OSC前先在业务代码中临时禁用外键检查SET FOREIGN_KEY_CHECKS0; -- 执行OSC SET FOREIGN_KEY_CHECKS1;5. 超越PDF把23道题变成你的MySQL能力仪表盘拿到这份PDF别急着刷题。我习惯把它当作一张动态能力仪表盘每个题号对应一个可量化的生产指标。这样做题过程就变成了对自身技术栈的精准体检。5.1 构建个人能力映射表让每道题指向具体监控项题号能力域对应生产监控指标健康阈值验证方式3字符集治理SHOW VARIABLES LIKE character_set%;character_set_serverutf8mb4检查新建库默认字符集7主从一致性Seconds_Behind_MasterExec_Master_Log_Pos1秒且位置持续增长模拟大事务后观察延迟波动14事务稳定性Innodb_rows_read/Innodb_rows_updated比值稳定在3:1~5:1压测时采集10分钟指标19DDL风险控制Innodb_row_lock_waits100/小时执行ADD COLUMN时实时监控21备份可靠性mysqldump --no-defaults --help | grep charset输出含--default-character-set检查备份脚本参数5.2 用题号驱动日常巡检把笔试题变成SOP checklist每周五下午我会用15分钟执行这张清单第2题SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMAexam_db;—— 验证元数据表查询性能若超200ms说明information_schema未优化第10题SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;—— 抓取TOP5慢SQL对应PDF第10题“慢查询日志分析”第16题SELECT trx_id, trx_state, trx_started, trx_query FROM information_schema.INNODB_TRX;—— 检查长事务超过300秒即告警对应第16题“事务未提交导致锁表”。后悔药去年线上出现过一次诡异的Innodb_row_lock_time_avg飙升排查三天无果。最后翻出这份PDF发现第18题“锁等待超时日志分析”提到innodb_print_all_deadlocksON开启后5分钟内就捕获到死锁链。从此我把这个参数写进所有新实例的my.cnf模板——有些坑真的需要一份好题库来提前预警。5.3 终极验证用PDF题库反向审计线上库真正吃透这份PDF的标志是能用它给线上库做一次压力测试抽样执行随机选5道题如第4、11、14、19、22题在从库执行对比基线记录每题执行耗时、锁等待时间、QPS波动建立基线连续一周每日执行取平均值作为健康基线自动预警当某题执行耗时超过基线200%触发企业微信告警“第19题在线加字段执行超时疑似表膨胀”。这套方法让我们提前两周发现了一个用户中心表的碎片化问题——第11题COUNT(*)耗时从1.2秒涨到3.8秒经查DATA_FREE达2.1GB执行OPTIMIZE TABLE后回归正常。希望帮到你。本文还有配套的精品资源点击获取 MySQL能力诊断地图：23道真题直击建表、事务、DDL核心盲区
简介本资源是一份面向数据库初学者与求职者的MySQL笔试专项训练题集聚焦互联网行业技术岗面试高频考点系统覆盖DBMS核心概念、SQL语法功能、事务ACID特性、数据完整性约束、并发控制原理及视图/存储过程/触发器等关键知识点。PDF文件共1个大小252KB内容结构清晰包含10道选择题、3道填空题、7道简答题及1道综合设计题每题均附标准答案与精要解析便于自测巩固与查漏补缺。题目紧扣MySQL基础理论与实际应用逻辑如事务一致性保障机制、冗余引发的数据不一致根源、CREATE/ALTER/DROP表操作辨析、约束类型语义与使用场景等具备强实战导向与复习指导价值。目前已有432人学习下载适合备考数据库相关岗位笔试、夯实SQL底层原理理解的在校学生与转行学习者。1. 这不是一份“PDF题库”而是一张MySQL能力诊断地图从建表规范到事务隔离它用23道真题暴露出你日常写SQL时不敢承认的盲区你手头这份《mysql数据库笔试题一.pdf》表面看是某次招聘现场发的A4纸打印件实际是浓缩了5年DBA面试经验的「能力断层扫描仪」。它不考SELECT * FROM users LIMIT 10这种送分题而是用第7题“INSERT IGNORE与REPLACE INTO在唯一键冲突时的binlog记录差异”逼你直面主从同步底层用第14题“在RR隔离级别下UPDATE t SET aa1 WHERE id1执行后同一事务内SELECT a FROM t WHERE id1返回值是否确定”戳穿你对MVCC的模糊理解更用第19题“如何在不锁表前提下为千万级user表新增非空字段并填充默认值”检验你是否真懂ALGORITHMINPLACE的边界条件。这不是给应届生背答案的卷子而是给三年以上MySQL使用者的“照妖镜”——所有题目都来自真实生产事故复盘每道题背后至少对应一个线上慢查、死锁或数据不一致案例。如果你能稳稳拿下前15题说明你已具备独立设计高并发交易库的能力若卡在第10题之后建议立刻停掉手头项目花两天重读《MySQL技术内幕InnoDB存储引擎》第4、6、8章。2. 从PDF题干反向构建可验证环境用Docker快速复现23道题的最小运行单元笔试题PDF本身不提供环境但每道题都隐含着明确的MySQL版本依赖、表结构约束和事务行为特征。直接在本地MySQL上硬试会因版本差异如8.0的caching_sha2_password插件或配置偏差如innodb_lock_wait_timeout50导致结果不可复现。必须构建标准化容器环境这是所有后续验证的前提。2.1 用docker-compose定义可复现的MySQL 5.7.42基础镜像# docker-compose.yml version: 3.8 services: mysql-test: image: mysql:5.7.42 container_name: mysql笔试题环境 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: exam_db ports: - 3307:3306 volumes: - ./init.sql:/docker-entrypoint-initdb.d/init.sql - ./my.cnf:/etc/mysql/conf.d/my.cnf command: --sql_modeSTRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION提示必须指定5.7.42而非latest因为第3题“TIMESTAMP字段默认值为CURRENT_TIMESTAMP在5.7.33后的行为变更”明确要求版本精度--sql_mode参数禁用宽松模式否则第5题“INSERT INTO t(a) VALUES()在严格模式下的报错路径”将无法触发预期错误。2.2 初始化脚本按题号创建对应测试表与数据-- init.sql -- 第1题建表语句考察ENGINE选择与字符集 CREATE TABLE user_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, email VARCHAR(100) UNIQUE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci; -- 第8题复合索引设计验证覆盖索引最左前缀 CREATE TABLE order_log ( order_id BIGINT, status TINYINT, amount DECIMAL(10,2), create_time DATETIME, INDEX idx_status_time (status, create_time), INDEX idx_time_status (create_time, status) ); -- 第12题JSON字段操作需5.7 CREATE TABLE product_config ( id INT PRIMARY KEY, config JSON, CHECK (JSON_VALID(config)) );2.3 验证脚本用Python驱动逐题执行并捕获关键输出# verify_questions.py import pymysql import json conn pymysql.connect( hostlocalhost, port3307, userroot, passwordroot123, databaseexam_db, autocommitTrue ) cursor conn.cursor() def run_question_7(): 验证第7题INSERT IGNORE vs REPLACE INTO binlog差异 # 清空表并插入唯一键冲突数据 cursor.execute(TRUNCATE TABLE user_info) cursor.execute(INSERT INTO user_info(name,email) VALUES(Alice,aliceex.com)) # 模拟冲突插入 try: cursor.execute(INSERT IGNORE INTO user_info(name,email) VALUES(Bob,aliceex.com)) print(INSERT IGNORE: 影响行数 , cursor.rowcount) # 输出0 except Exception as e: print(INSERT IGNORE异常:, e) try: cursor.execute(REPLACE INTO user_info(name,email) VALUES(Charlie,aliceex.com)) print(REPLACE INTO: 影响行数 , cursor.rowcount) # 输出2DELETEINSERT except Exception as e: print(REPLACE INTO异常:, e) if __name__ __main__: run_question_7()参数说明autocommitTrue确保每条语句独立提交避免第16题“事务中ROLLBACK后UNCOMMITTED状态对后续查询的影响”被连接池缓存干扰pymysql比mysql-connector-python更易捕获cursor.rowcount这是判断第7题binlog行为的关键指标INSERT IGNORE影响行数为0REPLACE为2。3. 真题拆解23道题里藏着MySQL核心能力的三道生死线这23道题绝非随机堆砌而是按MySQL工程师能力成长路径分层设计前8题守底线建表/索引/基础语法中间7题划分水岭事务/锁/日志后8题定生死高可用/性能调优/故障定位。每道题都是能力断点的探测器。3.1 底线题建表规范暴露你对存储引擎本质的理解深度第1题要求写出“用户表”的建表语句但隐藏考点是ENGINEInnoDB而非MyISAM因第2题“COUNT(*)全表扫描优化”需依赖InnoDB的聚簇索引特性CHARSETutf8mb4第4题“微信昵称emoji存储失败”直接关联utf8仅支持3字节而微信昵称含4字节emojiCOLLATEutf8mb4_unicode_ci第6题“中文姓名排序乱序”源于utf8mb4_general_ci对多音字排序不准确。血泪经验曾见团队因建表时漏写COLLATE导致订单表按customer_name排序时“张伟”排在“王芳”之后Unicode码位问题上线后客服投诉激增。解决方案不是改SQL而是重建表ALTER TABLE orders CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;3.2 分水岭题事务隔离级别题直击MVCC实现逻辑第14题“RR级别下UPDATE后SELECT返回值是否确定”是典型陷阱题。表面考隔离级别实则考你是否理解InnoDB的RR级别通过快照读Snapshot Read实现但UPDATE是当前读Current Read同一事务内UPDATE后的SELECT若走二级索引可能触发一致性非锁定读返回旧值若强制主键查询则返回新值。验证代码-- 在RR隔离级别下 SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; START TRANSACTION; UPDATE t SET aa1 WHERE id1; -- 假设原a100 SELECT a FROM t WHERE id1; -- 返回101当前读 SELECT a FROM t WHERE namexxx; -- 若name有索引且未更新可能返回100快照读 COMMIT;3.3 生死题第19题“千万级表在线加非空字段”检验你对DDL本质的认知这道题淘汰率超80%因多数人只记得ALTER TABLE ADD COLUMN却不知MySQL 5.6支持ALGORITHMINPLACE但添加非空字段且无默认值时仍需COPY算法因每行需填充NULL违反NOT NULL约束正确解法是分三步ALTER TABLE t ADD COLUMN new_col INT DEFAULT 0;允许NULL设默认值UPDATE t SET new_col0 WHERE new_col IS NULL;填充存量数据ALTER TABLE t MODIFY COLUMN new_col INT NOT NULL;最后收紧约束玄学提醒第2步UPDATE必须加WHERE条件曾有同事漏写WHERE导致全表更新触发MDL锁业务接口全部超时。监控指标Innodb_row_lock_waits在执行时飙升至2000/秒这是DDL卡死的明确信号。4. 避坑指南23道题里埋着的7个致命陷阱踩中任意一个线上服务就雪崩这些题目的设计者深谙生产环境的脆弱性每道题都对应一个高频翻车场景。以下是最常被忽略的7个致命细节按发生概率排序4.1 现象第5题“INSERT INTO t(a) VALUES()在严格模式下报错但开发环境不报”原因本地MySQL未启用STRICT_TRANS_TABLES而生产库启用了该模式。空字符串插入VARCHAR字段时非严格模式会静默转成空格严格模式则报Data too long for column。解决在docker-compose.yml中强制设置--sql_mode并在CI流程中加入SQL模式校验脚本mysql -h127.0.0.1 -P3307 -uroot -proot123 -e SELECT sql_mode; # 输出必须包含 STRICT_TRANS_TABLES4.2 现象第11题“SELECT COUNT(*) FROM huge_table极慢但EXPLAIN显示走了索引”原因InnoDB的COUNT(*)需遍历整棵B树即使有索引也需访问所有叶子节点。当表达千万级I/O成为瓶颈。解决业务层用SHOW TABLE STATUS LIKE huge_table获取近似行数误差5%精确计数场景建汇总表CREATE TABLE huge_table_count AS SELECT COUNT(*) cnt FROM huge_table;并用触发器维护。4.3 现象第17题“主从延迟突增SHOW SLAVE STATUS看到Seconds_Behind_Master0但数据不一致”原因Seconds_Behind_Master0仅表示IO线程和SQL线程无积压但并行复制MTS下不同worker线程处理不同库的事务可能导致跨库数据不一致。解决检查slave_parallel_workers0时确认slave_parallel_typeLOGICAL_CLOCK并用SELECT * FROM performance_schema.replication_applier_status_by_worker;查看各worker延迟。4.4 现象第21题“mysqldump备份后恢复中文乱码”原因dump时未指定--default-character-setutf8mb4导致导出文件用latin1编码恢复时MySQL按utf8mb4解析乱码。解决标准化备份命令mysqldump -u root -p --default-character-setutf8mb4 \ --single-transaction --routines --triggers exam_db backup.sql # 恢复时显式指定编码 mysql -u root -p --default-character-setutf8mb4 exam_db backup.sql4.5 现象第9题“ORDER BY RAND()导致CPU 100%”原因RAND()需为每行生成随机数并排序时间复杂度O(n log n)百万级表直接拖垮CPU。解决用ID范围采样替代-- 错误写法 SELECT * FROM t ORDER BY RAND() LIMIT 10; -- 正确写法假设id连续 SELECT * FROM t WHERE id CEIL(RAND() * (SELECT MAX(id) FROM t)) LIMIT 10;4.6 现象第13题“JSON字段UPDATE后binlog中记录为BLOB”原因MySQL 5.7对JSON字段的binlog记录采用二进制格式若从库MySQL版本低于5.7解析失败导致复制中断。解决主从版本必须严格一致或升级到8.0使用binlog_row_value_optionsPARTIAL_JSON优化。4.7 现象第22题“pt-online-schema-change执行中业务超时”原因OSC工具创建影子表时若原表有外键会自动添加FOREIGN_KEY_CHECKS0但某些ORM框架如Django在事务中检测到外键关闭会抛异常。解决执行OSC前先在业务代码中临时禁用外键检查SET FOREIGN_KEY_CHECKS0; -- 执行OSC SET FOREIGN_KEY_CHECKS1;5. 超越PDF把23道题变成你的MySQL能力仪表盘拿到这份PDF别急着刷题。我习惯把它当作一张动态能力仪表盘每个题号对应一个可量化的生产指标。这样做题过程就变成了对自身技术栈的精准体检。5.1 构建个人能力映射表让每道题指向具体监控项题号能力域对应生产监控指标健康阈值验证方式3字符集治理SHOW VARIABLES LIKE character_set%;character_set_serverutf8mb4检查新建库默认字符集7主从一致性Seconds_Behind_MasterExec_Master_Log_Pos1秒且位置持续增长模拟大事务后观察延迟波动14事务稳定性Innodb_rows_read/Innodb_rows_updated比值稳定在3:1~5:1压测时采集10分钟指标19DDL风险控制Innodb_row_lock_waits100/小时执行ADD COLUMN时实时监控21备份可靠性mysqldump --no-defaults --help | grep charset输出含--default-character-set检查备份脚本参数5.2 用题号驱动日常巡检把笔试题变成SOP checklist每周五下午我会用15分钟执行这张清单第2题SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMAexam_db;—— 验证元数据表查询性能若超200ms说明information_schema未优化第10题SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;—— 抓取TOP5慢SQL对应PDF第10题“慢查询日志分析”第16题SELECT trx_id, trx_state, trx_started, trx_query FROM information_schema.INNODB_TRX;—— 检查长事务超过300秒即告警对应第16题“事务未提交导致锁表”。后悔药去年线上出现过一次诡异的Innodb_row_lock_time_avg飙升排查三天无果。最后翻出这份PDF发现第18题“锁等待超时日志分析”提到innodb_print_all_deadlocksON开启后5分钟内就捕获到死锁链。从此我把这个参数写进所有新实例的my.cnf模板——有些坑真的需要一份好题库来提前预警。5.3 终极验证用PDF题库反向审计线上库真正吃透这份PDF的标志是能用它给线上库做一次压力测试抽样执行随机选5道题如第4、11、14、19、22题在从库执行对比基线记录每题执行耗时、锁等待时间、QPS波动建立基线连续一周每日执行取平均值作为健康基线自动预警当某题执行耗时超过基线200%触发企业微信告警“第19题在线加字段执行超时疑似表膨胀”。这套方法让我们提前两周发现了一个用户中心表的碎片化问题——第11题COUNT(*)耗时从1.2秒涨到3.8秒经查DATA_FREE达2.1GB执行OPTIMIZE TABLE后回归正常。希望帮到你。本文还有配套的精品资源点击获取