Elton's Blog

1. 简介

我们知道，为了应对不断增长的数据，我们对数据进行切分，存储在不同的数据库里，本文提到的数据库在非特定指明的情况下，均指一个逻辑数据库（是一组数据库，比如Master-Slave），而非单一各个物理数据库。

其主要有两种方式：

垂直切分（Vertical Partition/Sharding）:就是把不同格式的数据，存储到不同的数据库。
水平切分（Horizontal Partition/Sharding）:就是把相同的数据格式的数据，存储到不同的数据库，本文将侧重这点进行讲述。

2. 垂直切分（Vertical Partition/Sharding）

对于垂直切分，其实应用非常广泛，主旨是把那些关系依赖非常紧密的数据保存到同一数据库，主要包含如下几种应用方式：

不同的应用使用不同数据库:这个非常容易理解，即对于一个企业来讲，往往有多个应用，甚至有些应用逐渐演变成两个或者多个应用，这其实就是一种垂直切分应用。
应用的不同模块使用不同的数据库:为同一应用的不同模块分别使用不同的数据库，之间提供低耦合的API进行访问。
同一应用相同模块使用不同数据库:在一些应用中，对于适合关系查询的数据，保存在关系数据库，而另外一些适合以NoSQL数据库保存的数据（例如key-value数据库），保存在NoSQL数据库中，方便数据扩展。这里给出一个例子，比如一个论坛应用，可以对个人用户信息保存在关系数据库，例如，其访问次数，个人信息等等，而对于发表的帖子和回帖，则可以保存在一个NoSQL里，方便扩展。注意，这里给出的例子并非真实例子，只是为了易于说明给出一个假设性的例子。

3. 水平切分（Horizontal Partition/Sharding）

水平切分相对比较复杂，我们还是从水平切分的策略谈起。

3.1 水平切分策略主要分为以下几种：

1. Round-Robin（轮询式）算法

顾名思义，就是把数据按照轮流的方式依次存放在的数据库节点上，比如，有2个节点，N0和N1，那么Data0放在N0节点上，Data1放在N1上，Data2放在N0上，依次类推……。

这种方式实现起来非常容易，对于数字键，我们有：n = key mod N。其中，key为数据的键，N为节点的数量，n为存放数据的节点编号；对于那些非数字键，我们可以让其转变为数字键，比如通过某些hash函数，让键值均匀分布，于是有：n = f (key) mod N。

这种方式有个缺点非常明显，不容易应对数据节点的变化，即不易进行二次切分。所谓二次分片是指，当数据的增长超过数据库容量时，需要增加数据库，或者系统故障导致某些数据库不能使用时，这时需要重新切分数据库。例如，有两个节点，N0和N1，现在需要增加一个节点N2，这时候，都需要吧N0上的数据和N1上的数据迁移到N2上，这个工作量是巨大的；并且可能导致上层应用对数据的改变，比如，之前数据Data5存储在N1上面，上层应用访问该数据时，根据key=5知道其存储在数据库N1里，那么便会在N1里查询数据，现在增加另外一个节点N2，那么这条数据被迁移到N2上了，上层应用就应该去N2上查询此数据了，这个看似简单，其实往往导致应用程序的复杂性很高。

2. 虚拟分片技术

为了保证二次分片时，避免对上层应用因为实际物理数据库发生改变而引起对数据访问逻辑的改变，中间加入了一个虚拟片段—物理片段映射表，数据对象存储在虚拟分片上，每个虚拟片段通过这个映射表找到相应的物理片段。这时间，上层应用依赖于虚拟分片，而非物理分片，只要保证虚拟片段足够多，就能避免上层应用的依赖。

3. 一致性Hash算法

为了避免数据库数量发生变化，引起大规模的数据迁移问题，而引入了一致性Hash算法。此算法由David Karger等人发表于1997年，论文题目为《Consistent hashing and random trees: distributed caching protocols for relieving hot spots on the World Wide Web》，这里有一篇文章讲述Java语言简单实现一致性Hash算法http://weblogs.java.net/blog/2007/11/27/consistent-hashing。

