移动Web环境下数据库性能提升那些事儿，聊聊怎么优化才靠谱

前段时间,我在InfoQ上看到一篇由某大厂资深工程师分享的文章，标题大概是《移动Web应用数据库选型与性能优化实战》，这篇文章结合了他们的实际项目经验，讲得非常实在，今天我就结合这篇资料和一些我自己的理解，来聊聊在手机浏览器这种移动Web环境下，怎么让数据库跑得更快、更稳，咱们不整那些虚头巴脑的理论，就说点实际的。

你得选对“武器”，移动Web环境下的数据库，跟我们平时在服务器上用的MySQL、Oracle那些完全是两码事，这里的主角是浏览器自带的存储方案，比如Web SQL Database（虽然已经不推荐了，但有些老项目还在用）、IndexedDB，还有简单的LocalStorage，根据InfoQ那篇文章的观点，现在最主流、能力最强的就是IndexedDB，它像个小型NoSQL数据库，能存大量结构化数据，还支持事务和索引，而LocalStorage只能存点简单的键值对，稍微复杂点的数据就歇菜了，第一步，如果你的数据量不小，或者结构复杂，需要快速查询，那就果断选IndexedDB，别用LocalStorage硬扛。

选好了数据库,接下来就是怎么用好的问题了，移动端网络时好时坏，手机性能也千差万别，所以操作数据库时一定要“轻手轻脚”，InfoQ的文章里特别强调了一点：避免在主线程上进行大量的、同步的数据库操作，虽然IndexedDB的API本身是异步的，但如果你在一个循环里疯狂执行成百上千次写入或查询，照样会把页面卡住，让用户觉得手机“冻住了”，正确的做法是，把大的操作分批处理，或者放到Web Worker（相当于后台线程）里去执行，保证用户滑动、点击页面时依然流畅。

然后就是数据库的“家务管理”，手机存储空间是有限的，你不能让数据无限制地增长下去，变成垃圾场，那篇文章提到，他们会在应用启动时或者定期检查数据库的大小，如果快达到浏览器的存储上限了，就自动清理掉那些过时的、不重要的数据，比如很久以前的聊天记录、缓存的历史图片等，这叫设置合理的数据过期和清理策略，不然，等浏览器自己来清理，或者直接报存储空间不足的错误时，用户体验就非常糟糕了。

索引也是个大学问,但咱们说得简单点，你可以把索引理解成一本书的目录，没有目录，你要找某个内容就得一页一页翻，累死个人，数据库也一样，如果你经常需要根据某个字段（比如用户名）来查找数据，那就给这个字段建个索引，查询速度会快很多，InfoQ的案例里，他们通过给商品ID建立索引，让搜索商品的性能提升了十倍不止，索引也不是越多越好，因为建立和维护索引本身也会占用空间和计算资源，会影响写入数据的速度，只给你最常用的查询条件建索引就够了。

还得有“兜底”方案，移动网络太不稳定了，用户可能在地铁里、电梯里，信号说没就没，如果你的应用严重依赖从网络加载数据并存到本地数据库，那么一旦网络中断，整个应用就可能瘫痪，那篇文章的建议是，要设计健壮的离线策略和同步机制，简单说就是，先保证应用在没网的时候也能用本地数据正常运转，等网络恢复了，再悄悄地把本地修改的数据同步到服务器，同时把服务器上的新数据拉下来，这个过程要处理好冲突，比如用户离线时修改了某条数据，线上数据也被别人改了，这时候以谁的为准？这些规则都要提前想好。

在移动Web环境下搞数据库优化,核心思想就是：选择合适的存储方案（IndexedDB），操作要异步化、批量化避免卡顿，勤做数据清理，按需建立索引，并设计好离线和同步方案来应对不稳定的网络，这些都是从实际项目中摸爬滚打出来的经验，照着做，你的移动Web应用用起来肯定会顺滑很多。