搜索速度依赖因素及MySQL单表RAM存储选择的技术咨询

问题1：搜索速度的提升是依靠快速数据访问还是快速索引访问实现的？ #

其实这得看具体的搜索场景，但绝大多数情况下，搜索速度的提升核心是靠快速索引访问，数据访问只是后续的配套步骤：

• 如果是主键/唯一键的精准查找：数据库会直接通过索引定位到目标行的存储位置，这时候索引访问是整个流程的核心，数据访问只是最后一步的快速读取（如果数据在缓冲池里几乎没开销）。
• 如果是范围搜索或联合索引查询：索引会先帮你过滤掉99%以上的无用数据，把查询范围缩小到极小的数据集，之后才会去访问对应的数据行。要是没有索引，就得全表扫描所有数据，速度会慢几个数量级。
• 还有一种特殊情况：如果你的查询用了覆盖索引（索引包含了查询需要的所有字段），那甚至不需要访问数据，直接从索引里返回结果——这时候索引访问就是整个搜索的全部。

问题2：将数据还是索引存储到RAM drive更优？ #

先明确你的场景：

仅用于搜索的表，80M行数据，占用8G磁盘空间（4G数据 + 4G索引），无法使用MEMORY引擎，只能通过DIRECTORY表选项将数据或索引存储到RAM drive。

从理论层面分析，优先把索引放到RAM drive里是更优的选择，原因主要有这几点：

• 索引的访问模式以随机IO为主：MySQL执行搜索时，需要频繁在B+树索引的节点间跳转查找，磁盘的随机IO性能极差，而RAM drive的随机IO速度是磁盘的几十甚至上百倍。把索引放RAM能彻底解决这个最大的性能瓶颈。
• 数据访问的IO模式更友好：基于索引的搜索找到数据位置后，数据的读取往往是连续的（比如InnoDB按页读取），磁盘的连续IO性能其实还不错，哪怕数据在磁盘上，也不会像随机读索引那样拖慢整体速度。
• 缓存复用率更高：索引的复用率通常比数据高——很多不同的查询可能会用到同一个索引节点，而数据行可能只有特定查询才会访问。把索引放RAM能让高频访问的索引页常驻高速存储，进一步提升搜索效率。
• 极端情况补充：如果你的搜索大多是覆盖索引查询（完全不需要访问数据），那把索引放RAM的优势会更明显；但如果是全表扫描为主的搜索（虽然这种情况不适合“仅用于搜索”的表），那可能数据放RAM更好——不过既然是专门做搜索的表，肯定是索引驱动的查询居多。

内容的提问来源于stack exchange，提问作者guigoz