一致性Hash算法的主要思想是不改变Hash函数本身，当减少节点时，临近的节点接手该节点，因此，消失节点上的数据迁移只迁移到临近节点上面；而增加节点时，只接手其临近的一个节点的部分数据，因此，只有一部分临近节点的数据被迁移至新加节点。

我们来详细了解一下具体实现：我们的Hash函数生成的数据都有一个值区间[min，max]，我们把该区间用一个环来表示，每个节点的hash值都映射到这个环上，如下图所示：

假设我们的值区间是[1,12]，我们有三个节点，1，4，9，数据的键也映射到这个环上，a的键值介于1~4之间，则存储在节点4上，即按照顺时针方向存储数据，同样b存储于节点9，而c存储于节点1。

假设节点4不可用时，那么数据a就会被迁移至节点9，其他节点的数据不发生迁移，如下图所示：

假设增加节点7，那么将把节点9上的部分数据迁移至节点7，其他节点数据不发生改变，如下图所示：

4. 按照数据的特点进行切分数据

最常见的就是按照地理位置切分数据，那么我们按照用户的注册信息或者用户数据提交的ip地址等来把它们放置于离它们地理位置最近的数据库中。

3.2 实际应用

在真实的应用中，往往会结合这些策略，甚至提供更为抽象的接口让开发人员实现适合自己的切分方法。我们这里讲述Mongodb和Hibernate Shards的分片方式。

3.2.1 Mongodb Sharding

Mongo db是基于文档的NoSQL数据库，查询方式和关系数据库非常接近。

Mongodb把数据存放在称为Chuncks数据结构上面，Chunck的默认大小是64M，每个Chunck上面存储一定切分范围的数据，当数据超过64M时，会自行分裂成两个Chunks，相当于一致性Hash算法添加了一个节点，只是这个节点不是DB。而每台物理db（称为Shard）上含有多个Chunks，为了达到更好的负载均衡，这些物理db上的Chunks会自动迁移，使得db上的Chunks发布均衡。

3.2.2 Hibernate Shards

Hibernate Shards是在Hibernate Core上做的一层扩展，目的是在关系数据库上封装和降低水平切分的复杂性。

Hibernate Shards为开发者提供了抽象接口，开发人员可以实现自己想要的切分策略，为了避免物理数据库发生改变引起应用程序的改变，其采用虚拟分片技术。

Hibernate Shards参考中文文档请参见：http://redhat.iteye.com/blog/328032

3.3 应注意的问题

水平切分数据库之后，会给查询造成一定的困难，特别是Aggregation查询。Mongodb采用Map/Reduce方式，能够比较高效进行Aggregation查询。

4 总结

对于大规模，可伸缩，海量数据的应用，数据切分是其架构必须考虑的一个重点内容，我们在进行数据切分时，往往采用先垂直，再水平方式对数据分片。

摘自：http://blog.csdn.net/co0der/article/details/7217974

Strings

Strings 数据结构是简单的key-value类型，value其实不仅是String，也可以是数字。使用Strings类型，你可以完全实现目前 Memcached 的功能，并且效率更高。还可以享受Redis的定时持久化，操作日志及 Replication等功能。除了提供与 Memcached 一样的get、set、incr、decr 等操作外，Redis还提供了下面一些操作：

• 获取字符串长度
• 往字符串append内容
• 设置和获取字符串的某一段内容
• 设置及获取字符串的某一位（bit）
• 批量设置一系列字符串的内容

Hashs

在Memcached中，我们经常将一些结构化的信息打包成hashmap，在客户端序列化后存储为一个字符串的值，比如用户的昵称、年龄、性别、积分等，这时候在需要修改其中某一项时，通常需要将所有值取出反序列化后，修改某一项的值，再序列化存储回去。这样不仅增大了开销，也不适用于一些可能并发操作的场合（比如两个并发的操作都需要修改积分）。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。

Lists

Lists 就是链表，相信略有数据结构知识的人都应该能理解其结构。使用Lists结构，我们可以轻松地实现最新消息排行等功能。Lists的另一个应用就是消息队列，可以利用Lists的PUSH操作，将任务存在Lists中，然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作Lists中某一段的api，你可以直接查询，删除Lists中某一段的元素。

Sets

