由于一下子为单表创建了三个索引,所以, 简单测一测这个高亮摘录数据库的插入性能,测试平台是安卓,每次插入一行字数为3~7的摘录数据。
String sqlBuilder = "create table if not exists " +
TABLE_BOOK_ANNOT_v2 +
"(" +
"id INTEGER PRIMARY KEY AUTOINCREMENT" +
", bid INTEGER NOT NULL"+
", entryHash INTEGER NOT NULL" +
", lexHash INTEGER NOT NULL" +
", entryDig VARCHAR(5)" +
", lexDig VARCHAR(5)" +
", hasNotes BOOLEAN DEFAULT 0 NOT NULL" +
", entry LONGVARCHAR" +
", lex LONGVARCHAR" +
", pos INTEGER NOT NULL"+
", creation_time INTEGER NOT NULL"+
", last_edit_time INTEGER NOT NULL" +
", visit_count INTEGER DEFAULT 0 NOT NULL" +
", param BLOB" +
", notes BLOB" +
")";
db.execSQL(sqlBuilder);
db.execSQL("CREATE INDEX if not exists bookannot_book_hash_index ON bookannot (bid, entryHash, entryDig, lexHash, lexDig, pos, hasNotes)"); // 查询,页面笔记界面
db.execSQL("CREATE INDEX if not exists bookannot_time_index ON bookannot (bid, last_edit_time)"); // 词典笔记界面
db.execSQL("CREATE INDEX if not exists bookannot_time_index ON bookannot (last_edit_time)"); // 全部笔记界面
轮次 | 插入行数 | 平均速度(行/秒) | 最后一行写入时间(毫秒) |
---|---|---|---|
0 | 50378 | 7859 | 未记录 |
1 | 50601 | 5177 | 17 |
2 | 50516 | 11265 | 19 |
3 | 50523 | 9751 | 20 |
4 | 50656 | 9502 | 24 |
5 | 50459 | 5639 | 25 |
6 | 50534 | 5837 | 29 |
7 | 50509 | 4402 | 31 |
8 | 50509 | 4402 | 31 |
9 | 50597 | 5852 | 19 |
10 | 50396 | 5613 | 40 |
11 | 50591 | 6252 | 41 |
12 | 50492 | 5248 | 42 |
13 | 50469 | 4980 | 45 |
14 | 50461 | 4782 | 47 |
15 | 50448 | 5082 | 44 |
16 | 50524 | 4829 | 36 |
17 | 50501 | 4668 | 45 |
18 | 50508 | 4794 | 37 |
19 | 50438 | 4653 | 65 |
20 | 50438 | 4653 | 65 |
21 | 50531 | 3632 | 69 |
至此,表中数据有一百万行,数据库大小177MB。即便如此,最后一次插入时间也妥妥地在100ms内。里面的数据是这个样子的:

在此基础上换个数据集,随机测试:
轮次 | 插入行数 | 平均速度(行/秒) | 最后一行写入时间(毫秒) |
---|---|---|---|
0 | 14419 | 2664 | 6 |
1 | 14396 | 2621 | 4 |
2 | 14413 | 2529 | 5 |
由于摘录的只是3、4个字母的测试数据,所以速度很快,接下来引入断词(BreakIterator),测一测摘录完整的英文单词,是否还是那么快:
轮次 | 插入行数 | 平均速度(行/秒) | 最后一行写入时间(毫秒) |
---|---|---|---|
0 | 12919 | 2120 | 6 |
1 | 12919 | 2209 | 12 |
2 | 12919 | 2263 | 7 |

结论:只要参数合适,sqlite处理百万级的数据还是能够胜任的。
网友评论