2025年數(shù)據(jù)庫技術(shù)考試題及答案一、單項選擇題（每題2分，共20分）1.下列關(guān)于關(guān)系模型完整性約束的描述中，錯誤的是（）A.實體完整性通過主鍵約束實現(xiàn)B.參照完整性通過外鍵約束保證C.用戶定義完整性可通過CHECK約束實現(xiàn)D.所有外鍵必須對應(yīng)被參照表的主鍵2.某電商數(shù)據(jù)庫中，用戶表（user_idPK，name，reg_time）與訂單表（order_idPK，user_idFK，amount，order_time）需頻繁查詢“2024年1月1日以后注冊用戶的訂單金額總和”，最優(yōu)索引策略是（）A.在user表reg_time字段建立索引，在訂單表user_id字段建立索引B.在user表（reg_time,user_id）建立聯(lián)合索引，在訂單表（user_id,order_time）建立聯(lián)合索引C.在訂單表（order_time,user_id,amount）建立覆蓋索引D.在user表user_id字段建立索引，在訂單表（user_id,amount）建立聯(lián)合索引3.若事務(wù)T1對數(shù)據(jù)A加S鎖，事務(wù)T2對數(shù)據(jù)A加X鎖，根據(jù)兩階段鎖協(xié)議（2PL），正確的處理方式是（）A.T2等待T1釋放S鎖后獲取X鎖B.T1立即釋放S鎖，T2獲取X鎖C.T2拒絕加鎖，回滾事務(wù)D.T1與T2并行執(zhí)行，由數(shù)據(jù)庫自動處理沖突4.分布式數(shù)據(jù)庫中，CAP定理指的是（）A.一致性（Consistency）、可用性（Availability）、分區(qū)容忍性（PartitionTolerance）B.正確性（Correctness）、原子性（Atomicity）、持久性（Persistence）C.并發(fā)控制（ConcurrencyControl）、訪問控制（AccessControl）、性能（Performance）D.壓縮（Compression）、聚合（Aggregation）、并行（Parallelism）5.數(shù)據(jù)湖（DataLake）與傳統(tǒng)數(shù)據(jù)倉庫（DataWarehouse）的核心區(qū)別是（）A.數(shù)據(jù)湖存儲結(jié)構(gòu)化數(shù)據(jù)，數(shù)據(jù)倉庫存儲非結(jié)構(gòu)化數(shù)據(jù)B.數(shù)據(jù)湖支持實時分析，數(shù)據(jù)倉庫僅支持批處理C.數(shù)據(jù)湖在存儲階段不強制模式（Schema-on-Read），數(shù)據(jù)倉庫在存儲前定義模式（Schema-on-Write）D.數(shù)據(jù)湖采用行存儲，數(shù)據(jù)倉庫采用列存儲6.列存儲數(shù)據(jù)庫（如ClickHouse）在以下哪種場景中性能最優(yōu)？（）A.實時事務(wù)處理（OLTP）中的增刪改操作B.歷史報表分析（OLAP）中的多維度聚合查詢C.高頻小批量插入的日志記錄D.關(guān)聯(lián)復(fù)雜的多表連接查詢7.防止SQL注入攻擊的最有效方法是（）A.對用戶輸入進行字符串過濾（如替換“;”“--”）B.使用預(yù)編譯語句（PreparedStatement）綁定參數(shù)C.限制數(shù)據(jù)庫用戶的操作權(quán)限D(zhuǎn).在應(yīng)用層對SQL語句進行正則表達式校驗8.多版本并發(fā)控制（MVCC）通過以下哪種方式實現(xiàn)讀不阻塞寫？（）A.為每個數(shù)據(jù)行維護多個版本，讀操作訪問舊版本，寫操作提供新版本B.使用共享鎖（S鎖）和排他鎖（X鎖）的互斥機制C.通過時間戳排序事務(wù)，確保讀操作只能訪問早于當前事務(wù)時間戳的數(shù)據(jù)D.對寫操作加鎖，讀操作無需加鎖9.云數(shù)據(jù)庫（如AWSAurora）的彈性擴展特性主要依賴（）A.基于共享存儲的分布式架構(gòu)，計算節(jié)點可獨立擴展B.單一主節(jié)點加多個從節(jié)點的主從復(fù)制架構(gòu)C.分庫分表的水平擴展方式D.內(nèi)存數(shù)據(jù)庫與磁盤數(shù)據(jù)庫的混合存儲10.文檔型NoSQL數(shù)據(jù)庫（如MongoDB）存儲JSON文檔時，以下描述正確的是（）A.所有文檔必須遵循相同的模式（Schema）B.支持通過點符號（如“user.address.city”）查詢嵌套字段C.不支持索引，查詢性能依賴全表掃描D.事務(wù)僅支持單文檔操作，不支持多文檔原子性二、填空題（每空1分，共20分）1.ER模型的三要素是實體、屬性和（）。2.事務(wù)的ACID特性中，“A”代表（），“D”代表（）。3.B+樹索引中，所有數(shù)據(jù)記錄存儲在（）節(jié)點。4.數(shù)據(jù)庫恢復(fù)的基礎(chǔ)是（），其記錄了所有對數(shù)據(jù)庫的修改操作。5.分布式數(shù)據(jù)庫分片（Sharding）時，分片鍵的選擇需滿足（）（至少答兩點）。6.物化視圖（MaterializedView）與普通視圖的本質(zhì)區(qū)別是（）。7.主從復(fù)制（Master-SlaveReplication）中，從庫可能出現(xiàn)的延遲稱為（）。8.OLAP（聯(lián)機分析處理）的典型操作包括（）、切片、切塊和旋轉(zhuǎn)。9.數(shù)據(jù)脫敏技術(shù)中，將真實姓名替換為“用戶123”的方法屬于（）。10.圖數(shù)據(jù)庫（如Neo4j）的核心數(shù)據(jù)結(jié)構(gòu)是（）和（）。三、簡答題（每題8分，共40分）1.簡述關(guān)系代數(shù)中的自然連接（NaturalJoin）與等值連接（EquiJoin）的區(qū)別，并舉例說明。2.索引優(yōu)化是數(shù)據(jù)庫性能調(diào)優(yōu)的關(guān)鍵，請列舉3條索引設(shè)計的基本原則，并解釋原因。3.分布式事務(wù)需要解決哪些挑戰(zhàn)？請說明兩階段提交（2PC）的基本流程及其局限性。4.NoSQL數(shù)據(jù)庫（如Redis、Cassandra、MongoDB）與關(guān)系型數(shù)據(jù)庫的主要差異有哪些？各舉一個典型應(yīng)用場景。5.數(shù)據(jù)安全是數(shù)據(jù)庫設(shè)計的重要環(huán)節(jié)，請從存儲層、傳輸層、應(yīng)用層三個層面，分別說明可采取的安全措施。四、設(shè)計題（每題10分，共20分）1.設(shè)計一個電商平臺的訂單管理數(shù)據(jù)庫，要求包含用戶、商品、訂單、訂單詳情四個實體。需完成：（1）繪制ER圖（用文字描述實體、屬性及關(guān)系）；（2）給出關(guān)系模式（主碼用下劃線標出，外碼用波浪線標出）。2.某企業(yè)日志系統(tǒng)使用MySQL存儲用戶操作日志，表結(jié)構(gòu)為log（log_idPK，user_id，action，log_time，extra_infoJSON），當前面臨查詢慢（如按user_id和log_time范圍查詢）、存儲成本高的問題。請設(shè)計優(yōu)化方案，包括存儲引擎選擇、索引策略、分區(qū)/分表策略、歸檔機制，并說明理由。五、綜合題（20分）某互聯(lián)網(wǎng)公司計劃將傳統(tǒng)單體數(shù)據(jù)庫遷移至分布式數(shù)據(jù)庫TiDB，業(yè)務(wù)場景為電商交易系統(tǒng)（日活用戶100萬，日均訂單量500萬，涉及用戶、商品、訂單、庫存等核心表）。請回答以下問題：（1）TiDB的架構(gòu)特點是什么？如何支持水平擴展？（2）針對訂單表（order_idPK，user_id，goods_id，amount，status，create_time），如何設(shè)計分片策略？需考慮哪些因素？（3）遷移過程中需解決哪些關(guān)鍵問題（如數(shù)據(jù)一致性、業(yè)務(wù)停機時間）？提出具體解決方案。（4）上線后需監(jiān)控哪些核心指標？當出現(xiàn)主節(jié)點故障時，TiDB如何保證服務(wù)可用性？答案一、單項選擇題1.D（外鍵可對應(yīng)被參照表的唯一鍵，不一定是主鍵）2.B（聯(lián)合索引覆蓋reg_time過濾用戶，user_id關(guān)聯(lián)訂單，order_time過濾時間范圍）3.A（2PL要求事務(wù)在釋放鎖后不能再申請鎖，T1持有S鎖時，T2需等待其釋放后獲取X鎖）4.A（CAP定理的標準定義）5.C（數(shù)據(jù)湖的Schema-on-Read與數(shù)據(jù)倉庫的Schema-on-Write是核心區(qū)別）6.B（列存儲適合OLAP的聚合查詢，減少I/O）7.B（預(yù)編譯語句綁定參數(shù)可徹底避免SQL注入）8.A（MVCC通過多版本實現(xiàn)讀寫不阻塞）9.A（云數(shù)據(jù)庫的彈性擴展依賴共享存儲架構(gòu)，計算節(jié)點獨立擴展）10.B（MongoDB支持嵌套字段查詢，文檔模式靈活）二、填空題1.聯(lián)系2.原子性；持久性3.葉子4.日志（或事務(wù)日志、重做日志）5.數(shù)據(jù)分布均勻、減少跨分片查詢、業(yè)務(wù)相關(guān)性（任意兩點）6.物化視圖存儲實際數(shù)據(jù)，普通視圖是虛擬表（或物化視圖預(yù)計算并存儲結(jié)果）7.復(fù)制延遲（或主從延遲）8.上卷（RollUp）/下鉆（DrillDown）9.匿名化（或脫敏替換）10.節(jié)點（Node）；關(guān)系（Relationship）三、簡答題1.區(qū)別：自然連接自動匹配所有同名屬性列，且結(jié)果中去除重復(fù)列；等值連接需顯式指定連接條件，結(jié)果保留重復(fù)列。舉例：表A（id,name），表B（id,age），自然連接結(jié)果為（id,name,age）；等值連接A.id=B.id結(jié)果為（A.id,name,B.id,age）。2.原則：（1）在高頻查詢的過濾列上建索引（減少全表掃描）；（2）聯(lián)合索引遵循最左前綴法則（索引順序與查詢條件順序匹配）；（3）避免在低基數(shù)列（如性別）建索引（區(qū)分度低，索引效率差）；（4）索引列更新頻繁時需權(quán)衡（索引維護影響寫性能）。（任意3條）3.挑戰(zhàn)：網(wǎng)絡(luò)延遲、節(jié)點故障、數(shù)據(jù)一致性。2PC流程：協(xié)調(diào)者發(fā)送準備（Prepare）請求，參與者反饋是否就緒；協(xié)調(diào)者根據(jù)反饋發(fā)送提交（Commit）或回滾（Abort）指令。局限性：阻塞（參與者故障時協(xié)調(diào)者等待）、單點故障（協(xié)調(diào)者故障導(dǎo)致事務(wù)卡?。?、性能差（多輪網(wǎng)絡(luò)交互）。4.差異：（1）數(shù)據(jù)模型：關(guān)系型（表結(jié)構(gòu)）vsNoSQL（鍵值、列族、文檔、圖）；（2）一致性：關(guān)系型強一致vsNoSQL最終一致；（3）擴展性：關(guān)系型垂直擴展vsNoSQL水平擴展；（4）事務(wù)：關(guān)系型支持多表事務(wù)vsNoSQL多支持單文檔事務(wù)。場景：Redis（緩存）、Cassandra（海量日志）、MongoDB（內(nèi)容管理系統(tǒng)）。5.存儲層：加密存儲（透明數(shù)據(jù)加密TDE）、訪問控制（角色權(quán)限管理）；傳輸層：SSL/TLS加密傳輸、IP白名單；應(yīng)用層：輸入校驗（防止SQL注入）、敏感數(shù)據(jù)脫敏（如手機號打碼）、審計日志（記錄操作軌跡）。四、設(shè)計題1.（1）ER圖描述：用戶（用戶ID，姓名，手機號，注冊時間）；商品（商品ID，名稱，價格，庫存）；訂單（訂單ID，用戶ID，總金額，下單時間，狀態(tài)）；訂單詳情（詳情ID，訂單ID，商品ID，數(shù)量，單價）。關(guān)系：用戶與訂單是1:N（一個用戶多個訂單）；訂單與訂單詳情是1:N（一個訂單多個詳情）；訂單詳情與商品是N:1（多個詳情對應(yīng)一個商品）。（2）關(guān)系模式：用戶（_用戶ID_，姓名，手機號，注冊時間）；商品（_商品ID_，名稱，價格，庫存）；訂單（_訂單ID_，~用戶ID~，總金額，下單時間，狀態(tài)）；訂單詳情（_詳情ID_，~訂單ID~，~商品ID~，數(shù)量，單價）。2.優(yōu)化方案：（1）存儲引擎：使用InnoDB（支持事務(wù)，適合高并發(fā)）；（2）索引：在（user_id,log_time）建立聯(lián)合索引（加速按用戶和時間的查詢），對extra_info中的高頻查詢字段（如“device”）建立JSON索引（如MySQL的JSON_SEARCH或提供列索引）；（3）分區(qū)：按log_time做范圍分區(qū)（如按月分區(qū)），減少單表數(shù)據(jù)量；（4）歸檔：將3個月前的日志歸檔至冷存儲（如對象存儲），僅保留熱數(shù)據(jù)在數(shù)據(jù)庫。理由：聯(lián)合索引覆蓋查詢條件，分區(qū)降低I/O，歸檔減少存儲成本。五、綜合題（1）TiDB架構(gòu)：計算層（TiDBServer）負責SQL解析和執(zhí)行，存儲層（TiKV）基于Raft協(xié)議分布式存儲，PD（PlacementDriver）負責元數(shù)據(jù)管理和調(diào)度。水平擴展：通過添加TiDBServer節(jié)點擴展計算能力，添加TiKV節(jié)點擴展存儲能力，PD自動均衡數(shù)據(jù)分布。（2）分片策略：選擇order_id（全局唯一）或user_id作為分片鍵。若選order_id，需確保分片均勻（如哈希分片）；若選user_id，需考慮用戶訂單分布（避免熱點用戶）。因素：數(shù)據(jù)分布均勻性、跨分片查詢頻率、業(yè)務(wù)查詢模式（如按user_id查詢訂單需本地分片）。（3）關(guān)鍵問題及方案：數(shù)據(jù)一致