Sets 就是一个集合，集合的概念就是一堆不重复值的组合。利用Redis提供的Sets数据结构，可以存储一些集合性的数据，比如在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作，可以非常方便的实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

Sorted Sets

和Sets相比，Sorted Sets增加了一个权重参数score，使得集合中的元素能够按score进行有序排列，比如一个存储全班同学成绩的Sorted Sets，其集合value可以是同学的学号，而score就可以是其考试得分，这样在数据插入集合的时候，就已经进行了天然的排序。另外还可以用Sorted Sets来做带权重的队列，比如普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

Pub/Sub

Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。

Transactions

谁说NoSQL都不支持事务，虽然Redis的Transactions提供的并不是严格的ACID的事务（比如一串用EXEC提交执行的命令，在执行中服务器宕机，那么会有一部分命令执行了，剩下的没执行），但是这个Transactions还是提供了基本的命令打包执行的功能（在服务器不出问题的情况下，可以保证一连串的命令是顺序在一起执行的，中间有会有其它客户端命令插进来执行）。Redis还提供了一个Watch功能，你可以对一个key进行Watch，然后再执行Transactions，在这过程中，如果这个Watched的值进行了修改，那么这个Transactions会发现并拒绝执行。

但凡初次接触MongoDB的人，无不惊讶于它对内存的贪得无厌，至于个中缘由，我先讲讲Linux是如何管理内存的，再说说MongoDB是如何使用内存的，答案自然就清楚了。

据说带着问题学习更有效，那就先看一个MongoDB服务器的top命令结果：

1
2
3
4
5
6

shell> top -p $(pidof mongod)
Mem:  32872124k total, 30065320k used,  2806804k free,   245020k buffers
Swap:  2097144k total,      100k used,  2097044k free, 26482048k cached
 
 VIRT  RES  SHR %MEM
1892g  21g  21g 69.6

这台MongoDB服务器有没有性能问题？大家可以一边思考一边继续阅读。

先讲讲Linux是如何管理内存的

在Linux里（别的系统也差不多），内存有物理内存和虚拟内存之说，物理内存是什么自然无需解释，虚拟内存实际是物理内存的抽象，多数情况下，出于方便性的考虑，程序访问的都是虚拟内存地址，然后操作系统会把它翻译成物理内存地址。

很多人会把虚拟内存和Swap混为一谈，实际上Swap只是虚拟内存引申出的一种技术而已：操作系统一旦物理内存不足，为了腾出内存空间存放新内容，就会把当前物理内存中的内容放到交换分区里，稍后用到的时候再取回来，需要注意的是，Swap的使用可能会带来性能问题，偶尔为之无需紧张，糟糕的是物理内存和交换分区频繁的发生数据交换，这被称之为Swap颠簸，一旦发生这种情况，先要明确是什么原因造成的，如果是内存不足就好办了，加内存就可以解决，不过有的时候即使内存充足也可能会出现这种问题，比如MySQL就有可能出现这样的情况，解决方法是限制使用Swap：

1

shell> sysctl -w vm.swappiness=0

查看内存情况最常用的是free命令：

1
2
3
4
5

shell> free -m
             total       used       free     shared    buffers     cached
Mem:         32101      29377       2723          0        239      25880
-/+ buffers/cache:       3258      28842
Swap:         2047          0       2047

新手看到used一栏数值偏大，free一栏数值偏小，往往会认为内存要用光了。其实并非如此，之所以这样是因为每当我们操作文件的时候，Linux都会尽可能的把文件缓存到内存里，这样下次访问的时候，就可以直接从内存中取结果，所以cached一栏的数值非常的大，不过不用担心，这部分内存是可回收的，操作系统会按照LRU算法淘汰冷数据。还有一个buffers，也是可回收的，它和cache的区别，可以参考维基百科。

知道了原理，我们就可以推算出系统可用的内存是free + buffers + cached：

1
2

shell> echo "2723 + 239 + 25880" | bc -l
28842

至于系统实际使用的内存是used – buffers – cached：

1
2

shell> echo "29377 - 239 - 25880" | bc -l
3258

除了free命令，还可以使用sar命令：

1
2
3
4
5
6
7

