2025年信息處理技術(shù)員數(shù)據(jù)庫優(yōu)化考試試題及答案解析1.單選題（每題1分，共30分）1.1某電商訂單表orders(o_id,user_id,sku_id,qty,price,status,pay_time,ship_time,finish_time)，數(shù)據(jù)量8億行，日均新增400萬行。DBA發(fā)現(xiàn)“查詢最近30天已付款訂單”的SQL在MySQL8.0上執(zhí)行耗時(shí)從0.8s暴漲到12s，最可能的原因是A.緩沖池命中率下降B.統(tǒng)計(jì)信息過期導(dǎo)致優(yōu)化器放棄使用pay_time索引C.磁盤碎片率超過95%D.行格式從DYNAMIC變?yōu)镃OMPACT答案：B解析：數(shù)據(jù)量線性增長，但耗時(shí)呈指數(shù)級(jí)上升，通常是因?yàn)閮?yōu)化器誤判。MySQL8.0的costmodel對高并發(fā)場景敏感，若ANALYZETABLE超過7天未執(zhí)行，histogram缺失，優(yōu)化器會(huì)放棄pay_time索引轉(zhuǎn)而全表掃描，造成陡升。1.2PostgreSQL15分區(qū)表采用DeclarativePartitioning，父表log，子表按月。執(zhí)行SELECTFROMlogWHEREtsBETWEEN'2025-04-1500:00:00'AND'2025-04-1600:00:00'時(shí)，EXPLAIN出現(xiàn)“Append(cost=0.00..2.1M)”卻掃描了2025-01到2025-06共6個(gè)子表，其根因是A.分區(qū)鍵ts上創(chuàng)建了btree索引B.查詢條件未使用分區(qū)鍵的表達(dá)式C.子表check約束使用了date_trunc('month',ts)D.父表上存在觸發(fā)器干擾答案：C解析：check約束若寫成CHECK(date_trunc('month',ts)='2025-04-01')，優(yōu)化器無法將常量范圍直接映射到分區(qū)，只能窮舉所有分區(qū)。應(yīng)改為CHECK(ts>='2025-04-01'ANDts<'2025-05-01')，使約束排除生效。1.3在Oracle19c的ExadataX9M上，對一張壓縮表開啟EHCCQueryHigh，同時(shí)設(shè)置PARALLEL64，發(fā)現(xiàn)某并行查詢?nèi)猿霈F(xiàn)“cellsingleblockphysicalread”等待，最合理的優(yōu)化手段是A.增加PARALLEL到128B.關(guān)閉EHCC改用OLTP壓縮C.將表存儲(chǔ)在FlashCache的KEEP池D.降低PARALLEL_DEGREE_POLICY為MANUAL答案：C解析：EHCC在SmartScan過濾率不足時(shí)，會(huì)回退到單塊讀。KEEP池可讓熱點(diǎn)區(qū)常駐閃存，減少磁盤單塊讀。盲目提高并行度反而加劇爭用。1.4某業(yè)務(wù)使用RedisCluster做緩存，key格式為sku:stock:{sku_id}，value為整數(shù)。大促期間出現(xiàn)“MOVED”重定向風(fēng)暴，CPU飆高。以下改造最能根治的是A.將value改為哈希結(jié)構(gòu)B.使用RedisPipeline批量請求C.在客戶端本地緩存slot映射表并開啟crc16預(yù)計(jì)算D.把maxmemory-policy從volatile-lru改為allkeys-lfu答案：C解析：MOVED風(fēng)暴多由客戶端頻繁重建slot映射導(dǎo)致。Jedis-lettuce等組件默認(rèn)懶加載映射表，高并發(fā)下反復(fù)觸發(fā)CLUSTERSLOTS。預(yù)計(jì)算并緩存映射可消除90%以上重定向。1.5某財(cái)務(wù)系統(tǒng)使用SQLServer2022，表voucher(v_id,v_date,amt)建有列存聚集索引。夜間批處理需更新v_date，但出現(xiàn)“TupleMover”阻塞，解決的最佳方案是A.關(guān)閉自動(dòng)合并B.將更新拆成DELETE+INSERTC.改為行存表D.在列存索引上使用COMPRESSION_DELAY=0答案：B解析：列存表更新會(huì)生成deltastore，再等待TupleMover壓縮。大夜批一次性更新百萬行，deltastore膨脹，壓縮線程跟不上。拆成DELETE+INSERT可繞過deltastore，直接生成新rowgroup。1.6MongoDB6.0分片集群，chunk大小默認(rèn)128MB，文檔平均6KB，某集合出現(xiàn)jumbochunk，其文檔數(shù)約為A.2.1萬B.21萬C.210萬D.2100萬答案：B解析：128MB≈134217728B，134217728/6144≈21845，取整約21k，最接近21萬。1.7在MySQL8.0.34中，使用innodb_dedicated_server=ON，主機(jī)內(nèi)存64GB，InnoDBBufferPool自動(dòng)計(jì)算值約為A.48GBB.52GBC.56GBD.60GB答案：C解析：公式min(0.75物理內(nèi)存,物理內(nèi)存-1G)。0.7564=48GB，但上限為物理內(nèi)存-1GB=63GB，取min得48GB；然而8.0.34對dedicatedserver放寬到min(0.875物理內(nèi)存,物理內(nèi)存-1G)，0.87564=56GB，故選C。1.8某時(shí)序庫使用ClickHouse23.8，表采用MergeTree，按toStartOfHour(ts)分區(qū)，按sipHash64(device_id)采樣，發(fā)現(xiàn)磁盤占用比預(yù)期高30%，最可能遺漏的設(shè)置為A.TTL未配置B.compresson_codecs未指定C.index_granularity設(shè)置過大D.parts_to_throw_insert設(shè)置過小答案：B解析：ClickHouse默認(rèn)使用LZ4，未指定列級(jí)codec時(shí)，高壓縮比列（如Float64）未啟用Delta+ZSTD，導(dǎo)致空間浪費(fèi)。1.9某銀行核心系統(tǒng)使用Db211.5，表card_bin(card_no,bin)上建有壓縮索引，執(zhí)行SELECTbinFROMcard_binWHEREcard_no=?仍出現(xiàn)indexscan+fetchfilter，其原因是A.索引未包含include列B.表壓縮導(dǎo)致RIDlist膨脹C.card_no定義為人眼可讀CHAR(19)且右補(bǔ)空格D.統(tǒng)計(jì)信息中CARD=0答案：C解析：CHAR(19)右補(bǔ)空格，輸入?yún)?shù)為VARCHAR，發(fā)生隱式轉(zhuǎn)換，導(dǎo)致索引失效。應(yīng)改為VARCHAR(19)FORBITDATA或使用RTRIM。1.10在OceanBase4.2中，對分區(qū)表做majorfreeze后，發(fā)現(xiàn)sstable的宏塊平均填充率僅65%，最可能觸發(fā)A.merge_thread_count過小B.write_buffer_size過大C.macro_block_size設(shè)置過大D.分區(qū)切分鍵選擇不合理答案：C解析：宏塊默認(rèn)2MB，若表行寬小，65%填充率說明宏塊內(nèi)部空洞大。調(diào)小macro_block_size到512KB可提升填充率至85%以上。1.11某日志系統(tǒng)使用Elasticsearch8.11，索引按天生成，節(jié)點(diǎn)磁盤水位85%觸發(fā)read-only，以下curl指令可立即解除read-only的是A.PUT_cluster/settings-d'{"persistent":{"cluster.routing.allocation.disk.threshold_enabled":false}}'B.PUT_all/_settings-d'{"index.blocks.read_only_allow_delete":null}'C.POST_cache/clearD.POST_forcemerge?max_num_segments=1答案：B解析：read_only_allow_delete是索引級(jí)阻塞，需逐索引解除。A關(guān)閉閾值只能防止再次觸發(fā)，不能解除現(xiàn)有阻塞。1.12某SaaS應(yīng)用使用AmazonAuroraMySQL3.04，讀寫延遲突增，PerformanceInsight顯示“wait/synch/cond/innodb/row_lock”占85%，最合理的排查順序是A.查看information_schema.innodb_trx→innodb_locks→殺掉大事務(wù)B.直接重啟實(shí)例C.升級(jí)實(shí)例規(guī)格D.關(guān)閉binlog答案：A解析：行鎖等待需先定位長事務(wù)，再分析鎖沖突。重啟會(huì)丟失現(xiàn)場，升級(jí)規(guī)格無法解決鎖熱點(diǎn)。1.13在TiDB7.5中，某事務(wù)執(zhí)行UPDATEtSETc=c+1WHEREid=100，id為主鍵，但commit耗時(shí)400ms，最可能的原因是A.未開啟異步提交B.未使用悲觀鎖C.未啟用1PCD.未開啟CoprocessorCache答案：C解析：TiDB默認(rèn)悲觀事務(wù)，若滿足單行+主鍵+無二級(jí)索引，可下沉到TiKV走1PC，commit耗時(shí)從2RTT降至1RTT。未開啟1PC時(shí)，需經(jīng)歷Prewrite+Commit兩階段，RTT翻倍。1.14某游戲服務(wù)器使用Nginx+Lua共享字典緩存排行榜，但凌晨3點(diǎn)出現(xiàn)“LRUexpired”導(dǎo)致排行榜穿透，其根因是A.共享字典內(nèi)存不足B.LuaGC暫停C.緩存key未設(shè)置隨機(jī)過期D.未使用resty.lock答案：C解析：大量key在同一秒過期，引發(fā)并發(fā)回源。應(yīng)在過期時(shí)間上增加隨機(jī)漂移，如ttl+math.random(0,300)。1.15某數(shù)倉使用Hive3.1onTez，小文件平均12MB，NameNodeRPC延遲高，以下參數(shù)組合最能合并小文件的是A.tez.grouping.min-size=128MB,hive.merge.smallfiles.avgsize=256MBB.tez.grouping.max-size=16MB,mapreduce.job.reduces=1000C.hive.exec.reducers.bytes.per.reducer=1GBD.hive.merge.mapfiles=false答案：A解析：tez.grouping.min-size控制vertex輸入合并閾值，hive.merge.smallfiles.avgsize控制最終輸出合并，兩者配合可將12MB小文件合并成128MB大文件，顯著降低RPC。1.16在SQLServer2022中，使用ResumableOnlineIndexCreate構(gòu)建列存索引，中途暫停，系統(tǒng)表記錄狀態(tài)的是A.sys.index_resumable_operationsB.sys.dm_db_index_operational_statsC.sys.index_columnsD.sys.dm_tran_locks答案：A解析：sys.index_resumable_operations記錄可恢復(fù)索引操作的percent_complete、start_time等，支持ALTERINDEXRESUME。1.17某Kafka3.6集群，topicA100分區(qū)，rf=3，min.insync.replicas=2，生產(chǎn)者acks=all，出現(xiàn)“OFFSET_OUT_OF_RANGE”異常，其原因是A.消費(fèi)者組重平衡B.日志段被提前清理C.分區(qū)leader宕機(jī)D.未啟用冪等答案：B解析：acks=all僅保證ISR寫入，不阻止segment刪除。若消費(fèi)者位點(diǎn)過期，拉取已刪除的offset，即報(bào)OUT_OF_RANGE。1.18某圖數(shù)據(jù)庫NebulaGraph3.7，屬性索引采用Elasticsearch，執(zhí)行LOOKUPONplayerWHERE=="Tim"yieldplayer.age出現(xiàn)全表掃描，其原因是A.未重建索引B.索引字段未同步C.查詢語法錯(cuò)誤D.索引分片未分配答案：B解析：Nebula的ES索引為異步管道，寫入后需等待listener同步，若同步延遲，LOOKUP回退storage掃描。1.19在CockroachDB23.2中，某表使用REGIONALBYROW，主鍵為UUID，發(fā)現(xiàn)熱點(diǎn)，應(yīng)改為A.主鍵改為SERIALB.主鍵改為UUID+region列C.主鍵改為hashshardedindexD.關(guān)閉followerreads答案：C解析：UUID隨機(jī)性不足，hashshardedindex將主鍵前綴做shard位，打散range，消除單range寫入熱點(diǎn)。1.20某實(shí)時(shí)數(shù)倉使用Flink1.18，Kafka→ClickHouse，exactly-once依賴兩階段提交，但ClickHouse重啟后數(shù)據(jù)重復(fù)，其原因是A.未開啟冪等寫入B.ClickHouse未開啟事務(wù)表C.Flink未啟用checkpointD.ClickHouse不支持XID回查答案：D解析：ClickHouse23.8僅支持冪等INSERT，不支持外部XID回查，無法參與2PC，需下游去重或替換為冪等表引擎ReplacingMergeTree。1.21在MySQL8.0中，使用GROUPBYu_idORDERBYNULL仍出現(xiàn)filesort，其原因是A.未覆蓋索引B.sql_mode含ONLY_FULL_GROUP_BYC.排序緩沖區(qū)不足D.使用了ROLLUP答案：A解析：ORDERBYNULL僅取消隱式排序，若SELECT列含非聚合列且未覆蓋，仍需臨時(shí)表排序。應(yīng)建復(fù)合索引(u_id,…)覆蓋。1.22某系統(tǒng)使用HBase2.5，RowKey設(shè)計(jì)為reverse(timestamp)+device_id，發(fā)現(xiàn)scan仍出現(xiàn)熱點(diǎn)，其原因是A.未預(yù)分區(qū)B.reverse長度不足C.使用了Long.MaxValue-timestampD.寫入線程過少答案：B解析：reverse僅翻轉(zhuǎn)秒級(jí)，若同一秒內(nèi)百萬設(shè)備，仍落同一region。應(yīng)精確到毫秒并加鹽。1.23某企業(yè)使用PolarDBPostgreSQL14，開啟IMCI（列存索引），執(zhí)行TPCHQ1仍走行存，其原因是A.未設(shè)置enable_imci=onB.IMCI未包含所有列C.統(tǒng)計(jì)信息未收集D.查詢含Array列答案：B解析：IMCI為投影列存，若select列未全部覆蓋，優(yōu)化器放棄使用。1.24在Oracle21c中，使用JSON數(shù)據(jù)類型，創(chuàng)建索引CREATEINDEXidxONt(JSON_VALUE(j,'$.id'RETURNINGNUMBER))，查詢?nèi)匀頀呙瑁湓蚴茿.未使用JSON_TABLEB.未開啟FUNCTION-BASEDINDEXC.查詢條件未使用JSON_VALUED.未收集擴(kuò)展統(tǒng)計(jì)答案：C解析：函數(shù)索引需與查詢表達(dá)式完全匹配，包括RETURNING子句。1.25某系統(tǒng)使用SQLite3.44，WAL模式，讀并發(fā)300，出現(xiàn)“databaseislocked”，其原因是A.未啟用sharedcacheB.寫事務(wù)持有WAL-WRITE鎖C.未開啟mmapD.page_size過小答案：B解析：WAL下寫事務(wù)會(huì)短暫獲取WAL-WRITE排斥鎖，若寫事務(wù)長，讀被阻塞。1.26某時(shí)序數(shù)據(jù)庫InfluxDB2.7，tagcardinality達(dá)800萬，查詢OOM，其原因是A.未開啟TSIB.retention未設(shè)置C.shardduration過長D.未使用flux答案：A解析：高基數(shù)tag導(dǎo)致倒排索引爆炸，需開啟TimeSeriesIndex(TSI)并限制series數(shù)量。1.27某系統(tǒng)使用Doris2.0，BrokerLoad導(dǎo)入ORC文件，出現(xiàn)“failedtogetblocklocation”，其原因是A.ORC含復(fù)雜類型B.HDFS客戶端未配置HAC.BE節(jié)點(diǎn)時(shí)鐘漂移D.未設(shè)置timezone答案：B解析：BrokerLoad需訪問NameNode，若未配置services，無法解析block位置。1.28在Greenplum7.0中，對分區(qū)表執(zhí)行ALTERTABLEEXCHANGEPARTITION失敗，提示“distributionmismatch”，其原因是A.外部表與分區(qū)表分布鍵不同B.未禁用triggerC.外部表含check約束D.未設(shè)置gp_enable_exchange_default_partition答案：A解析：GP要求交換雙方分布鍵一致，否則拒絕。1.29某系統(tǒng)使用Cassandra4.1，表采用TWCS，窗口24h，但磁盤仍持續(xù)增長，其原因是A.gc_grace_seconds過大B.未關(guān)閉compactionC.使用LCSD.未設(shè)置default_time_to_live答案：A解析：TWCS依賴gc_grace_seconds判斷墓碑是否可刪，若設(shè)為10天，窗口內(nèi)數(shù)據(jù)無法及時(shí)清理。1.30某系統(tǒng)使用RocksDB8.7，寫放大達(dá)38倍，最可能的原因是A.level0_stop_writes_trigger過小B.bloom_bits過大C.未開啟dynamic_level_bytesD.使用了FIFO答案：C解析：未開dynamic_level_bytes導(dǎo)致L1大小固定，L0→L1compaction頻繁，寫放大飆升。2.多選題（每題2分，共20分）2.1以下哪些手段可降低MySQL8.0二級(jí)索引的頁分裂頻率A.使用自增列作為主鍵B.設(shè)置innodb_fill_factor=70C.定期OPTIMIZETABLED.使用COMPRESS行格式E.降低page_cleaners答案：A、B、C解析：自增主鍵保證順序插入，fill_factor預(yù)留空間，OPTIMIZE重建索引。COMPRESS與頁分裂無關(guān)，page_cleaners影響刷臟而非分裂。2.2在PostgreSQL15中，以下哪些參數(shù)組合可加速并行索引掃描A.max_parallel_workers_per_gather=8B.parallel_tuple_cost=0C.parallel_setup_cost=0D.effective_cache_size=32GBE.work_mem=1GB答案：A、B、C、E解析：降低并行啟動(dòng)與元組成本，增大work_mem，可提升并行度。effective_cache_size影響優(yōu)化器估算，但不直接加速掃描。2.3以下哪些屬于Oracle19c自動(dòng)索引（AutoIndex）的觸發(fā)條件A.查詢出現(xiàn)全表掃描B.統(tǒng)計(jì)信息過期C.重復(fù)執(zhí)行超過3次D.資源消耗超過閾值E.表小于1000行答案：A、C、D解析：自動(dòng)索引需觀測到重復(fù)高成本SQL，且表足夠大。統(tǒng)計(jì)信息過期與觸發(fā)無關(guān)。2.4以下哪些做法可降低KafkaProducer端到端延遲A.linger.ms=0B.batch.size=0C.compression.type=snappyD.acks=1E.enable.idempotence=true答案：A、D解析：linger=0立即發(fā)送，acks=1減少等待副本。batch=0反而降低吞吐，壓縮增加CPU，冪等與延遲無關(guān)。2.5以下哪些屬于ClickHouseMergeTree的merge并發(fā)控制參數(shù)A.background_pool_sizeB.max_bytes_to_merge_at_max_space_in_poolC.parts_to_delay_insertD.max_replica_delay_for_distributed_queriesE.max_insert_threads答案：A、B、C解析：background_pool_size控制merge線程，max_bytes限制單次merge大小，parts_to_delay_insert觸發(fā)限流。D、E與merge無關(guān)。2.6以下哪些屬于SQLServer2022的集成PolyBase支持的外部數(shù)據(jù)源A.OracleB.TeradataC.MongoDBD.ODBCGenericE.REST答案：A、B、D解析：2022版PolyBase原生支持Oracle、Teradata、ODBCGeneric，MongoDB需第三方便利，REST非關(guān)系型不在列。2.7以下哪些屬于TiDBTiFlash的MPP下推函數(shù)A.COUNTB.SUMC.REGEXPD.JSON_EXTRACTE.WindowFunctionROW_NUMBER答案：A、B、E解析：TiFlash7.5已支持下推窗口函數(shù)，JSON與正則尚未支持。2.8以下哪些屬于HBaseRegion熱點(diǎn)自動(dòng)切分策略A.HexStringSplitB.IncreasingToUpperBoundSplitC.BusyRegionSplitD.DisabledRegionSplitE.SteadyRegionSplit答案：B、C解析：IncreasingToUpperBoundSplit根據(jù)size，BusyRegionSplit根據(jù)請求熱度。HexStringSplit為預(yù)分區(qū)，非自動(dòng)。2.9以下哪些屬于Redis7.2ACL的權(quán)限粒度A.KEYB.PUBSUBC.SCRIPTD.MODULEE.CLUSTER答案：A、B、C、D解析：ACL支持keys、pubsub、script、module級(jí)授權(quán)，cluster為管理命令，歸在ADMIN類。2.10以下哪些屬于Flink1.18Checkpoint對齊屏障（barrier）的優(yōu)化特性A.UnalignedCheckpointB.BufferDebloatingC.ApproximateCheckpointD.ChangelogStateBackendE.LocalRecovery答案：A、B、D解析：Unaligned與BufferDebloating降低barrier對齊時(shí)間，Changelog將增量寫先記日志。Approximate為近似，LocalRecovery為本地恢復(fù)，非對齊優(yōu)化。3.判斷題（每題1分，共10分）3.1MySQL8.0的hashjoin無需索引即可用于非等值連接。答案：錯(cuò)解析：hashjoin僅支持等值連接，非等值需nestedloop。3.2PostgreSQLBRIN索引適合高選擇列。答案：錯(cuò)解析：BRIN適合低選擇、物理相關(guān)性高的列，如時(shí)序。3.3Oracle的In-Memory列存與行存可實(shí)時(shí)雙格式同步。答案：對解析：IMCU與buffercache通過dualformat實(shí)時(shí)維護(hù)。3.4MongoDB復(fù)合索引{a:1,b:1}可完全替代{a:1}。答案：對解析：最左前綴原則，{a:1,b:1}可服務(wù){(diào)a}查詢。3.5RedisCluster的hashslot遷移是原子性的。答案：對解析：遷移通過MULTI/EXEC包裹，原子性。3.6Cassandra的LCS讀放大一定低于STCS。答案：錯(cuò)解析：LCS減少空間放大，但level多，讀放大可能更高。3.7ClickHouse的JOIN默認(rèn)采用hashjoin，且全部在內(nèi)存完成。答案：錯(cuò)解析：右表超max_memory_usage會(huì)落盤。3.8TiDB的悲觀事務(wù)在2PC的prewrite階段即獲取鎖。答案：對解析：悲觀鎖在prewrite前已加，避免沖突。3.9HBase的MOB數(shù)據(jù)建議存儲(chǔ)在WAL中。答案：錯(cuò)解析：MOB超閾值直接寫HFile，不進(jìn)WAL。3.10Flink的exactly-once語義依賴source支持重放。答案：對解析：source需可重放offset，否則無法容錯(cuò)。4.填空題（每空2分，共20分）4.1在MySQL8.0中，使用________命令可在線調(diào)整innodb_buffer_pool_size而無需重啟。答案：SETGLOBALinnodb_buffer_pool_size=32G;4.2PostgreSQL15中，查看分區(qū)裁剪是否生效的系統(tǒng)視圖是________。答案：pg_partitioned_table4.3Oracle19c中，自動(dòng)索引的默認(rèn)任務(wù)名稱是________。答案：SYS_AUTO_INDEX_TASK4.4Redis7.2的functions采用________語言編寫。答案：Lua4.5ClickHouse23.8中，設(shè)置________可讓后臺(tái)merge線程最大占用CPU核心數(shù)為4。答案：background_pool_size=44.6TiDB7.5中，開啟________參數(shù)可將單行事務(wù)優(yōu)化為1PC。答案：tidb_enable_1pc=ON4.7SQLServer2022的Resumable索引創(chuàng)建使用________子句。答案：WITH(RESUMABLE=ON)4.8Cassandra4.1中，設(shè)置________可讓TWCS窗口內(nèi)數(shù)據(jù)在壓縮后立即刪除。答案：unchecked_tombstone_compaction=true4.9Flink1.18的ChangelogStateBackend底層存儲(chǔ)格式為________。答案：RocksDB4.10HBase2.5中，________協(xié)處理器可在region級(jí)別做聚合。答案：AggregateImplementation5.簡答題（每題10分，共20分）5.1某社交平臺(tái)消息表message(msg_id,sender_id,receiver_id,ts,content)，數(shù)據(jù)量日均5億，MySQL8.0單機(jī)，主鍵msg_id，輔助索引(sender_id,ts)?，F(xiàn)發(fā)現(xiàn)“查詢某用戶最近100條私信”需5s，請給出三步優(yōu)化方案并說明原理。答案：第一步，建立覆蓋索引(receiver_id,tsDESC)INCLUDE(sender_id,content)。原理：將過濾+排序+回表三合一，避免filesort與回表，IO降至1%。第二步，按receiver_id分區(qū)，采用RANGECOLUMNS(ts)做二級(jí)分區(qū)，每7天一個(gè)分區(qū)。原理：分區(qū)裁剪使查詢只掃最近7天數(shù)據(jù)，數(shù)據(jù)量從30億降至3.5億。第三步，將content列改為壓縮BLOB，外部存儲(chǔ)于對象存儲(chǔ)，表內(nèi)保留URL。原理：減少行寬，單頁存放更多行，邏輯讀下降70%，同時(shí)利用對象存儲(chǔ)低成本優(yōu)勢。三步疊加，耗時(shí)從5s降至30ms。5.2某電商大促使用RedisCluster緩存庫存，key=sku:stock:{sku_id}，value=整數(shù)。高峰出現(xiàn)“超賣”，請分析原因并給出基于Lua腳本的分布式扣減方案，要求支持事務(wù)回滾與重入。答案：原因：并發(fā)下GET→DECR非原子，競態(tài)條件導(dǎo)致庫存為負(fù)。方案：使用Lua腳本保證原子性，腳本如下：localkey=KEYS[1]localqty=tonumber(ARGV[1])localorderId=ARGV[2]localheld=redis.call('HGET',key..':held',orderId)ifheldthenreturn{0,held}endlocalstock=tonumber(redis.call('GET',key))ifstock>=qtythenredis.call('DECRBY',key,qty)redis.call('HSET',key..':held',orderId,qty)redis.call('EXPIRE',key..':held',900)return{1,qty}elsereturn{-1,stock}end回滾腳本：localkey=KEYS[1]localorderId=ARGV[1]localheld=redis.call('HGET',key..':held',orderId)ifheldthenredis.call('INCRBY',key,tonumber(held))redis.call('HDEL',key..':held',orderId)return1endreturn0客戶端流程：