我是否需要为具有单行的 MySQL 表定义索引（设置表）
出于性能/优化的原因，我是否需要为具有单行（设置表）的 MySQL 表定义索引？
Do I need to define an index for a MySQL table with a single row (settings table) for performance/optimization reasons?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果它只有一行，则毫无意义，因为无论如何都会对整个表进行 seq 扫描。
If it has a single row it's pointless, because the whole table will get seq scanned anyway.
对于所有关系数据库来说，这是一个非常常见的问题。 PostgreSQL 的查询规划器会故意不在读取几页数据时使用索引，因为执行索引扫描而不是简单的顺序扫描时性能会受到影响。我希望几乎所有数据库（具有最少的智能）在这种情况下都会做同样的事情。
反问一下：当您只需执行一次即可扫描 8K 数据时，为什么还要执行多次 read(2) 调用呢？上下文切换、操作系统文件系统缓存等。索引的页面很可能已经在缓存中，因此在更大的方案中优化实际上很小。为一行数据保存两次缓存命中与仅一次缓存命中......谁在乎呢？
专门针对 MySQL，使用 MyISAM 或 InnoDB 以及 file-per-table 选项设置后，您不需要索引（如果您将所有数据都放在一个 InnoDB 文件中，我不确定是否需要索引）。
This is a very common question for all relational databases. PostgreSQL's query planner will deliberately not use indexes when reading a few pages of data because performance suffers when doing an index scan instead of a simple sequential scan. I would expect that nearly all databases (with the smallest amount of intelligence) would do the same in this case.
Rhetorical: why perform multiple read(2) calls when you can just perform one and scan 8K of data? Context switching, OS file-system cache, etc. Chances are the page for the index is already in cache, so the optimization is really tiny in the greater scheme of things. Saving two cache hits for a row of data vs just one cache hit... who cares?
Specifically for MySQL, with MyISAM or InnoDB with the file-per-table options set, you don't need an index (I'm not sure if you need an index if you have all of your data in a single InnoDB file).