shell> sar -r
kbmemfree kbmemused  %memused kbbuffers  kbcached
  3224392  29647732     90.19    246116  26070160
 
shell> sar -W
pswpin/s pswpout/s
    0.00      0.00

希望你没有被%memused吓到，如果不幸言中，重读本文。

再说说MongoDB是如何使用内存的

目前，MongoDB使用的是内存映射存储引擎，它会把磁盘IO操作转换成内存操作，如果是读操作，内存中的数据起到缓存的作用，如果是写操作，内存还可以把随机的写操作转换成顺序的写操作，总之可以大幅度提升性能。MongoDB并不干涉内存管理工作，而是把这些工作留给操作系统的虚拟内存管理器去处理，这样的好处是简化了MongoDB的工作，但坏处是你没有方法很方便的控制MongoDB占多大内存，事实上MongoDB会占用所有能用的内存，所以最好不要把别的服务和MongoDB放一起。

有时候，即便MongoDB使用的是64位操作系统，也可能会遭遇臭名昭著的OOM问题，出现这种情况，多半是因为限制了虚拟内存的大小所致，可以这样查看当前值：

1

shell> ulimit -a | grep 'virtual'

多数操作系统缺省都是把它设置成unlimited的，如果你的操作系统不是，可以这样修改：

1

shell> ulimit -v unlimited

不过要注意的是，ulimit的使用是有上下文的，最好放在MongoDB的启动脚本里。

有时候，出于某些原因，你可能想释放掉MongoDB占用的内存，不过前面说了，内存管理工作是由虚拟内存管理器控制的，所以通常你只能通过重启服务来释放内存，你一定不齿于这样的方法，幸好可以使用MongoDB内置的closeAllDatabases命令达到目的：

1
2

mongo> use admin
mongo> db.runCommand({closeAllDatabases:1})

另外，通过调整内核参数drop_caches也可以释放缓存：

1

shell> sysctl -w vm.drop_caches=1

平时可以通过mongo命令行来监控MongoDB的内存使用情况，如下所示：

1
2
3
4
5
6

mongo> db.serverStatus().mem:
{
    "resident" : 22346,
    "virtual" : 1938524,
    "mapped" : 962283
}

还可以通过mongostat命令来监控MongoDB的内存使用情况，如下所示：

1
2
3

shell> mongostat
mapped  vsize    res faults
  940g  1893g  21.9g      0

其中内存相关字段的含义是：

• mapped：映射到内存的数据大小
• visze：占用的虚拟内存大小
• res：占用的驻留内存大小

注：如果操作不能在内存中完成，结果faults列的数值不会是0，视大小可能有性能问题。

在上面的结果中，vsize是mapped的两倍，而mapped等于数据文件的大小，所以说vsize是数据文件的两倍，之所以会这样，是因为本例中，MongoDB开启了journal，需要在内存里多映射一次数据文件，如果关闭journal，则vsize和mapped大致相当。

如果想验证这一点，可以在开启或关闭journal后，通过pmap命令来观察文件映射情况：

1

shell> pmap $(pidof mongod)

到底MongoDB配备多大内存合适？宽泛点来说，多多益善，如果要确切点来说，这实际取决于你的数据及索引的大小，内存如果能够装下全部数据加索引是最佳情况，不过很多时候，数据都会比内存大，比如本文所涉及的MongoDB实例：

1
2
3
4
5

mongo> db.stats()
{
    "dataSize" : 1004862191980,
    "indexSize" : 1335929664
}

本例中索引只有1G多，内存完全能装下，而数据文件则达到了1T，估计很难找到这么大内存，此时保证内存能装下热数据即可，至于热数据是多少，取决于具体的应用。如此一来内存大小就明确了：内存 > 索引 + 热数据。

原文引自：火丁笔记

顾名思义，MySQL Query Cache 就是用来缓存和 Query 相关的数据的。具体来说，Query Cache 缓存了我们客户端提交给 MySQL 的 SELECT 语句以及该语句的结果集。大概来讲，就是将 SELECT 语句和语句的结果做了一个 HASH 映射关系然后保存在一定的内存区域中。

在大部分的 MySQL 分发版本中，Query Cache 功能默认都是打开的，我们可以通过调整 MySQL Server 的参数选项打开该功能。主要由以下5个参数构成：

