iOS 用mysql吗_iOS端数据库解决方案，你明白是什么情况吗？

原标题：iOS端数据库解决方案，你明白是什么情况吗？

最近看到一些关于IOS端数据库的知识，觉得对大家有点用，你看有这么多的粉丝关注量，做ios开发的朋友一定也不少。

既然如此，就简单得给大家讲讲移动端的一些知识点，让一些刚步入这行的朋友一点方向。

为什么要用数据库

iOS端持久化的方案选择比较多，NSUserDefault，Keychain，File，sqlite都可以帮助存储关键的业务数据。NSUserDefault和Keychain都是轻量级解决方案，自定义数据格式的File则读取麻烦一些，每次更新部分数据都会导致整个文件io，数据的结构一旦复杂起来，最后还是会走向sqlite。

sqlite是移动端的轻量级数据库解决方案，它的应用之广几乎已经遍及我们日常生活当中所使用的主流App，大部分人所熟知的CoreData或者FMDB，其内核都是基于sqlite。现在第三方的封装使得sqlite的使用更为便捷，但数据库是计算机科学一大知识体系，其涵盖的知识点相当庞大，简单用起来很简单，用得合理用得溜就不那么容易了。一个高频次使用的App，一年之后还要保持高效的读写真不是个简单的活。

在具体深入CoreData和Sqlite细节之前，先梳理下数据相关的重要知识点，以下关于数据库的讨论都是以sqlite为范畴。

Relation(关系) vs Object(对象)

在开始讨论之前，分清楚Relation(关系)和Object(对象)之间的差别非常重要。这两个概念对很多最初接触数据库的同学来说可能有些模糊不清，特别是直接上手一些第三方封装过Sqlite库，很容易认为表和对象之间存在天然的映射关系，毕竟table当中的记录刚好可以对应一个object。

其实对于sqlite这类关系型数据库，在数据的存储和表现形式上和面向对象当中的object还是存在很大差异的。我们平常使用OOP编程语言的时候，习惯性思维会用对象去模拟，描述一切和业务相关的存在，比如用户，商品，购物车，浏览记录，购买记录等等，这些可以方便的对应到一个个的table，但Object在描述对象的时候更加灵活，比如UserProfile对象，他可以有一个property来描述他的朋友列表：

@interfaceUesrProfile: NSObject@property(nonatomic, strong) NSArray* friends;@end

可以用Array这类集合的概念进一步细化表示Object，但sqlite的table只能存储scalar type，也就是单一数据类型，无法去存储Array，关系型数据库的做法通常是通过主键和外键，在两个表之间来表示关系。当然我们也可以在UserProfile表中增加一个自定义的blobdata或者格式化后的特殊String来存储array，但这种设计已经脱离关系系数据库的范畴了。

总而言之，sqlite这类关系型数据库更加强调关系，将内存中的OOP对象保持至数据库的时候需要进行一步转化的工作，将OOP的Relation转化成sqlite的Relation。

index(索引)

索引是平常数据库使用当中基础中的基础，如果只是将数据转化为表进行保持，下次用时再取，在表记录变得庞大以后很容易出现性能问题。用数据库保持数据的另一大好处是数据的读取可以很快，和传统的文件存储相比，性能不在一个量级。当然我们需要索引的帮助，index可以让我们以特定的方式快速读取或查找某些记录，有多快呢？理解index有多快需要一些算法知识的储备，并不是很复杂的算法。

抽象来看，数据库也可以看做是一种集合类。

对于无序Array，我们需要完整的遍历整个集合才能找到我们感兴趣的元素，查找的时间复杂度为O(N)。

有序的Array，二分法查找可以将时间复杂度降为O(logN)，但插入为O(N)。

有没有一种数据存储方式可以同时让insert和search都快呢？Tree可以，Binary Search Tree可以在insert和search之间取得平衡，达到O(logN)的速度。

再继续深入之前，我们先抽象的看下sqlite是如何存储数据的。

所谓的建索引是给原数据表新建了一个index表来方便查找，如果我们给User表中的Name做了索引，当我们根据Name去做sql查询的时候，第一步其实是去User表对应的Index表去做查询，Index表以Name为key建立了一个B+Tree的树形结构。上图中虽然Index表看上去也是一个table，但背后其实是以B+Tree为数据结构进行了整理，在B+Tree(Index表)中找到记录A之后，第二步可以从A记录中的地址信息找到原User表对应的记录信息。这里可以看出主要的性能损耗在第一步，第二步是普通的磁盘I/O。索引并不是万金油，我们可以通过分析第一步来了解建立了索引之后的查询性能瓶颈在哪。要分析第一步，还得先了解其他几个知识点：

磁盘I/O瓶颈

在学校学习计算机基础这门课程的时候，我们都知道内存(Memory)较之于磁盘(Disk)，读取速度快，但由于价格贵所以空间