2025年数据库原理与应用试题及答案

2025年数据库原理与应用试题及答案一、单项选择题（每题2分，共20分）1.在关系数据库中，若属性集X能函数决定属性集Y，且X的任何真子集都不能函数决定Y，则称X对Y的依赖为A.平凡函数依赖 B.部分函数依赖 C.完全函数依赖 D.传递函数依赖答案：C解析：完全函数依赖强调“最小性”，即决定因素不能再缩减。2.某高校选课系统采用MySQL8.0，需保证同一门课在同一学期最多被50名学生选中，最合理的约束实现方式是A.在应用层统计后拒绝 B.使用触发器在插入前检查 C.创建含COUNT()的检查约束 D.采用外键级联答案：B解析：MySQL检查约束对聚合函数无效，触发器可在插入前查询已选人数并抛出SIGNAL。3.关于PostgreSQL的MVCC，下列说法错误的是A.更新操作会生成新版本元组 B.事务ID回卷后旧快照仍可安全读取 C.autovacuum负责回收死元组 D.通过xmin、xmax字段判断可见性答案：B解析：事务ID回卷若未冻结，将导致旧快照误认为未来事务可见，需冻结行。4.在分布式数据库中，采用“两阶段提交”主要解决A.网络分区 B.数据倾斜 C.原子性丧失 D.读性能下降答案：C解析：2PC通过投票与提交阶段保证跨节点事务原子性。5.某表对列c1建立位图索引，最适合的查询条件是A.c1=5 B.c1BETWEEN1AND100 C.c1LIKE'%abc%' D.c1+1=6答案：A解析：位图索引对低基数等值查询效率最高，LIKE和表达式会抑制索引。6.Redis采用跳表实现有序集合，其平均查找复杂度为A.O(1) B.O(logn) C.O(n) D.O(nlogn)答案：B解析：跳表通过多层索引将期望高度控制在logn。7.在MongoDB分片集群里，要使得写入均匀且范围查询高效，应选择的片键是A.单调递增的ObjectId B.低基数枚举字段 C.复合哈希片键 D.时间戳答案：C解析：复合哈希片键既分散写入，又保留前缀查询局部性。8.关于SQLServer的AlwaysEncrypted，正确的是A.数据库引擎可计算加密列的和 B.应用驱动负责加解密 C.列加密后无法建立索引 D.需启用透明数据加密答案：B解析：驱动在客户端完成加解密，引擎仅处理密文，支持确定性加密索引。9.在SparkSQL中，将频繁使用的DataFrame持久化到内存并采用序列化存储，其级别是A.MEMORY_ONLY B.MEMORY_AND_DISK C.MEMORY_ONLY_SER D.DISK_ONLY答案：C解析：MEMORY_ONLY_SER以序列化字节存储，节省空间但牺牲CPU。10.某银行核心系统采用Raft共识，最可能将A.读请求随机路由到任意节点 B.写请求仅转发给Leader C.节点崩溃后需人工合并日志 D.一致性级别设为“最终”答案：B解析：Raft写路径必须经Leader复制日志，读可线性化或过期读。二、多项选择题（每题3分，共15分）11.下列哪些技术可有效降低MySQL主从延迟A.并行复制 B.增大binlog_group_commit_sync_delay C.使用逻辑时钟 D.备库关闭log_slave_updates E.采用半同步复制答案：A、C、E解析：并行复制与逻辑时钟提升回放速度；半同步缩短主库等待时间；B增大延迟，D仅减少磁盘写入但无助延迟。12.关于图数据库Neo4j，正确的有A.节点可带多个标签 B.关系必须有向 C.采用免索引邻接 D.Cypher支持可变长路径匹配 E.存储引擎为B+树答案：A、C、D解析：关系可双向语义；免索引邻接通过双向链表直接存邻接；存储引擎为原生图存储，非B+树。13.在Oracle中，使用RMAN可完成A.增量备份 B.表空间时间点恢复 C.跨平台迁移字节序 D.闪回删除表 E.压缩备份集答案：A、B、C、E解析：闪回删除表使用回收站，无需RMAN。14.关于列式存储，下列说法正确的有A.适合OLAP场景 B.压缩比通常高于行式 C.点查单行所有列代价低 D.向量化执行可提升CPU缓存命中率 E.更新操作一般比行式高效答案：A、B、D解析：列式更新需拆分多列，代价高；点查需组装多列，延迟大。15.在NewSQL系统中，实现可串行化但避免两阶段锁的技术有A.Calvin的确定性事务 B.TiDB的Percolator模型 C.CockroachDB的HLC+SSI D.VoltDB的存储过程排队 E.MongoDB的文档级锁答案：A、C、D解析：Percolator为快照隔离；MongoDB锁非可串行化。三、判断题（每题1分，共10分）16.在关系代数中，选择运算对并运算满足分配律。答案：√解析：σ_p(R∪S)=σ_p(R)∪σ_p(S)。17.任何满足3NF的模式也一定满足BCNF。答案：×解析：存在主属性对码的部分或传递依赖时，3NF可接受但BCNF拒绝。18.Redis的RDB持久化方式在fork子进程时使用了写时复制技术。答案：√解析：fork后父子进程共享内存页，修改时复制，避免瞬时双倍内存。19.在MySQL中，InnoDB的聚簇索引叶节点存储整行数据，因此二级索引无需回表。答案：×解析：二级索引叶节点仅存主键值，需回表获取其余列。20.使用HBase存储时，RowKey设计应避免热点，但无法通过加盐方式解决。答案：×解析：加盐（哈希前缀）可将连续主键离散，消除热点。21.在SQL标准中，FULLOUTERJOIN可用LEFT和RIGHTJOIN再加UNION模拟。答案：√解析：先左连后右连，排除重复内连行。22.分布式事务的Saga模式允许业务通过补偿操作达到最终一致，无需锁定资源。答案：√解析：Saga将长事务拆为局部事务+补偿，牺牲隔离性换可用性。23.图数据库的三角形计数算法复杂度一定低于关系数据库的同等计算。答案：×解析：若关系表已建双向索引且内存充足，优化器可生成高效哈希连接，性能未必低。24.在PostgreSQL中，可通过CREATEEXTENSION引入新访问方法。答案：√解析：访问方法如btree、hash、gin、spgist均以扩展形式存在。25.使用KafkaConnect将MySQLbinlog同步至ElasticSearch属于ETL而非ELT。答案：×解析：数据先抽取转换（过滤、扁平化）再加载，属于ELT范畴。四、简答题（每题8分，共24分）26.描述InnoDB如何通过插入缓冲（ChangeBuffer）优化二级索引的随机IO，并说明其合并过程及触发条件。答案：当非唯一二级索引页不在缓冲池时，InnoDB不立即读取磁盘，而是将更新操作缓存到ChangeBuffer，内存结构为B+树，键为（space_id,page_no）。合并发生在以下场景：1.用户访问该页——缓冲池缺失触发读取，合并缓存条目；2.服务器空闲——后台线程定期扫描，按页合并；3.崩溃恢复——从系统表空间读取IBUF，重放记录；4.页被刷盘——flush前必须合并，保证页一致。合并过程持索引页闩，将缓存的插入、删除标记排序后批量应用，减少随机读。若页被压缩或加密，合并需先解密解压。参数innodb_change_buffer_max_size控制其占缓冲池比例，默认25%。27.解释OceanBase的“日志即数据”架构如何同时降低写入放大与缩短故障恢复时间，并给出与传统LSM-tree的对比。答案：OceanBase将Redolog与MemTable融合，更新仅追加到Clog（CommitLog），内存表即日志回放结果，无需WAL+SSTable双写。对比LSM-tree：1.写入路径——LSM-tree需先写WAL再写MemTable，后期合并至SSTable；OceanBase仅一次Clog追加，写入放大≈1。2.空间放大——LSM-tree分层合并产生多版本SSTable；OceanBase基于多副本共享Clog，仅保留未合并段，空间节省30%。3.恢复时间——LSM-tree需重放WAL并重建MemTable，再异步加载SSTable索引；OceanBase因MemTable即日志状态，重启后仅重放未提交事务，平均恢复时间从分钟级降至秒级。4.读放大——OceanBase通过全局多版本合并器（GC）后台整理，读请求可跨副本并行，避免LSM-tree的层间查找。28.说明Snowflake的混合存储引擎如何利用微分区（Micro-Partition）与列式压缩实现“按需扫描”，并给出查询优化器在剪枝阶段的执行流程。答案：Snowflake将表按90–150MB逻辑大小切分为微分区，每个分区内部列存、压缩、并记录元数据（min/max、计数、位图）。查询优化器执行流程：1.解析SQL生成逻辑计划；2.提取谓词列，与分区元数据匹配，建立候选集；3.利用ZoneMap剪枝——若min/max与谓词无交集，则跳过整个分区；4.对高基数列使用布隆过滤器，进一步剔除误报；5.生成物理计划，仅扫描剩余分区，并下推投影、过滤至存储层；6.执行时通过向量化的列批处理，利用SIMD解压与过滤，减少网络传输。该机制使扫描数据量降至原始3%–8%，兼顾弹性计算与存储分离。五、综合设计题（共31分）29.某电商平台“秒杀”场景，要求库存扣减绝对正确，峰值10万QPS，持续3分钟，商品中心表结构如下：goods(id,stock,version,…)，采用MySQL8.0主从。（1）指出纯MySQL方案面临的两大瓶颈（4分）；（2）设计一种“缓存+队列+数据库”三级方案，保证不超卖且性能满足，需给出缓存结构、队列选型、数据库SQL及异常补偿流程（15分）；（3）若将MySQL替换为TiDB，说明如何基于Percolator模型简化方案，并给出冲突检测SQL示例（6分）；（4）估算三级方案与TiDB方案在3分钟内的总机器成本，假设云主机单价0.4元/小时，给出计算过程（6分）。答案：（1）瓶颈：1.行锁热点——单行库存扣减导致InnoDB排他锁排队，单节点TPS上限约2万；2.主从延迟——从库读易脏读，导致重复售卖。（2）三级方案：缓存层：RedisCluster，每商品key为stock:{itemId}，value=剩余库存；使用Lua脚本保证DECR原子，脚本返回≥0则扣减成功，否则回滚。队列层：Kafkatopic秒杀订单，分区数=商品数×10，保证并行度；成功扣减缓存后发送消息{orderId,itemId,qty,userId,timestamp}，生产幂等启用enable.idempotence=true。数据库：消费组异步批量INSERT…ONDUPLICATEKEYUPDATEstock=stock-VALUES(qty)，WHEREstock>=VALUES(qty)；失败则发送DLQ，触发补偿任务，将缓存INCR回补。异常补偿：定时任务扫描DLQ，校验订单状态，若未支付则回补库存；缓存与DB每30秒对账，差异报警。性能：Redis单分片3万QPS，10万分片4主8从；Kafka3节点可支撑15万写QPS；MySQL8核32G双主互备，批量消费线程16，单批200条，峰值TPS1.2万，满足。（3）TiDB简化：利用Percolator的乐观事务，取消缓存扣减，直接BEGIN；SELECTstock,versionFROMgoodsWHEREid=?FORUPDATE；UPDATEgoodsSETstock=stock-?,version=version+1WHEREid=?ANDversion=?；提交时TiDB自动检测写冲突，若冲突则重试；无需队列，10万并发由TiKV分片自动扩展。冲突检测SQL：BEGIN；@stock,@ver:=SELECTstock,versionFROMgoodsWHEREid=100FORUPDATE；UPDATEgoodsSETstock=@stock-1,version=@ver+1WHEREid=100ANDversion=@ver；COMMIT；若影响行数=0则回滚并提示售罄。（4）成本估算：三级方案：Redis4主8从共12台8G；Kafka3台16G；MySQL2台32G；Consumer4台8G；总计21台。TiDB方案：TiDBServer3台16G；PD3台4G；TiKV6台32G；总计12台。时长0.05小时，三级方案21×0.4×0.05=0.42元；TiDB方案12×0.4×0.05=0.24元；TiDB节省43%。六、查询优化与调优（共20分）30.给定模式：orders(o_id,o_custkey,o_orderdate,o_totalpence,…)分区表，按o_orderdateRANGE分区，2015–2025每年一分区；lineitem(l_orderkey,l_partkey,l_quantity,l_extendedprice,l_discount,l_tax,…)子分区HASH(l_orderkey)16个子分区；需优化查询：SELECTo_custkey,SUM(l_extendedprice(1-l_discount))ASrevenueFROMordersJOINlineitemONo_id=l_orderkeyWHEREo_orderdateBETWEEN'2024-06-01'AND'2024-06-30'ANDl_partkeyIN(SELECTp_partkeyFROMpartWHEREp_nameLIKE'%red%')GROUPBYo_custkeyORDERBYrevenueDESCLIMIT20；（1）列出执行计划可能出现的最大性能陷阱（4分）；（2）给出改写后SQL，利用分区裁剪与索引合并，并说明新建索引的列顺序及原因（8分）；（3）若数据量orders20亿、lineitem80亿，估算使用Spark3.4执行该查询的最小Executor内存及并行度（4分）；（4）说明在PostgreSQL15中如何通过扩展统计对象（extendedstatistics）解决相关列估计误差，给出创建语句（4分）。答案：（1）陷阱：1.子查询未物化，导致lineitem对part多次索引查找；2.分区裁剪失效，因o_orderdate为表达式；3.哈希连接建表过大，缺少过滤下推；4.排序溢出，估算行数少，内存不足。（2）改写：WITHred_partASMATERIALIZED(SELECTp_partkeyFROMpartWHEREp_nameLIKE'%red%')SELECT/+USE_HASH(orderslineitem)LEADING(orderslineitem)/o_custkey,SUM(l_extendedprice(1-l_discount))ASrevenueFROMordersSTRAIG