query_cache_limit：允许 Cache 的单条 Query 结果集的最大容量，默认是1MB，超过此参数设置的 Query 结果集将不会被 Cache
query_cache_min_res_unit：设置 Query Cache 中每次分配内存的最小空间大小，也就是每个 Query 的 Cache 最小占用的内存空间大小
query_cache_size：设置 Query Cache 所使用的内存大小，默认值为0，大小必须是1024的整数倍，如果不是整数倍，MySQL 会自动调整降低最小量以达到1024的倍数
query_cache_type：控制 Query Cache 功能的开关，可以设置为0(OFF),1(ON)和2(DEMAND)三种，意义分别如下：
0(OFF)：关闭 Query Cache 功能，任何情况下都不会使用 Query Cache
1(ON)：开启 Query Cache 功能，但是当 SELECT 语句中使用的 SQL_NO_CACHE 提示后，将不使用Query Cache
2(DEMAND)：开启 Query Cache 功能，但是只有当 SELECT 语句中使用了 SQL_CACHE 提示后，才使用 Query Cache
query_cache_wlock_invalidate：控制当有写锁定发生在表上的时刻是否先失效该表相关的 Query Cache，如果设置为 1(TRUE)，则在写锁定的同时将失效该表相关的所有 Query Cache，如果设置为0(FALSE)则在锁定时刻仍然允许读取该表相关的 Query Cache。
Query Cache 如何处理子查询的？
这是我遇到的最为常见的一个问题。其实 Query Cache 是以客户端请求提交的 Query 为对象来处理的，只要客户端请求的是一个 Query，无论这个 Query 是一个简单的单表查询还是多表 Join，亦或者是带有子查询的复杂 SQL，都被当作成一个 Query，不会被分拆成多个 Query 来进行 Cache。所以，存在子查询的复杂 Query 也只会产生一个Cache对象，子查询不会产生单独的Cache内容。UNION[ALL] 类型的语句也同样如此。

Query Cache 是以 block 的方式存储的数据块吗？
不是，Query Cache 中缓存的内容仅仅只包含该 Query 所需要的结果数据，是结果集。当然，并不仅仅只是结果数据，还包含与该结果相关的其他信息，比如产生该 Cache 的客户端连接的字符集，数据的字符集，客户端连接的 Default Database等。

Query Cache 为什么效率会非常高，即使所有数据都可以 Cache 进内存的情况下，有些时候也不如使用 Query Cache 的效率高？
Query Cache 的查找，是在 MySQL 接受到客户端请求后在对 Query 进行权限验证之后，SQL 解析之前。也就是说，当 MySQL 接受到客户端的SQL后，仅仅只需要对其进行相应的权限验证后就会通过 Query Cache 来查找结果，甚至都不需要经过 Optimizer 模块进行执行计划的分析优化，更不许要发生任何存储引擎的交互，减少了大量的磁盘 IO 和 CPU 运算，所以效率非常高。

客户端提交的 SQL 语句大小写对 Query Cache 有影响吗？
有，由于 Query Cache 在内存中是以 HASH 结构来进行映射，HASH 算法基础就是组成 SQL 语句的字符，所以必须要整个 SQL 语句在字符级别完全一致，才能在 Query Cache 中命中，即使多一个空格也不行。

一个 SQL 语句在 Query Cache 中的内容，在什么情况下会失效？
为了保证 Query Cache 中的内容与是实际数据绝对一致，当表中的数据有任何变化，包括新增，修改，删除等，都会使所有引用到该表的 SQL 的 Query Cache 失效。

为什么我的系统在开启了 Query Cache 之后整体性能反而下降了？
当开启了 Query Cache 之后，尤其是当我们的 query_cache_type 参数设置为 1 以后，MySQL 会对每个 SELECT 语句都进行 Query Cache 查找，查找操作虽然比较简单，但仍然也是要消耗一些 CPU 运算资源的。而由于 Query Cache 的失效机制的特性，可能由于表上的数据变化比较频繁，大量的 Query Cache 频繁的被失效，所以 Query Cache 的命中率就可能比较低下。所以有些场景下，Query Cache 不仅不能提高效率，反而可能造成负面影响。

