最早接触 iOS 开发了解到的第一个缓存数据库就是 SQLite，后面一直也以 SQLite 作为中坚力量使用，以前没有接触到比较大量数据的读写，所以在性能优化方面关注不多，这次对一个特定场景的较多数据批量读写做了一个性能优化，使性能提高了十倍。
大致应用场景是这样：
每次程序启动会从服务器拉取一些数据，对本地数据库两个表进行同步更新，不存在就写入，存在就更新其字段。数据少的时候几十条，多的上千条。
由于缓存的数据可能会存在异步同时读写，所以做了一个后台同步队列，所有的缓存数据库操作都在这个队列里面，然后我监控了一下写数据库的关键代码执行耗时，一千条数据更新到数据库就能耗时 30 秒之久，磁盘写入在 1.5M/s 浮动， 虽然没有卡主线程，这个消耗即使在后台也是不可容忍的。
核心的数据库操作大概是这样的
for 1000 : {
Select -> Update Or Insert
Select -> Update Or Insert
}
由于牵涉到两张表，所以会有两次，经过测试，Select 一次几乎没有多少消息，可是 Update 或者 Insert ( [FMDatabaseQueue executeUpdate:] ) 就消耗大了，因为会写入磁盘，然后想到是不是可以把所有的 SQL 语句拼接起来，最后只想一次；再后来想到 SQLite 不是有事务 ( Transaction ) 嘛，于是尝试了一下利用 FMDB 的事务操作，在循环开始前 [db beginTransaction] ，循环结束 [db commit]，包起来就行了。
增加事务之后的大概逻辑：
beginTransaction
for 1000 : {
Select -> Update Or Insert
Select -> Update Or Insert
}
commit
测试效果非常好，整个耗时从 30 秒下降到了2.8 秒左右，仅仅增加了两行代码。
总结：
踩过的坑，走过的坎，都是以后的经验
虽然利用事务取巧来提高了性能，但是这样做其实并不安全，好在所属场景对这部分数据绝对一致要求不是太高。
模拟器和真机有时候测试并不能重现同一个问题，因为所属架构、CPU、硬盘都不一样，所以性能测试最好还是以真机为准。该问题测试的时候在模拟器上很多问题都没有，因为硬盘比真机读写速度要高，所以避免了很多问题，测试的时候也就没有发现。
数据库设计设计的时候得多考虑考虑，多想想以后怎么扩展，怎么升级，读写的时候性能怎么样
SQLite,性能优化
《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒 经典版》的玩家都可以获得奖励。