2025年高頻iossql面試題及答案iOS開(kāi)發(fā)中SQL相關(guān)技能是數(shù)據(jù)持久化模塊的核心能力，以下整理2025年高頻面試問(wèn)題及深度解析：Q1：iOS中使用SQLite時(shí)，F(xiàn)MDB與原生sqlite3API各有什么優(yōu)劣勢(shì)？實(shí)際項(xiàng)目中如何選擇？FMDB基于Objective-C封裝了sqlite3的C語(yǔ)言接口，優(yōu)勢(shì)在于：①簡(jiǎn)化API，用OC方法替代繁瑣的C函數(shù)（如executeUpdate替代sqlite3_prepare_v2+sqlite3_step）；②自動(dòng)處理內(nèi)存管理（如自動(dòng)釋放stmt）；③線程安全支持（FMDatabaseQueue通過(guò)GCD隊(duì)列管理多線程操作）；④結(jié)果集解析方便（FMResultSet封裝了字段類型轉(zhuǎn)換）。劣勢(shì)是增加了一層封裝開(kāi)銷，極端性能敏感場(chǎng)景可能不如原生API；部分復(fù)雜操作（如自定義busyhandler）需要通過(guò)rawSQL實(shí)現(xiàn)。原生sqlite3API優(yōu)勢(shì)：①零封裝開(kāi)銷，適合需要極致性能的場(chǎng)景（如百萬(wàn)級(jí)數(shù)據(jù)批量寫(xiě)入）；②完全控制SQL執(zhí)行流程（如手動(dòng)管理stmt重用）；③支持更底層的配置（如PRAGMA指令的實(shí)時(shí)調(diào)整）。劣勢(shì)：①代碼冗余（需手動(dòng)處理內(nèi)存釋放、錯(cuò)誤碼判斷）；②線程安全需完全手動(dòng)管理（需結(jié)合GCD或NSOperationQueue）；③結(jié)果集解析需手動(dòng)處理字段類型（如通過(guò)sqlite3_column_text獲取字符串）。選擇建議：業(yè)務(wù)型項(xiàng)目?jī)?yōu)先FMDB（開(kāi)發(fā)效率高，減少錯(cuò)誤）；工具類/性能敏感型項(xiàng)目（如日志系統(tǒng)）可混合使用（核心寫(xiě)入用原生API，查詢用FMDB）；需注意FMDB3.0+已支持Swift，Swift項(xiàng)目可選擇FMDB或GRDB（另一種Swift友好的封裝庫(kù)）。Q2：CoreData的NSPersistentContainer默認(rèn)包含哪些組件？如何優(yōu)化NSFetchRequest的查詢性能？NSPersistentContainer整合了CoreData三大核心組件：NSManagedObjectModel：數(shù)據(jù)模型描述（.xcdatamodeld文件編譯后的產(chǎn)物）；NSPersistentStoreCoordinator：負(fù)責(zé)連接存儲(chǔ)（默認(rèn)SQLite），管理模型與存儲(chǔ)的映射；NSManagedObjectContext：管理對(duì)象的生命周期，處理持久化操作（插入、刪除、更新）。NSFetchRequest優(yōu)化策略：①限制返回字段：使用propertiesToFetch指定僅需要的屬性（避免加載全字段），配合resultType=NSDictionaryResultType直接獲取字典；②分頁(yè)查詢：設(shè)置fetchLimit（每頁(yè)數(shù)量）和fetchOffset（偏移量），避免一次性加載大量數(shù)據(jù)；③預(yù)取關(guān)聯(lián)對(duì)象：對(duì)關(guān)系型數(shù)據(jù)使用includesSubentities（是否包含子實(shí)體）和includesPropertyValues（是否加載屬性值），結(jié)合fetchBatchSize（批量加載大?。﹥?yōu)化關(guān)聯(lián)查詢；④索引支持：在模型中為常查詢的屬性添加索引（模型編輯器中勾選“Indexed”），CoreData會(huì)自動(dòng)在SQLite表中創(chuàng)建索引；⑤使用謂詞優(yōu)化：避免在謂詞中使用函數(shù)（如SUBSTRING）或計(jì)算（如age+1>20），這些會(huì)導(dǎo)致全表掃描；優(yōu)先使用范圍查詢（BETWEEN）或等式查詢；⑥禁用自動(dòng)更新：對(duì)只讀查詢?cè)O(shè)置includesPendingChanges=NO，避免上下文中未提交的變更影響結(jié)果；⑦分析執(zhí)行計(jì)劃：通過(guò)context.persistentStoreCoordinator?.managedObjectIDForURIRepresentation(...)獲取底層SQL，結(jié)合sqlite3_analyzer工具分析查詢效率。Q3：如何處理iOS多線程環(huán)境下的數(shù)據(jù)庫(kù)并發(fā)問(wèn)題？FMDB和CoreData的解決方案有何不同？多線程并發(fā)的核心問(wèn)題是SQLite的寫(xiě)鎖機(jī)制（同一時(shí)間僅允許一個(gè)寫(xiě)操作），處理不當(dāng)會(huì)導(dǎo)致SQLITE_BUSY錯(cuò)誤或數(shù)據(jù)損壞。FMDB方案：禁止多線程共享FMDatabase實(shí)例（其非線程安全）；使用FMDatabaseQueue管理隊(duì)列，所有數(shù)據(jù)庫(kù)操作通過(guò)queueinDatabase:或inTransaction:提交到串行隊(duì)列，確保操作順序執(zhí)行；對(duì)于讀多寫(xiě)少場(chǎng)景，可配合FMDatabase的readOnly屬性創(chuàng)建只讀實(shí)例（共享讀鎖），但需注意寫(xiě)操作仍需通過(guò)隊(duì)列。CoreData方案：上下文（NSManagedObjectContext）的線程親和性：每個(gè)線程使用獨(dú)立上下文（根據(jù)concurrencyType設(shè)置：mainQueue/privateQueue）；主從上下文模式：主線程使用mainQueueConcurrencyType上下文，后臺(tái)線程使用privateQueueConcurrencyType上下文，通過(guò)parentContext建立父子關(guān)系，后臺(tái)上下文保存（save:）后，主上下文通過(guò)mergeChangesFromContextDidSaveNotification合并變更；避免跨線程傳遞NSManagedObject實(shí)例（其非線程安全），需通過(guò)objectID（可跨線程）重新獲取實(shí)例；高級(jí)場(chǎng)景可使用NSPersistentStoreCoordinator的performBlock:方法直接操作存儲(chǔ)層，但需謹(jǐn)慎處理鎖。關(guān)鍵差異：FMDB通過(guò)GCD隊(duì)列實(shí)現(xiàn)操作序列化，CoreData通過(guò)上下文的線程隔離+變更合并實(shí)現(xiàn)并發(fā)安全，后者更適合復(fù)雜對(duì)象圖的多線程操作。Q4：SQLite的事務(wù)機(jī)制如何提升寫(xiě)入性能？實(shí)際使用中需要注意哪些問(wèn)題？SQLite默認(rèn)是自動(dòng)提交模式（每個(gè)INSERT/UPDATE/DELETE語(yǔ)句自動(dòng)開(kāi)啟并提交事務(wù)），頻繁單條寫(xiě)入會(huì)導(dǎo)致大量磁盤(pán)IO（每次提交需寫(xiě)入WAL日志并同步）。開(kāi)啟顯式事務(wù)后，多條操作在一個(gè)事務(wù)中執(zhí)行，僅最后提交時(shí)同步磁盤(pán)，顯著減少I(mǎi)O次數(shù)。測(cè)試顯示，百萬(wàn)條數(shù)據(jù)插入時(shí)，事務(wù)模式比非事務(wù)模式快約100倍。注意事項(xiàng)：①事務(wù)范圍控制：避免事務(wù)過(guò)大（如包含上萬(wàn)條操作），長(zhǎng)時(shí)間持有寫(xiě)鎖可能導(dǎo)致其他線程阻塞（觸發(fā)SQLITE_BUSY）；②異常處理：事務(wù)中若發(fā)生錯(cuò)誤（如約束沖突），必須回滾（rollback）而非直接終止，否則數(shù)據(jù)庫(kù)可能進(jìn)入“事務(wù)掛起”狀態(tài)，后續(xù)操作失敗；③嵌套事務(wù)：SQLite不支持真正的嵌套事務(wù)，多次BEGIN會(huì)被視為單層事務(wù)，COMMIT僅提交最外層；④WAL模式影響：?jiǎn)⒂肳AL（PRAGMAjournal_mode=WAL）后，事務(wù)提交更快（無(wú)需同步主數(shù)據(jù)庫(kù)文件），但需注意WAL文件的自動(dòng)清理（通過(guò)PRAGMAwal_checkpoint）；⑤CoreData中的事務(wù)：CoreData的save:方法默認(rèn)以事務(wù)方式提交，多次對(duì)同一上下文調(diào)用insert/delete后統(tǒng)一save可自動(dòng)利用事務(wù)。Q5：如何防范iOS中SQLite的SQL注入攻擊？實(shí)際開(kāi)發(fā)中容易踩的坑有哪些？SQL注入的本質(zhì)是將用戶輸入的數(shù)據(jù)當(dāng)作SQL代碼執(zhí)行，防范核心是使用參數(shù)化查詢（預(yù)編譯語(yǔ)句），而非字符串拼接。正確做法：原生API：使用sqlite3_prepare_v2編譯帶?占位符的SQL語(yǔ)句，通過(guò)sqlite3_bind_系列函數(shù)綁定參數(shù)（如sqlite3_bind_text(stmt,1,username.UTF8String,-1,SQLITE_TRANSIENT)）；FMDB：使用executeUpdate:@"INSERTINTOuser(name)VALUES(?)",username;或帶字典的executeUpdate:withParameterDictionary:方法；CoreData：謂詞（NSPredicate）自動(dòng)使用參數(shù)化查詢（如[NSPredicatepredicateWithFormat:@"name=%@",username]），底層會(huì)轉(zhuǎn)換為參數(shù)綁定。常見(jiàn)誤區(qū)：①認(rèn)為“數(shù)據(jù)來(lái)自內(nèi)部就安全”：即使數(shù)據(jù)來(lái)自應(yīng)用內(nèi)部（如用戶輸入的備注字段），仍可能包含特殊字符（如單引號(hào)）導(dǎo)致SQL語(yǔ)法錯(cuò)誤或注入；②手動(dòng)轉(zhuǎn)義引號(hào)：如將單引號(hào)替換為兩個(gè)單引號(hào)（'→''），但這種方法易遺漏其他特殊字符（如分號(hào)；），且不同數(shù)據(jù)庫(kù)轉(zhuǎn)義規(guī)則不同，參數(shù)化查詢是更可靠的方案；③錯(cuò)誤使用字符串拼接：例如[NSStringstringWithFormat:@"SELECTFROMuserWHEREname='%@'",username]，這種寫(xiě)法在username包含'時(shí)會(huì)破壞SQL結(jié)構(gòu)（如輸入O'Neil會(huì)變成WHEREname='O'Neil'，導(dǎo)致語(yǔ)法錯(cuò)誤或注入）；④動(dòng)態(tài)表名/字段名：參數(shù)化查詢不支持表名或字段名作為參數(shù)（因?yàn)轭A(yù)編譯階段需確定表結(jié)構(gòu)），此時(shí)需手動(dòng)校驗(yàn)白名單（如僅允許已知的表名），禁止直接使用用戶輸入。Q6：iOS數(shù)據(jù)庫(kù)遷移（Schema變更）的常見(jiàn)場(chǎng)景有哪些？如何實(shí)現(xiàn)輕量級(jí)遷移和手動(dòng)遷移？常見(jiàn)遷移場(chǎng)景：添加字段（如用戶表新增“avatarUrl”字段）；刪除字段（如廢棄“oldPhone”字段）；修改字段類型（如“age”從INTEGER改為T(mén)EXT）；重命名字段/表；新增關(guān)聯(lián)關(guān)系（如用戶與訂單的一對(duì)多關(guān)系）。輕量級(jí)遷移（自動(dòng)遷移）：適用于簡(jiǎn)單變更，CoreData可自動(dòng)提供映射模型。需滿足以下條件：新增字段（可為NULL或有默認(rèn)值）；刪除字段（非必填字段）；重命名字段（通過(guò)模型的renamingIdentifier屬性標(biāo)記舊名稱）；變更字段類型（需兼容，如INTEGER→REAL）。實(shí)現(xiàn)步驟：1.在Xcode中修改數(shù)據(jù)模型（.xcdatamodeld），并創(chuàng)建新版本（Editor→AddModelVersion）；2.設(shè)置當(dāng)前版本（選中模型文件→右側(cè)屬性面板→CurrentVersion）；3.配置持久化存儲(chǔ)選項(xiàng)：```objcNSPersistentStoreDescriptiondesc=[NSPersistentStoreDescriptionnew];desc.shouldMigrateStoreAutomatically=YES;//自動(dòng)遷移desc.shouldInferMappingModelAutomatically=YES;//自動(dòng)推斷映射模型```手動(dòng)遷移：復(fù)雜變更（如跨多個(gè)版本遷移、字段邏輯轉(zhuǎn)換）需自定義映射模型（NSEntityMapping）和遷移策略（NSEntityMigrationPolicy）。步驟：1.創(chuàng)建舊模型（v1）和新模型（v2）；2.新建映射模型（.xcmappingmodel），配置實(shí)體映射關(guān)系；3.自定義遷移策略類（繼承NSEntityMigrationPolicy），重寫(xiě)關(guān)鍵方法（如createDestinationInstancesForSourceInstance:entityMapping:manager:error:）處理數(shù)據(jù)轉(zhuǎn)換；4.加載自定義映射模型，替換自動(dòng)遷移：```objcNSURLmappingURL=[[NSBundlemainBundle]URLForResource:@"V1ToV2"withExtension:@"xcmappingmodel"];NSMappingModelmapping=[NSMappingModelmappingModelFromBundles:@[[NSBundlemainBundle]]forSourceModel:sourceModeldestinationModel:destModel];NSErrorerror;BOOLsuccess=[coordinatormigratePersistentStore:storefromURL:storeURLoptions:@{NSMigratePersistentStoresAutomaticallyOption:@NO}withMappingModel:mappingtoURL:newStoreURLstoreType:NSSQLiteStoreTypeerror:&error];```注意：遷移前需備份原數(shù)據(jù)庫(kù)（通過(guò)復(fù)制文件），遷移過(guò)程中避免用戶操作（可顯示加載界面），并在測(cè)試時(shí)覆蓋所有版本升級(jí)路徑（如v1→v3需測(cè)試v1→v2→v3和v1→v3直接遷移）。Q7：如何優(yōu)化SQLite數(shù)據(jù)庫(kù)的存儲(chǔ)空間？大字段（如圖像、視頻）應(yīng)該存儲(chǔ)在數(shù)據(jù)庫(kù)還是文件系統(tǒng)？存儲(chǔ)空間優(yōu)化策略：①字段類型優(yōu)化：使用最小必要類型（如TINYINT替代INTEGER存儲(chǔ)布爾值），避免TEXT存儲(chǔ)數(shù)字（增加索引開(kāi)銷）；②啟用壓縮：集成SQLCipher時(shí)可開(kāi)啟壓縮（需SQLite編譯時(shí)啟用ZLIB支持），或?qū)LOB字段手動(dòng)壓縮（如用NSData的gzip壓縮）；③清理冗余數(shù)據(jù)：定期刪除過(guò)期緩存（如設(shè)置maxAge=7天），使用DELETE+VACUUM命令回收空間（VACUUM會(huì)重建數(shù)據(jù)庫(kù)文件，可能耗時(shí)）；④避免NULL字段：SQLite對(duì)NULL字段仍有存儲(chǔ)開(kāi)銷（1字節(jié)），可為字段設(shè)置默認(rèn)值（如DEFAULT''）避免NULL；⑤使用WAL模式：WAL文件比傳統(tǒng)回滾日志更緊湊，且自動(dòng)截?cái)嗯f日志。大字段存儲(chǔ)決策：小于100KB的二進(jìn)制數(shù)據(jù)（如小圖標(biāo)、JSON配置）：可存儲(chǔ)為BLOB字段，優(yōu)勢(shì)是原子性（隨事務(wù)提交）、查詢方便（可直接關(guān)聯(lián)其他字段）；大于100KB的數(shù)據(jù)（如高清圖片、視頻）：建議存儲(chǔ)在文件系統(tǒng)，數(shù)據(jù)庫(kù)僅記錄文件路徑（TEXT類型）。原因：→SQLite對(duì)大BLOB的讀寫(xiě)性能較差（需加載整個(gè)BLOB到內(nèi)存）；→文件系統(tǒng)對(duì)大文件的分塊讀寫(xiě)更高效（可部分讀?。弧苊鈹?shù)據(jù)庫(kù)文件過(guò)大（單文件過(guò)大影響備份、恢復(fù)和IO性能）；→便于利用系統(tǒng)級(jí)緩存（如iOS的文件緩存機(jī)制）?；旌戏桨福簩?duì)需要快速訪問(wèn)的小縮略圖存BLOB，原圖存文件；或使用“懶加載”策略，首次訪問(wèn)大文件時(shí)從數(shù)據(jù)庫(kù)讀取并保存到文件系統(tǒng)，后續(xù)從文件讀取。Q8：CoreData的NSFetchedResultsController在UITableView中的使用注意事項(xiàng)有哪些？如何處理數(shù)據(jù)變更的實(shí)時(shí)刷新？NSFetchedResultsController（FRC）是專為UITableView/UICollectionView設(shè)計(jì)的控制器，通過(guò)監(jiān)聽(tīng)CoreData上下文的變更自動(dòng)更新數(shù)據(jù)源。注意事項(xiàng)：①初始化配置：需指定正確的managedObjectContext（與tableView同線程）、fetchRequest（需設(shè)置sectionNameKeyPath或cacheName）；②緩存使用：設(shè)置cacheName可緩存查詢結(jié)果，提升滾動(dòng)性能，但需注意緩存失效（模型變更或數(shù)據(jù)大量修改時(shí)需刪除舊緩存）；③線程安全：FRC的delegate方法（如controller:didChangeObject:）默認(rèn)在上下文所在線程執(zhí)行（如mainQueue），需確保UI更新在主線程；④批量操作優(yōu)化：對(duì)大量數(shù)據(jù)變更（如刪除100條記錄），應(yīng)暫時(shí)移除delegate，批量保存后再添加，避免頻繁調(diào)用tableView的insert/delete方法導(dǎo)致卡頓；⑤處理重復(fù)數(shù)據(jù)：fetchRequest需設(shè)置sortDescriptors（否則FRC無(wú)法正確跟蹤順序），且需確保數(shù)據(jù)唯一性（避免同一對(duì)象多次觸發(fā)變更通知）。實(shí)時(shí)刷新實(shí)現(xiàn)：注冊(cè)上下文保存通知：FRC內(nèi)部已監(jiān)聽(tīng)NSManagedObjectContextDidSaveNotification，變更會(huì)自動(dòng)同步到UI；手動(dòng)刷新：若上下文未自動(dòng)合并變更（如跨上下文操作），需調(diào)用[controllerperformFetch:&error]手動(dòng)刷新；處理沖突：若多個(gè)上下文同時(shí)修改同一對(duì)象，需在保存時(shí)處理合并沖突（通過(guò)mergePolicy屬性，默認(rèn)NSMergeByPropertyStoreTrumpMergePolicy）。Q9：SQLite的索引設(shè)計(jì)原則有哪些？哪些場(chǎng)景不適合創(chuàng)建索引？索引設(shè)計(jì)原則：①針對(duì)高頻查詢字段：為WHERE子句、JOIN條件、ORDERBY/GROUPBY中的字段創(chuàng)建索引；②最左匹配原則：復(fù)合索引（如(name,age)）可加速name查詢、name+age查詢，但無(wú)法加速age單獨(dú)查詢；③避免冗余索引：如已有(name,age)索引，無(wú)需再創(chuàng)建name單獨(dú)索引（除非name查詢極高頻且age字段很大）；④索引字段長(zhǎng)度：對(duì)長(zhǎng)文本字段（如content）使用前綴索引（CREATEINDEXidx_contentONtable(content(20))），減少索引大??；⑤覆蓋索引：若查詢僅需要索引中的字段（如SELECTnameFROMuserWHEREage=20），可創(chuàng)建(age,name)索引，避免回表查詢。不適合索引的場(chǎng)景：①低基數(shù)字段：如性別（僅男/女），索引無(wú)法有效過(guò)濾數(shù)據(jù)；②頻繁更新的字段：索引會(huì)增加INSERT/UPDATE/DELETE的開(kāi)銷（每次變更需更新索引）；③小表：數(shù)據(jù)量小于1000條時(shí)，全表掃描可能比索引查詢更快；④大字段：如TEXT/BLOB類型，索引存儲(chǔ)和維護(hù)成本高；⑤僅查詢一次的字段：臨時(shí)查詢無(wú)需長(zhǎng)期維護(hù)索引。Q10：iOS中如何實(shí)現(xiàn)數(shù)據(jù)庫(kù)加密？SQLCipher集成的關(guān)鍵步驟和注意事項(xiàng)有哪些？數(shù)據(jù)庫(kù)加密的核心是對(duì)存儲(chǔ)的二進(jìn)制數(shù)據(jù)加密，防止直接通過(guò)文件讀取獲取明文。iOS常用方案是集成SQLCipher（基于SQLite的加密擴(kuò)展）。集成步驟：1.通過(guò)Coco