如何确认一个系统的 Query Cache 的运行是否健康，命中率如何，设置量是否足够？
MySQL 提供了一系列的 Global Status 来记录 Query Cache 的当前状态，具体如下：

Qcache_free_blocks：目前还处于空闲状态的 Query Cache 中内存 Block 数目
Qcache_free_memory：目前还处于空闲状态的 Query Cache 内存总量
Qcache_hits：Query Cache 命中次数
Qcache_inserts：向 Query Cache 中插入新的 Query Cache 的次数，也就是没有命中的次数
Qcache_lowmem_prunes：当 Query Cache 内存容量不够，需要从中删除老的 Query Cache 以给新的 Cache 对象使用的次数
Qcache_not_cached：没有被 Cache 的 SQL 数，包括无法被 Cache 的 SQL 以及由于 query_cache_type 设置的不会被 Cache 的 SQL
Qcache_queries_in_cache：目前在 Query Cache 中的 SQL 数量
Qcache_total_blocks：Query Cache 中总的 Block 数量
可以根据这几个状态计算出 Cache 命中率，计算出 Query Cache 大小设置是否足够，总的来说，我个人不建议将 Query Cache 的大小设置超过256MB，这也是业界比较常用的做法。

MySQL Cluster 是否可以使用 Query Cache？
其实在我们的生产环境中也没有使用 MySQL Cluster，所以我也没有在 MySQL Cluster 环境中使用 Query Cache 的实际经验，只是 MySQL 文档中说明确实可以在 MySQL Cluster 中使用 Query Cache。从 MySQL Cluster 的原理来分析，也觉得应该可以使用，毕竟 SQL 节点和数据节点比较独立，各司其职，只是 Cache 的失效机制会要稍微复杂一点。

引自:http://www.javaeye.com/news/16744-mysql-query-cache-summary

导入sql表结构

• 用sqlplus命令登录Oracle

1

sqlplus system/password@orcl

• 使用@命令导入sql文件

1

SQL> @/path/to/file/sample.sql

2. 导入数据
• 导入ctl文件
在命令行中，执行

1

sqlldr userid=username/password control=sample.ctl

可以使用下面的命令来列出当前用户所有的表

1
2

select * from tab;
select table_name from user_tables;

如果想列出所有的表，可以使用

1

select table_name from all_tables;

• 用system用户登录。system用户默认就有DBA的权限

1

sqlplus system/password@orcl

• 查看数据文件存放位置

1
2
3
4
5
6
7
8
9

select file_name from dba_data_files;
 
FILE_NAME
--------------------------------------------------------------------------------
/Users/oracle/oradata/orcl/users01.dbf
/Users/oracle/oradata/orcl/sysaux01.dbf
/Users/oracle/oradata/orcl/undotbs01.dbf
/Users/oracle/oradata/orcl/system01.dbf
/Users/oracle/oradata/orcl/example01.dbf

• 建立临时表空间

1
2
3
4
5
6
7
8

create temporary tablespace decernis_temp
tempfile '/Users/oracle/oradata/orcl/decernis_temp01.dbf'
size 32m
autoextend on 
next 32m maxsize 2048m
extent management local;
 
Tablespace created.

• 建立用户数据表空间

1
2
3
4
5
6
7
8
9

create tablespace decernis_data
logging
datafile '/Users/oracle/oradata/orcl/decernis_data01.dbf'
size 32m 
autoextend on
next 32m maxsize 2048m
extent management local; 
 
Tablespace created.

• 创建用户

1
2
3

create user decernis identified by password
default tablespace decernis_data
temporary tablespace decernis_temp;

• 授予权限

1

grant dba,connect,resource to decernis;

注意，上面语句中，制定数据文件路径的时候，一定要使用单引号，否则会出现“ORA-00972: identifier is too long”的错误。

如果最后一行不添加，则用户没有表空间分配EXTENT的权限，将会会出现“ORA-01950: no privileges on tablespace
”的错误。

以后，这个用户所操作的表，就自动分配到这个表空间了。

向大家推荐一款很不错的轻量级的Cocoa持久化对象 — sqlitepersistentobjects

