Cacher is the code snippet organizer for pro developers

你的问题比较多也比较专业，里面存在一些误区，我给你一一回复：

1. 在任何操作系统上，文件的大小和打开速度是无关的，因为打开文件只是获取一个句柄。如果感觉慢，一定是程序打开文件后自动开始读取内容，需要读取的内容越多才越慢，如果打开后不自动读文件，就不会慢，很多支持打开上G文件的文本编辑器都是采用了这样的设计。Evernote在笔记有变更后，会建立本地索引，索引是为了读取和搜索更快。在Evernote启动后都会自动读取索引，索引的体积很小，但是显然也是随着笔记数增长的。如果启动不读取索引，会导致你之后的读取和搜索速度慢得无法接受。所以目前的设计已经是比较快速的了。
2. 至于“单文件损坏无法分摊风险”。这里有很多错误。首先你的备份方式就不对，Evernote已经提供了合理的备份方式，应该是用菜单里的文件 - 导出，生成.enex文件，这种格式才是备份文件。你说的.exb是Evernote程序使用的数据库文件，这个文件的设计目的并不是用于备份和恢复，一般来说对用户是隐蔽不可见的。隐蔽的原因就是不希望用户直接使用这个文件，也不用关心这个文件。直接去覆盖这个文件导致的风险是不可控的，Evernote没办法为这样的操作负责。其次导出的时候是有很多种粒度可选的，你可以导出所有笔记，也可以分笔记本导出（就是你想要的一个笔记本一个文件），甚至只导出一条笔记，只需要在想导出的对象上点右键 - 导出。最后单文件损坏的风险不可控，这里问题的主要原因在于FAT32文件系统的单文件体积限制不能超过4G，不止是Evernote，任何程序都无法突破这个限制。可以做到的是分多个文件存储数据，这个Evernote需要考虑如何改进，因为涉及到更换数据库类型，变动比较大。
3. 备份只能用覆盖，这个在第2点已经解释了，你可以选择分笔记本备份。我推荐一个自己长期实践的方式，就是使用Dropbox备份。我自己的备份习惯是，每个月导出所有笔记到一个.enex文件，然后按日期命名，不覆盖以前的文件（我不清楚你为什么一定要覆盖），例如Evernote_20130101.enex。然后全部到存放到Dropbox里，自动上传，上传完了之后删除掉前一个备份文件，始终只占用一个文件的空间。不管是删除还是覆盖操作，Dropbox都会保存文件的历史版本，随时可以回溯恢复，所以空间不够的话可以放心删除。而且Dropbox不限制单个文件的大小，多大的文件都可以上传。