这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天
今天遇到在建表的时候用到了全文索引，发现全文索引会极大的降低查询效率，因此对全文索引做了一个基准测试，方便以后使用。
1 Background
环境
docker-mysql5.7-db_game/guild
单核intel i7 CPU，内存1024MB
2 Test
condition 1
- 插入插入2e7条数据，公会名长度为5-60个字符
- 采用createInBatch的方法插入，BatchSize=1000
- start_time: 2021-12-31 10:59:46.275335 +0800 CST m=+0.051705754
- end_time: 2021-12-31 12:49:45.369766 +0800 CST m=+6599.377015526
插入
@iterations: 7
| iteration | cost_time |
|---|---|
| 1 | 33.201700727s |
| 2 | 33.141301241s |
| 3 | 33.658088113s |
| 4 | 34.188540121s |
| 5 | 32.799325738s |
| 6 | 33.857287635s |
| 7 | 33.178098592s |
@insert_num: 1e5
@average_time: 33.43204888s
@description:
插入速度没有受到插入量的影响，在数据库中包含大量数据时，使用批插入的方式依然可以做到较快的速度进行插入。
查询
@iterations: 5
| iteration | cost_time |
|---|---|
| 1 | 35.562128597s |
| 2 | 34.67599826s |
| 3 | 35.056739311s |
| 4 | 34.273200999s |
| 5 | 36.189313488s |
@query_num: 10
@average_time: 35.151476131s / 10 queries
@description:
在查找规范输入的字符串时——“字符串长度3-10，并且只包含数字和字母”，平均速度在3.5秒左右，在包含2e7条数据时，索引量约为6e8，巨大的索引表长度使查找速度变得缓慢。
condition 2
- 插入插入1e6条数据
- 采用createInBatch的方法插入，BatchSize=1000
- start_time: 2021-12-31 16:45:50.065461 +0800 CST m=+0.211699355
- end_time: 2021-12-31 16:51:37.081026 +0800 CST m=+347.233174027
插入
@iterations: 7
| iteration | cost_time |
|---|---|
| 1 | 32.806922751s |
| 2 | 32.854887624s |
| 3 | 33.231469524s |
| 4 | 32.7953842s |
| 5 | 33.32131404s |
| 6 | 32.901601062s |
| 7 | 33.126655437s |
@insert_num: 1e5
@average_time: 33.00546209s
@description:
插入速度相比2e7数据量有极小的提升，也验证了上文的猜测，在当前数据库存在大量数据时，插入的速度几乎不受影响。
查询
@iterations: 5
| iteration | cost_time |
|---|---|
| 1 | 496.235011ms |
| 2 | 603.685949ms |
| 3 | 581.655154ms |
| 4 | 405.884284ms |
| 5 | 422.617482ms |
@query_num: 10
@average_time: 502.015576ms / 10 queries
@description:
在查找规范输入的字符串时——“字符串长度3-10，并且只包含数字和字母”，平均速度在50毫秒左右，很明显的可以看到，在包含1.7e6数据量的数据库上查找的速度要比在包含2e7条数据的数据库上查找速度快得多，满足需求的速度。
3 补充
在测试的过程中发现，虽然设置了空的停用词表，但是在保存索引和查找字符串的时候仍然会忽略特殊字符，忽略的机制与作为停用词的机制一样。即在查找时首先剔除查找串中包含的停用词，在建立索引时，不建立包含停用词的索引。