使用起来跟ActiveRecord很类似，也非常简单
将下载的zip中的所有文件加入你的项目中，然后链接libsqlite3.dylib，之后你就可以声明实体类了。

1
2
3
4
5
6
7
8
9
10

#import <foundation/foundation.h>
#import "SQLitePersistentObject.h"
 
@interface PersistablePerson : SQLitePersistentObject {
 NSString *lastName;
 NSString *firstName;
}
@property (nonatomic, retain) NSString * lastName;
@property (nonatomic, retain) NSString * firstName;
@end

然后你可以这样使用它：

1
2
3

PersistablePerson *person = [[PersistablePerson alloc] init];
person.firstName = @"Joe";
person.lastName = @"Smith";

当你打算保存的时候：

1

[person save];

是不是很简单

OS X自从10.4后把SQLite这套相当出名的数据库软件，放进了作业系统工具集里。OS X包装的是第三版的SQLite，又称SQLite3。这套软件有几个特色：

• 支援大多数的SQL指令（下面会简单介绍）。
• 一个档案就是一个数据库。不需要安装数据库服务器软件。
• 完整的Unicode支援（因此没有跨语系的问题）。
• 速度很快。

目前在OS X 10.4里，SQLite是以/usr/bin/sqlite3的形式包装，也就说这是一个命令列工具，必须先从终端机（Terminal.app或其他程序）进入shell之后才能使用。网络上有一些息协助使用SQLite的视觉化工具，但似乎都没有像CocoaMySQL（配合MySQL数据库使用）那般好用。或许随时有惊喜也未可知，以下仅介绍命令列的操作方式。

以下我们就建立数据库、建立资料表及索引、新增资料、查询资料、更改资料、移除资料、sqlite3命令列选项等几个项目做简单的介绍。

建立数据库档案

用sqlite3建立数据库的方法很简单，只要在shell下键入（以下$符号为shell提示号，请勿键入）：

1

$ sqlite3 foo.db

如果目录下没有foo.db，sqlite3就会建立这个数据库。sqlite3并没有强制数据库档名要怎么取。

在sqlite3提示列下操作

进入了sqlite3之后，会看到以下文字：

1
2
3

SQLite version 3.1.3
Enter ".help" for instructions
sqlite>

这时如果使用.help可以取得求助，.quit则是离开（请注意：不是quit）

SQL的指令格式

所以的SQL指令都是以分号（;）结尾的。如果遇到两个减号（–）则代表注解，sqlite3会略过去。

建立资料表

假设我们要建一个名叫film的资料表，只要键入以下指令就可以了：

1

create table film(title, length, year, starring);

这样我们就建立了一个名叫film的资料表，里面有name、length、year、starring四个字段。

这个create table指令的语法为：

1

create table table_name(field1, field2, field3, ...);

table_name是资料表的名称，fieldx则是字段的名字。sqlite3与许多SQL数据库软件不同的是，它不在乎字段属于哪一种资料型态：sqlite3的字段可以储存任何东西：文字、数字、大量文字（blub），它会在适时自动转换。

建立索引

如果资料表有相当多的资料，我们便会建立索引来加快速度。好比说：

1

create index film_title_index on film(title);

意思是针对film资料表的name字段，建立一个名叫film_name_index的索引。这个指令的语法为

1

create index index_name on table_name(field_to_be_indexed);

一旦建立了索引，sqlite3会在针对该字段作查询时，自动使用该索引。这一切的操作都是在幕后自动发生的，无须使用者特别指令。

加入一笔资料

接下来我们要加入资料了，加入的方法为使用insert into指令，语法为：

1

insert into table_name values(data1, data2, data3, ...);

例如我们可以加入

1
2
3
4

insert into film values ('Silence of the Lambs, The', 118, 1991, 'Jodie Foster');
insert into film values ('Contact', 153, 1997, 'Jodie Foster');
insert into film values ('Crouching Tiger, Hidden Dragon', 120, 2000, 'Yun-Fat Chow');
insert into film values ('Hours, The', 114, 2002, 'Nicole Kidman');

如果该字段没有资料，我们可以填NULL。

查询资料

