2025年數(shù)據(jù)庫系統(tǒng)工程師考試數(shù)據(jù)庫系統(tǒng)性能優(yōu)化案例分析試卷考試時間：______分鐘總分：______分姓名：______一、選擇題（本大題共25小題，每小題2分，共50分。在每小題列出的四個選項中，只有一項是最符合題目要求的。請將正確選項的字母填在題后的括號內(nèi)。）1.某數(shù)據(jù)庫系統(tǒng)在高峰時段出現(xiàn)響應緩慢，經(jīng)過初步分析懷疑是索引失效導致的。為了驗證這一假設，最直接有效的測試方法是（）。A.查看系統(tǒng)慢查詢?nèi)罩綛.手動刪除所有索引并觀察性能變化C.使用EXPLAIN命令分析特定查詢的執(zhí)行計劃D.增加服務器內(nèi)存并觀察是否改善2.在優(yōu)化一個涉及多表關聯(lián)的查詢時，發(fā)現(xiàn)JOIN條件中的某個字段沒有索引。根據(jù)數(shù)據(jù)庫性能優(yōu)化的基本原則，正確的處理方式是（）。A.立即在該字段上創(chuàng)建索引，但不考慮索引的選擇性B.先分析該字段的數(shù)據(jù)分布，再決定是否創(chuàng)建索引及索引類型C.優(yōu)先優(yōu)化查詢邏輯，暫不創(chuàng)建索引D.創(chuàng)建一個復合索引，包含所有JOIN條件字段3.某應用頻繁執(zhí)行插入操作，且數(shù)據(jù)具有時間序列特性。為了提高插入性能，以下哪種索引策略通常效果最好？（）。A.創(chuàng)建B-Tree索引B.創(chuàng)建哈希索引C.創(chuàng)建覆蓋索引D.使用自增主鍵配合普通索引4.在進行數(shù)據(jù)庫表結構優(yōu)化時，以下哪種做法最有助于提升查詢性能？（）。A.將所有字段設置為NOTNULL約束B.合并多個經(jīng)常一起查詢的表為一個大表C.將長文本字段拆分到單獨的表中進行存儲D.減少表的字段數(shù)量，即使某些字段很少使用5.某數(shù)據(jù)庫系統(tǒng)在執(zhí)行批量更新操作時性能低下，即使添加了索引也無法顯著改善?？赡艿脑蚴牵ǎ?。A.更新操作觸發(fā)了大量索引重建B.數(shù)據(jù)庫配置了過大的innodb_log_file_sizeC.服務器CPU使用率持續(xù)處于峰值D.更新操作涉及的數(shù)據(jù)量小于內(nèi)存大小6.當數(shù)據(jù)庫查詢中出現(xiàn)鎖等待問題時，以下哪種工具最適合用于定位鎖的持有者？（）。A.SHOWPROCESSLIST命令B.EXPLAINANALYZE語句C.MySQLWorkbench的PerformanceSchemaD.iostat系統(tǒng)監(jiān)控工具7.在優(yōu)化慢查詢時，發(fā)現(xiàn)某個查詢使用了LIKE'%keyword%'的模式匹配。為了提升性能，應該考慮（）。A.將LIKE條件改為LIKE'keyword%'或'keyword%'B.在模糊匹配的字段上創(chuàng)建全文索引C.將模糊查詢改為使用JOIN條件D.增加數(shù)據(jù)庫緩存大小8.某應用需要實現(xiàn)秒級的數(shù)據(jù)實時統(tǒng)計功能，以下哪種數(shù)據(jù)庫架構最適合？（）。A.單機關系型數(shù)據(jù)庫B.分區(qū)表+物化視圖C.主從復制+延遲秒級同步D.內(nèi)存數(shù)據(jù)庫+定時任務9.在進行數(shù)據(jù)庫硬件升級時，以下哪種做法對提升寫入性能最有效？（）。A.更換更高頻率的內(nèi)存條B.使用更快的SSD替換HDDC.增加CPU核心數(shù)量D.提高網(wǎng)絡帶寬10.某查詢涉及對百萬級數(shù)據(jù)進行排序操作，即使添加了索引也無法顯著提升性能?？赡艿脑蚴牵ǎ?。A.排序操作未使用索引B.數(shù)據(jù)庫排序算法配置不當C.排序字段存在大量重復值D.服務器內(nèi)存不足11.在優(yōu)化事務性能時，以下哪種做法最有助于減少鎖競爭？（）。A.減少事務隔離級別B.增加事務隔離級別C.使用更小的鎖粒度D.減少事務持續(xù)時間12.某數(shù)據(jù)庫系統(tǒng)在執(zhí)行DDL操作時導致業(yè)務中斷，為了減少對業(yè)務的影響，應該采用（）。A.禁用索引后再執(zhí)行DDLB.使用在線DDL功能C.分批次執(zhí)行DDL操作D.增加DDL操作的并行度13.在進行數(shù)據(jù)庫備份優(yōu)化時，以下哪種策略最有助于減少備份時間？（）。A.增加備份窗口時間B.使用增量備份C.減少備份集大小D.降低備份壓縮率14.某應用需要實現(xiàn)高可靠的數(shù)據(jù)存儲，以下哪種冗余方案最適合？（）。A.主從復制+定期備份B.多地域多副本存儲C.增量備份+熱備份D.數(shù)據(jù)庫集群+自動故障切換15.在優(yōu)化數(shù)據(jù)庫緩存時，以下哪種做法最有效？（）。A.增加緩存命中率的命中率B.減少緩存大小C.使用更快的緩存存儲介質(zhì)D.增加緩存更新頻率16.某查詢涉及多表關聯(lián)，發(fā)現(xiàn)即使添加了合適的索引，性能仍然不佳。可能的原因是（）。A.JOIN順序不合理B.數(shù)據(jù)庫統(tǒng)計信息不準確C.查詢條件未使用索引D.服務器CPU資源不足17.在進行數(shù)據(jù)庫分區(qū)優(yōu)化時，以下哪種分區(qū)方式最適合時間序列數(shù)據(jù)？（）。A.范圍分區(qū)B.整數(shù)分區(qū)C.哈希分區(qū)D.復合分區(qū)18.某應用頻繁執(zhí)行數(shù)據(jù)變更操作，發(fā)現(xiàn)數(shù)據(jù)庫性能隨數(shù)據(jù)量增長而下降。可能的原因是（）。A.索引數(shù)量過多B.數(shù)據(jù)庫緩存配置不當C.服務器內(nèi)存不足D.數(shù)據(jù)庫統(tǒng)計信息過時19.在優(yōu)化數(shù)據(jù)庫寫入性能時，以下哪種做法最有效？（）。A.減少寫入頻率B.使用批量寫入C.增加寫入延遲D.減少寫入數(shù)據(jù)量20.某查詢涉及對文本字段進行全文搜索，為了提升性能，應該（）。A.使用普通B-Tree索引B.使用哈希索引C.創(chuàng)建全文索引D.使用LIKE'%keyword%'模式匹配21.在進行數(shù)據(jù)庫連接池優(yōu)化時，以下哪種配置最有助于提升性能？（）。A.設置過大的連接數(shù)B.使用長連接C.設置合理的連接超時時間D.減少連接池大小22.某數(shù)據(jù)庫系統(tǒng)在執(zhí)行復雜查詢時出現(xiàn)內(nèi)存溢出，以下哪種做法最有效？（）。A.增加數(shù)據(jù)庫緩存大小B.優(yōu)化查詢邏輯C.使用更快的內(nèi)存D.減少查詢數(shù)據(jù)量23.在優(yōu)化數(shù)據(jù)庫鎖性能時，以下哪種做法最有效？（）。A.使用更細粒度的鎖B.減少鎖競爭C.增加鎖等待時間D.使用更復雜的鎖算法24.某應用需要實現(xiàn)高可用性，以下哪種方案最適合？（）。A.主從復制+定期備份B.數(shù)據(jù)庫集群+自動故障切換C.多地域多副本存儲D.增量備份+熱備份25.在進行數(shù)據(jù)庫性能監(jiān)控時，以下哪種指標最關鍵？（）。A.CPU使用率B.內(nèi)存使用率C.磁盤I/OD.網(wǎng)絡流量二、簡答題（本大題共5小題，每小題5分，共25分。請將答案寫在答題紙上對應的位置。）1.描述一下數(shù)據(jù)庫索引失效的常見原因，以及如何避免索引失效。2.在進行數(shù)據(jù)庫表結構優(yōu)化時，如何平衡范式和性能的關系？3.解釋一下數(shù)據(jù)庫鎖的基本類型，以及它們各自的適用場景。4.描述一下數(shù)據(jù)庫緩存的基本原理，以及如何優(yōu)化緩存性能。5.在進行數(shù)據(jù)庫硬件升級時，如何評估升級效果？三、論述題（本大題共4小題，每小題10分，共40分。請將答案寫在答題紙上對應的位置。）1.某電商平臺的訂單系統(tǒng)數(shù)據(jù)庫在促銷活動期間出現(xiàn)嚴重的性能瓶頸，主要表現(xiàn)為訂單插入緩慢、查詢響應變慢。請你分析可能的原因，并提出至少三種具體的優(yōu)化方案，說明每種方案的優(yōu)缺點。2.比較B-Tree索引和哈希索引的異同點，并說明在什么場景下應該選擇使用哪種索引。請結合實際案例進行說明。3.描述一下數(shù)據(jù)庫分區(qū)的基本原理，以及它如何幫助提升數(shù)據(jù)庫性能。請說明不同分區(qū)類型的特點和適用場景，并舉例說明如何在實際應用中使用分區(qū)技術。4.在進行數(shù)據(jù)庫高可用架構設計時，需要考慮哪些關鍵因素？請描述一種常見的高可用架構方案，并說明其工作原理和優(yōu)缺點。四、案例分析題（本大題共2小題，每小題15分，共30分。請將答案寫在答題紙上對應的位置。）1.某金融公司的交易數(shù)據(jù)庫每天處理數(shù)百萬筆交易，為了保證數(shù)據(jù)的一致性和完整性，數(shù)據(jù)庫設置了嚴格的事務隔離級別。但在實際運行過程中，發(fā)現(xiàn)系統(tǒng)在高并發(fā)交易時出現(xiàn)大量鎖等待，導致交易延遲增加。請你分析可能的原因，并提出至少三種解決方案，說明每種方案的優(yōu)缺點和適用場景。2.某電信公司的用戶計費系統(tǒng)數(shù)據(jù)庫使用的是傳統(tǒng)的關系型數(shù)據(jù)庫，隨著用戶數(shù)量和數(shù)據(jù)量的增長，系統(tǒng)性能逐漸下降。為了提升系統(tǒng)性能，公司考慮進行數(shù)據(jù)庫架構升級。請你分析可能的升級方案（如分布式數(shù)據(jù)庫、NoSQL數(shù)據(jù)庫等），并說明每種方案的優(yōu)缺點和適用場景。請結合實際案例進行說明。本次試卷答案如下一、選擇題答案及解析1.C解析：驗證索引失效最直接有效的方法是使用EXPLAIN命令分析查詢的執(zhí)行計劃，查看是否使用了索引以及如何使用的。查看系統(tǒng)慢查詢?nèi)罩究梢园l(fā)現(xiàn)問題但無法直接驗證索引是否有效。手動刪除所有索引會嚴重影響所有查詢性能，不是驗證特定索引失效的好方法。增加服務器內(nèi)存可能改善但不是驗證索引失效的方法。2.B解析：創(chuàng)建索引前應先分析字段的數(shù)據(jù)分布，特別是選擇性高的字段。如果字段選擇性差（重復值多），創(chuàng)建索引效果可能不佳。優(yōu)先優(yōu)化查詢邏輯可能暫時緩解問題但治標不治本。復合索引適用于多條件JOIN，但單字段索引可能更有效。創(chuàng)建覆蓋索引需要所有查詢字段都在索引中，不一定適用于所有場景。3.A解析：對于頻繁插入且具有時間序列特性的數(shù)據(jù)，B-Tree索引通常效果最好，因為其有序性適合時間序列查詢。哈希索引不適合范圍查詢。覆蓋索引適用于查詢字段與索引字段一致的情況。自增主鍵配合普通索引是基礎做法，但不是針對時間序列的優(yōu)化。4.C解析：拆分長文本字段到單獨表可以減少主表的大小，降低I/O消耗，特別是當查詢不需要訪問長文本字段時。將所有字段設為NOTNULL會增加數(shù)據(jù)冗余。合并表會增大鎖競爭范圍。減少字段數(shù)量可能犧牲數(shù)據(jù)完整性。5.A解析：批量更新操作即使加了索引也可能因為頻繁的索引頁分裂和重建導致性能低下。其他選項中，innodb_log_file_size過大不會直接導致更新慢。CPU使用率過高可能是癥狀但不是根本原因。更新量小于內(nèi)存不會觸發(fā)磁盤I/O瓶頸。6.C解析：PerformanceSchema提供了詳細的鎖等待信息，可以查看鎖的持有者、等待者以及鎖的類型和狀態(tài)。SHOWPROCESSLIST主要顯示當前線程狀態(tài)。EXPLAINANALYZE用于查詢執(zhí)行計劃分析。iostat用于監(jiān)控I/O性能。7.A解析：將模糊匹配改為前綴匹配（LIKE'keyword%'）可以利用索引。全文索引適用于全文搜索，但不是所有數(shù)據(jù)庫都支持。JOIN條件不適用于模糊匹配。增加緩存對模糊查詢幫助不大。8.C解析：主從復制+延遲秒級同步可以保證數(shù)據(jù)一致性，延遲秒級滿足實時性要求。單機數(shù)據(jù)庫無法實現(xiàn)秒級實時統(tǒng)計。分區(qū)表+物化視圖適用于離線統(tǒng)計。內(nèi)存數(shù)據(jù)庫可能內(nèi)存不足。9.B解析：使用更快的SSD可以顯著提升磁盤I/O性能，這是寫入密集型操作的關鍵瓶頸。更換內(nèi)存頻率對寫入影響較小。增加CPU核心對計算密集型寫入有幫助，但寫入主要受I/O限制。提高網(wǎng)絡帶寬對數(shù)據(jù)庫寫入影響不大。10.B解析：如果數(shù)據(jù)庫未使用索引進行排序，會進行全表掃描然后排序，性能差。如果使用索引排序，但排序算法配置不當（如使用不當?shù)膬?nèi)存排序策略），也會導致性能問題。大量重復值會使得排序效率降低。內(nèi)存不足會導致排序使用磁盤排序。11.A解析：降低事務隔離級別（如從REPEATABLEREAD降到READCOMMITTED）可以減少鎖持有時間，從而減少鎖競爭。提高隔離級別會增加鎖競爭。更小的鎖粒度可能減少鎖競爭但增加死鎖風險。減少事務持續(xù)時間可以減少鎖持有時間。12.B解析：在線DDL可以在不中斷服務的情況下執(zhí)行表結構變更。禁用索引再執(zhí)行會導致臨時性能下降。分批次執(zhí)行DDL會延長總體變更時間。增加并行度可能增加復雜性。13.B解析：增量備份只備份自上次備份以來的變化數(shù)據(jù)，時間短速度快。增加備份窗口無助于減少時間。減少備份集大小可能影響完整性。降低壓縮率會減少時間但犧牲空間效率。14.B解析：數(shù)據(jù)庫集群+自動故障切換可以提供高可用性和數(shù)據(jù)冗余。主從復制+定期備份存在單點故障風險。多地域多副本成本高。增量備份+熱備份不能保證實時恢復。15.A解析：提高緩存命中率可以最大化利用緩存資源，這是緩存優(yōu)化的核心目標。減少緩存大小會降低性能。使用更快的緩存介質(zhì)成本高。增加更新頻率可能降低緩存命中率。16.A解析：JOIN順序不合理會導致某些JOIN先執(zhí)行導致需要掃描大量數(shù)據(jù)，性能差。數(shù)據(jù)庫統(tǒng)計信息不準確會導致執(zhí)行計劃選擇不當，但不是JOIN順序問題。未使用索引會影響JOIN性能，但不是順序問題。CPU不足是資源問題。17.A解析：范圍分區(qū)特別適合時間序列數(shù)據(jù)，可以根據(jù)時間范圍分割數(shù)據(jù)，便于管理和維護。整數(shù)分區(qū)適用于有序整數(shù)數(shù)據(jù)。哈希分區(qū)適用于無序數(shù)據(jù)的均勻分布。復合分區(qū)可以結合多種分區(qū)鍵。18.A解析：數(shù)據(jù)量增長時，索引數(shù)量過多會導致維護成本增加，鎖競爭加劇。緩存配置不當可能影響讀取性能。內(nèi)存不足會導致磁盤I/O增加。統(tǒng)計信息過時會影響執(zhí)行計劃選擇，但不是寫入性能下降的主要原因。19.B解析：批量寫入可以減少磁盤I/O次數(shù)，顯著提升寫入性能。減少寫入頻率會降低實時性。增加寫入延遲會犧牲實時性。減少寫入數(shù)據(jù)量可能暫時緩解，但不是根本優(yōu)化。20.C解析：全文索引專門用于文本搜索，比普通B-Tree索引更高效。哈希索引不適用于范圍查詢。LIKE'%keyword%'模式匹配會全表掃描。全文索引是專門為此設計的。21.C解析：合理的連接超時時間可以防止慢連接占用資源，同時保證正常業(yè)務連接。設置過大的連接數(shù)會增加資源消耗。長連接適用于頻繁交互，但可能導致資源長時間占用。減小連接池會降低并發(fā)能力。22.B解析：優(yōu)化查詢邏輯可以減少內(nèi)存消耗，是根本解決方法。增加內(nèi)存可能暫時緩解但治標不治本。更快的內(nèi)存對內(nèi)存溢出無直接幫助。減少查詢數(shù)據(jù)量可能暫時緩解，但不是根本優(yōu)化。23.B解析：減少鎖競爭可以通過優(yōu)化事務邏輯、減少事務粒度或調(diào)整隔離級別實現(xiàn)。使用更細粒度的鎖可能增加死鎖風險。增加鎖等待時間會惡化用戶體驗。更復雜的鎖算法不一定更優(yōu)。24.B解析：數(shù)據(jù)庫集群+自動故障切換可以提供高可用性和負載均衡。主從復制+定期備份存在單點故障。多地域多副本成本高。增量備份+熱備份不能保證實時恢復。25.C解析：磁盤I/O是數(shù)據(jù)庫性能的關鍵瓶頸，特別是在寫入密集型場景。CPU使用率高通常是資源瓶頸癥狀。內(nèi)存使用率高可能導致磁盤I/O。網(wǎng)絡流量對數(shù)據(jù)庫內(nèi)部性能影響不大。二、簡答題答案及解析1.索引失效的常見原因及避免方法索引失效常見原因：-使用函數(shù)或表達式操作索引字段（如DATE_FORMAT(date_field,'%Y-%m-%d')）-范圍查詢后使用其他條件（如索引a,b,查詢時使用a且b）-索引列類型不一致（如字符串與數(shù)字比較）-LIKE查詢中前導通配符（LIKE'%keyword'）-聚合函數(shù)作用于非索引列（如SUM(index_field)）避免方法：-確保查詢條件與索引列類型一致-避免在索引列上使用函數(shù)或表達式-盡量使用前綴匹配進行LIKE查詢-對于范圍查詢，確保所有條件都在索引范圍內(nèi)-創(chuàng)建合適的復合索引，覆蓋查詢所需所有字段-定期分析統(tǒng)計信息，確保執(zhí)行計劃選擇正確2.表結構優(yōu)化中的范式與性能平衡范式優(yōu)化需要在以下方面權衡：-第一范式：確保原子性，但過多冗余字段可能增加I/O-第二范式：消除部分依賴，但可能導致冗余數(shù)據(jù)-第三范式：消除傳遞依賴，但可能需要更多JOIN操作平衡方法：-關鍵業(yè)務字段強制非空-經(jīng)常一起查詢的字段放在一起-對于頻繁變更的字段考慮冗余-大型文本、圖片等不適合放在主表-根據(jù)查詢模式設計表結構，而非盲目追求范式-使用分區(qū)表優(yōu)化大數(shù)據(jù)量場景-適當使用冗余字段提升特定查詢性能3.數(shù)據(jù)庫鎖的基本類型及適用場景基本鎖類型：-行鎖：最細粒度鎖，如InnoDB的行鎖適用場景：高并發(fā)事務隔離，如金融交易系統(tǒng)-表鎖：最粗粒度鎖，如MyISAM表鎖適用場景：讀多寫少場景，如報表查詢-間隙鎖：鎖定范圍而非具體行適用場景：防止幻讀，如UPDATEWHEREid>10-記錄鎖：鎖定特定記錄前后適用場景：單行更新操作-共享鎖/排他鎖：共享鎖多讀，排他鎖寫適用場景：遵循兩階段鎖協(xié)議的事務適用場景：-行鎖適用于需要高并發(fā)控制的事務-表鎖適用于讀多寫少且可容忍鎖等待的場景-間隙鎖適用于范圍查詢更新-共享鎖適用于只讀事務-排他鎖適用于寫操作4.數(shù)據(jù)庫緩存的基本原理及優(yōu)化方法基本原理：-LRU（最近最少使用）：淘汰最久未使用頁-LFU（最不經(jīng)常使用）：淘汰使用頻率最低頁-寫策略：Write-through（寫入磁盤后才返回）或Write-back（先寫入緩存，稍后寫磁盤）-緩存分層：OS緩存、數(shù)據(jù)庫緩沖池、應用緩存優(yōu)化方法：-調(diào)整緩沖池大小，一般設為可用內(nèi)存的50-70%-對頻繁查詢的靜態(tài)數(shù)據(jù)使用持久化緩存-使用緩存預熱技術，初始化時加載熱點數(shù)據(jù)-對熱點數(shù)據(jù)使用更合適的緩存策略（如TTL）-減少緩存污染，避免緩存無效數(shù)據(jù)-使用緩存一致性協(xié)議，保證數(shù)據(jù)一致性5.數(shù)據(jù)庫硬件升級效果評估方法評估方法：-基準測試：在升級前后運行相同負載測試-性能指標：響應時間、吞吐量、資源利用率-瓶頸分析：使用監(jiān)控工具定位性能瓶頸-成本效益：比較投入產(chǎn)出比-長期監(jiān)控：觀察升級后性能是否穩(wěn)定評估內(nèi)容：-CPU：檢查是否達到理論峰值-內(nèi)存：觀察緩存命中率變化-磁盤：檢查IOPS和延遲是否改善-網(wǎng)絡：評估數(shù)據(jù)傳輸是否瓶頸-事務量：觀察TPS變化-瓶頸遷移：檢查瓶頸是否轉(zhuǎn)移到其他組件三、論述題答案及解析1.電商訂單系統(tǒng)性能優(yōu)化可能原因：-索引缺失或失效：高并發(fā)插入可能導致索引頁分裂-鎖競爭：大量并發(fā)事務導致表鎖或行鎖競爭-內(nèi)存不足：緩沖池不夠大，頻繁磁盤I/O-寫入放大：批量插入觸發(fā)大量索引更新-分區(qū)不當：數(shù)據(jù)分布不均導致部分分區(qū)壓力過大優(yōu)化方案：-增加索引：為主鍵、外鍵、查詢條件字段加索引-分區(qū)表：按時間范圍或訂單狀態(tài)分區(qū)-讀寫分離：將訂單寫入到從庫-批量插入：使用預編譯語句批量插入-緩存熱點數(shù)據(jù)：緩存訂單狀態(tài)和用戶信息-優(yōu)化事務：減少事務粒度或使用更短的事務-增加硬件：提升CPU、內(nèi)存或磁盤性能優(yōu)缺點：-索引優(yōu)化：提升查詢但增加寫入開銷-分區(qū)表：管理方便但增加復雜度-讀寫分離：提升寫入但可能延遲讀-批量插入：提升寫入但需要業(yè)務支持-緩存：提升讀但需要一致性保障2.B-Tree與哈希索引比較異同點：-B-Tree：有序結構，支持范圍查詢；哈希：無序結構，只支持精確匹配-B-Tree：可重復利用，適合高基數(shù)數(shù)據(jù)；哈希：空間利用率高，適合低基數(shù)數(shù)據(jù)-B-Tree：有高度概念，適合平衡樹；哈希：無高度概念，可能退化成鏈表-B-Tree：支持前綴匹配；哈希：不支持前綴匹配使用場景：B-Tree：-范圍查詢：如BETWEEN,>,<-聚合函數(shù)：GROUPBY-排序：ORDERBY-混合條件：多字段索引哈希：-精確匹配：WHEREid=10-主鍵索引：保證唯一性-高基數(shù)數(shù)據(jù)：重復值少時效率高3.數(shù)據(jù)庫分區(qū)原理及應用基本原理：分區(qū)將表數(shù)據(jù)按規(guī)則分布到不同物理部分，每個部分是邏輯上獨立的表，物理上共享結構。-分區(qū)鍵：決定數(shù)據(jù)如何分配的列-分區(qū)類型：-范圍分區(qū)：按值范圍分區(qū)，如日期-整