2026年数据库工程师练习题附答案

2026年数据库工程师练习题附答案一、单项选择题（每题2分，共20分）1.关系数据库中，若一个关系R的属性集X函数决定属性集Y（X→Y），且不存在X的真子集X'使得X'→Y，则称X→Y为（）。A.部分函数依赖B.完全函数依赖C.传递函数依赖D.多值依赖答案：B2.事务的隔离性通过（）实现，以避免并发操作带来的数据不一致问题。A.日志记录B.锁机制或多版本并发控制（MVCC）C.数据备份D.索引优化答案：B3.某数据库表T包含字段：id（主键）、name（VARCHAR(50)）、age（INT）、create_time（DATETIME）。若频繁查询条件为“nameLIKE'张%'ANDage>25”，最适合创建的索引是（）。A.单列索引（name）B.复合索引（name,age）C.复合索引（age,name）D.全文索引（name）答案：B4.分布式数据库中，CAP定理指的是（）不可同时满足。A.一致性、可用性、分区容忍性B.一致性、原子性、持久性C.可用性、分区容忍性、完整性D.原子性、一致性、隔离性答案：A5.以下关于数据仓库（DataWarehouse）的描述，错误的是（）。A.面向主题的、集成的、非易失的、随时间变化的数据集合B.主要支持OLTP（联机事务处理）C.通常采用星型模型或雪花模型进行维度建模D.数据加载过程包括抽取（Extract）、转换（Transform）、加载（Load）答案：B6.某MySQL数据库出现死锁，最有效的排查方法是（）。A.查看慢查询日志（slowquerylog）B.执行SHOWENGINEINNODBSTATUS命令C.检查二进制日志（binlog）D.分析事务隔离级别设置答案：B7.对于高并发写场景的NoSQL数据库（如HBase），表设计时应避免（）。A.使用递增的主键（如自增ID）B.预分区（Pre-split）表C.设计短而紧凑的RowKeyD.合理设置列族（ColumnFamily）数量答案：A8.数据库备份策略中，“每周日全量备份，每天2:00增量备份”的恢复流程是（）。A.恢复全量备份→按时间顺序恢复增量备份B.恢复最近一次增量备份→恢复全量备份C.直接恢复最近一次增量备份D.恢复全量备份→恢复最近一次增量备份答案：A9.防止SQL注入攻击的最有效措施是（）。A.对用户输入进行转义处理B.使用预编译语句（PreparedStatement）C.限制数据库连接的权限D.定期更新数据库补丁答案：B10.某查询语句执行计划显示“Usingfilesort”，说明（）。A.查询使用了索引扫描B.MySQL需要额外的排序操作，未利用索引完成排序C.查询结果通过临时表存储D.查询涉及多表连接答案：B二、简答题（每题8分，共40分）1.简述事务的ACID特性及其实现技术。答案：ACID是事务的四大特性：原子性（Atomicity）：事务的所有操作要么全部提交，要么全部回滚。通过Undo日志实现，记录事务执行前的数据状态，回滚时恢复。一致性（Consistency）：事务执行前后数据库保持完整性约束。依赖原子性、隔离性和应用层逻辑共同保证。隔离性（Isolation）：多个并发事务的执行互不干扰。通过锁机制（共享锁、排他锁）或MVCC（多版本并发控制）实现。持久性（Durability）：事务提交后，数据变更永久保存。通过Redo日志实现，提交时将日志写入磁盘，崩溃时通过日志恢复。2.比较B+树索引与哈希索引的优缺点及适用场景。答案：B+树索引：优点：支持范围查询（如WHEREage>20）、排序操作；索引节点存储指针，可顺序访问；适合动态数据插入（通过分裂合并保持平衡）。缺点：等值查询效率略低于哈希索引；索引维护成本较高（插入删除需调整树结构）。适用场景：OLTP系统的主键、外键索引，需要范围查询或排序的场景。哈希索引：优点：等值查询（如WHEREid=100）时间复杂度O(1)，效率高；索引结构简单，维护成本低。缺点：不支持范围查询、排序；哈希冲突可能影响性能；无法利用索引完成部分匹配（如LIKE'a%'）。适用场景：OLAP系统中需快速等值匹配的场景，或内存数据库（如Redis）的键值存储。3.分布式数据库中，如何在CAP定理下进行取舍？常见的策略有哪些？答案：CAP定理指出，分布式系统无法同时满足一致性（Consistency）、可用性（Availability）、分区容忍性（PartitionTolerance）。由于网络分区不可避免，实际系统需在C和A之间取舍：强一致性（CP）：优先保证一致性，分区发生时牺牲可用性（如ZooKeeper、HBase）。高可用性（AP）：优先保证可用性，允许短暂不一致（如Cassandra、RedisCluster）。最终一致性（弱一致性）：在AP基础上，通过异步复制实现最终一致（如AmazonDynamoDB）。4.数据仓库维度建模的步骤是什么？星型模型与雪花模型的区别是什么？答案：维度建模步骤：①确定分析主题（如销售分析）；②确定事实表（存储量化指标，如销售额、销售数量）；③确定维度表（描述业务上下文，如时间、地区、商品）；④设计维度层次（如时间维度的年-月-日）；⑤优化存储与查询性能（如维度表冗余、预计算聚合）。星型模型与雪花模型区别：星型模型：事实表直接连接维度表，维度表不进一步规范化（如地区维度包含国家、省份、城市字段）；雪花模型：维度表进一步规范化（如地区维度拆分为国家表、省份表、城市表，通过外键连接）；星型模型查询效率更高（减少连接操作），雪花模型存储空间更节省（减少冗余）。5.设计数据库高可用方案时需考虑哪些要点？主从复制与MHA（MasterHighAvailability）的差异是什么？答案：高可用方案设计要点：①故障检测（如心跳机制、超时判断）；②自动切换（主节点故障时，从节点提升为主节点）；③数据一致性（切换过程中避免数据丢失或冲突）；④业务透明（应用无需修改连接配置）；⑤性能开销（复制延迟、切换时间）。主从复制与MHA的差异：主从复制：仅实现数据同步，需手动干预故障切换；MHA：基于主从复制，增加自动故障检测、从节点选举、主节点提升功能，支持快速切换（通常在30秒内）；MHA支持多主节点场景（如半同步复制），而传统主从复制为单主结构。三、设计题（20分）某电商公司需设计订单系统数据库，要求支持以下业务场景：用户下单（包含多个商品）；按用户ID查询历史订单；按订单ID查询订单详情（含商品信息）；大促期间日订单量可达100万（当前单库已出现写入瓶颈）。请完成以下设计：（1）绘制简化的ER图（用矩形表示实体，菱形表示关系，标注主键和外键）；（2）设计核心数据表结构（字段、类型、约束）；（3）设计索引策略（需说明理由）；（4）设计事务方案（下单过程的事务边界与隔离级别）；（5）提出分库分表策略（需说明分片键与分片规则）。答案：（1）ER图（文字描述）：实体“用户”（User）：主键user_id（INT）；实体“商品”（Goods）：主键goods_id（BIGINT）；实体“订单”（Order）：主键order_id（BIGINT），外键user_id（关联User）；实体“订单详情”（OrderDetail）：主键detail_id（BIGINT），外键order_id（关联Order）、goods_id（关联Goods）；关系：User与Order为1:N（一个用户多个订单）；Order与OrderDetail为1:N（一个订单多个商品）；OrderDetail与Goods为N:1（多个详情项关联一个商品）。（2）核心数据表结构：用户表（t_user）：user_idINTUNSIGNEDAUTO_INCREMENTPRIMARYKEY,usernameVARCHAR(50)UNIQUENOTNULL,create_timeDATETIMEDEFAULTCURRENT_TIMESTAMP商品表（t_goods）：goods_idBIGINTUNSIGNEDAUTO_INCREMENTPRIMARYKEY,goods_nameVARCHAR(100)NOTNULL,priceDECIMAL(10,2)NOTNULL,stockINTNOTNULL订单表（t_order）：order_idBIGINTUNSIGNEDAUTO_INCREMENTPRIMARYKEY,user_idINTUNSIGNEDNOTNULL,total_amountDECIMAL(12,2)NOTNULL,statusTINYINTNOTNULLCOMMENT'0未支付，1已支付，2已发货',create_timeDATETIMEDEFAULTCURRENT_TIMESTAMP,INDEXidx_user_id(user_id)COMMENT'按用户查询订单'订单详情表（t_order_detail）：detail_idBIGINTUNSIGNEDAUTO_INCREMENTPRIMARYKEY,order_idBIGINTUNSIGNEDNOTNULL,goods_idBIGINTUNSIGNEDNOTNULL,quantityINTNOTNULL,unit_priceDECIMAL(10,2)NOTNULL,FOREIGNKEY(order_id)REFERENCESt_order(order_id),FOREIGNKEY(goods_id)REFERENCESt_goods(goods_id),INDEXidx_order_id(order_id)COMMENT'按订单查询详情'（3）索引策略：订单表t_order的user_id字段建立普通索引（idx_user_id）：支持“按用户ID查询历史订单”的高频操作，避免全表扫描。订单详情表t_order_detail的order_id字段建立普通索引（idx_order_id）：支持“按订单ID查询详情”的关联查询，加速订单与详情的连接。商品表t_goods的goods_id字段为主键（聚簇索引）：保证快速定位商品信息。不建议在订单表status字段单独建索引（除非查询条件包含status且数据倾斜），避免索引过多影响写入性能。（4）事务方案：事务边界：从“扣减商品库存”到“提供订单及详情”的完整流程，包含以下操作：①检查商品库存是否充足（SELECTstockFROMt_goodsWHEREgoods_id=?FORUPDATE）；②扣减库存（UPDATEt_goodsSETstock=stock-?WHEREgoods_id=?）；③插入订单（INSERTINTOt_order...）；④插入订单详情（INSERTINTOt_order_detail...）。隔离级别：选择可重复读（REPEATABLEREAD），避免脏读和不可重复读。通过行级锁（FORUPDATE）锁定商品库存行，防止并发下单导致超卖。（5）分库分表策略：分片键：选择user_id作为分片键（因高频查询为“按用户ID查订单”）。分片规则：采用哈希取模分片，例如将数据分散到8个数据库（db0-db7），每个库包含t_order和t_order_detail表。分片算法：shard_id=user_id%8。原因：按user_id分片可保证同一用户的订单数据集中存储，减少跨库查询；哈希取模实现简单，适合均匀分布数据；大促期间可通过水平扩展（增加分片数）提升写入能力。四、综合题（20分）某公司生产环境MySQL数据库（版本8.0，InnoDB引擎）出现以下问题：业务反馈“查询订单详情”变慢（平均响应时间从50ms增至500ms）；监控显示CPU使用率75%（平时50%），磁盘IO利用率90%（平时30%）；慢查询日志中记录了一条SQL：SELECTo.order_id,o.total_amount,d.goods_id,d.quantityFROMt_orderoJOINt_order_detaildONo.order_id=d.order_idWHEREo.user_id=12345ANDo.status=1ORDERBYo.create_timeDESCLIMIT20;请分析可能原因，并提出优化方案（需包含SQL优化、索引优化、存储优化、配置调整等方面）。答案：可能原因分析1.索引缺失或失效：t_order表可能未针对(user_id,status)建立复合索引，导致WHERE条件全表扫描；t_order_detail表的order_id索引可能未覆盖查询字段，需回表。2.数据量增长：订单表或详情表数据量过大（如超1亿条），单表查询性能下降。3.锁竞争：高并发下单导致行锁等待，影响查询响应时间。4.磁盘IO瓶颈：可能因日志写入（如binlog、redolog）或临时表使用导致磁盘读写压力大。5.查询执行计划不合理：MySQL可能选择了全表扫描而非索引扫描，或JOIN操作效率低。优化方案1.SQL与索引优化添加复合索引：在t_order表创建(idx_user_status_time,user_id,status,create_timeDESC)，覆盖WHERE条件（user_id=12345ANDstatus=1）和ORDERBY（create_timeDESC），避免filesort。覆盖索引优化：在t_order_detail表创建(idx_order_cover,order_id)INCLUDE(goods_id,quantity)（MySQL8.0支持INVISIBLEINDEX或通过复合索引实现覆盖），使JOIN操作仅通过索引获取数据，无需回表。重写SQL：若业务允许，限制查询时间范围（如WHERE