讲到这里，我们终于要开始介绍SQL最强大的select指令了。我们首先简单介绍select的基本句型：

1

select columns from table_name where expression;

最常见的用法，当然是倒出所有数据库的内容：

1

select * from film;

如果资料太多了，我们或许会想限制笔数：

1

select * from film limit 10;

或是照着电影年份来排列：

1

select * from film order by year limit 10;

或是年份比较近的电影先列出来：

1

select * from film order by year desc limit 10;

或是我们只想看电影名称跟年份：

1

select title, year from film order by year desc limit 10;

查所有茱蒂佛斯特演过的电影：

1

select * from film where starring='Jodie Foster';

查所有演员名字开头叫茱蒂的电影(‘%’ 符号便是 SQL 的万用字符）：

1

select * from film where starring like 'Jodie%';

查所有演员名字以茱蒂开头、年份晚于1985年、年份晚的优先列出、最多十笔，只列出电影名称和年份：

1

select title, year from film where starring like 'Jodie%' and year >= 1985 order by year desc limit 10;

有时候我们只想知道数据库一共有多少笔资料：

1

select count(*) from film;

有时候我们只想知道1985年以后的电影有几部：

1

select count(*) from film where year >= 1985;

（进一步的各种组合，要去看SQL专书，不过你大概已经知道SQL为什么这么流行了：这种语言允许你将各种查询条件组合在一起──而我们还没提到「跨数据库的联合查询」呢！）

如何更改或删除资料

了解select的用法非常重要，因为要在sqlite更改或删除一笔资料，也是靠同样的语法。

例如有一笔资料的名字打错了：

1

update film set starring='Jodie Foster' where starring='Jodee Foster';

就会把主角字段里，被打成’Jodee Foster’的那笔（或多笔）资料，改回成Jodie Foster。

1

delete from film where year < 1970;

就会删除所有年代早于1970年（不含）的电影了。

其他sqlite的特别用法

sqlite可以在shell底下直接执行命令：

1

sqlite3 film.db "select * from film;"

输出 HTML 表格：

1

sqlite3 -html film.db "select * from film;"

将数据库「倒出来」：

1

sqlite3 film.db ".dump" > output.sql

利用输出的资料，建立一个一模一样的数据库（加上以上指令，就是标准的SQL数据库备份了）：

1

sqlite3 film.db < output.sql

在大量插入资料时，你可能会需要先打这个指令：

1

begin;

插入完资料后要记得打这个指令，资料才会写进数据库中：

1

commit;

小结

以上我们介绍了SQLite这套数据库系统的用法。事实上OS X也有诸于SQLiteManagerX这类的图形接口程序，可以便利数据库的操作。不过万变不离其宗，了解SQL指令操作，SQLite与其各家变种就很容易上手了。

至于为什么要写这篇教学呢？除了因为OS X Tiger大量使用SQLite之外（例如：Safari的RSS reader，就是把文章存在SQLite数据库里！你可以开开看~/Library/Syndication/Database3这个档案，看看里面有什么料），OpenVanilla从0.7.2开始，也引进了以SQLite为基础的词汇管理工具，以及全字库的注音输入法。因为使用SQLite，这两个模块不管数据库内有多少笔资料，都可以做到「瞬间启动」以及相当快速的查询回应。

将一套方便好用的数据库软件包进OS X中，当然也算是Apple相当相当聪明的选择。再勤劳一点的朋友也许已经开始想拿SQLite来记录各种东西（像我们其中就有一人写了个程序，自动记录电池状态，写进SQLite数据库中再做统计……）了。想像空间可说相当宽广。

目前支援SQLite的程序语言，你能想到的大概都有了。这套数据库2005年还赢得了美国O’Reilly Open Source Conference的最佳开放源代码软件奖，奖评是「有什么东西能让Perl, Python, PHP, Ruby语言团结一致地支援的？就是SQLite」。由此可见SQLite的地位了。而SQLite程序非常小，更是少数打 “gcc -o sqlite3 *”，不需任何特殊设定就能跨平台编译的程序。小而省，小而美，SQLite连网站都不多赘言，直指SQL语法精要及API使用方法，原作者大概也可以算是某种程序设计之道（Tao of Programming）里所说的至人了。