当前位置：文江博客话题详情

索引有不同的表空间有什么逻辑原因吗？

发布于 2024-08-13 03:44:07 字数 38 浏览 1 评论 0原文

您好，有人可以告诉我为什么我们为索引和数据创建不同的表空间吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

稳稳的幸福 2024-08-20 03:44:07

人们普遍认为，将索引和表保存在单独的表空间中可以提高性能。现在，许多受人尊敬的专家认为这是一个神话（请参阅此询问汤姆主题 - 搜索“神话”），但这仍然是一种常见做法，因为旧习难改！

第三方编辑

来自asktom的摘录： “索引表空间” 从 2001 年开始，适用于 Oracle 版本 8.1.6 问题

将索引保留在自己的表空间中仍然是一个好主意吗？
这会提高性能还是更多的是恢复问题？
不同平台的答案是否不同？

回复的第一部分

Yes, no, maybe.

The idea, born in the 1980s when systems were tiny and user counts were in the single 
digits, was that you separated indexes from data into separate tablespaces on different 
disks.

In that fashion, you positioned the head of the disk in the index tablespace and the head 
of the disk in the data tablespace and that would be better then seeking 2 times on the 
same disk.

Drives back then were really slow at seeking and typically measured in the 10's to 100's 
of megabytes (if you were lucky)


Today, with logical volumes, raid, NN gigabyte (nn is rapidly becoming NNN gigabytes) 
drives, hundreds/thousands of concurrent users, thousands of tables, 10's of thousands of 
indexes - this sort of "optimization" is sort of impossible.

What you strive for today is to be able to manage things, to spread IO out evenly 
avoiding hot spots.

Since I believe all things should be in locally managed tablespaces with UNIFORM extent 
sizes, I would say that yes, indexes would be in a different tablespace from the data but 
only because they are a different SIZE then the data.  My table with 50 columns and an 
average row size of 4k might belong in a tablespace that has 5meg extents whereas the 
index on a single number column might belong in a tablespace with 512k or 1m extents.

I tend to keep my indexes separate from the data but for the above sizing reason.  The 
tablespaces frequently end up on the same exact mount points.  You strive for even io 
across your disks and you may end up with indexes and data on the same devices.

It is a widespread belief that keeping indexes and tables in separate tablespaces improves performance. This is now considered a myth by many respectable experts (see this Ask Tom thread - search for "myth"), but is still a common practice because old habits die hard!

Third party edit

Extract from asktom: "Index Tablespace" from 2001 for Oracle version 8.1.6 the question

Is it still a good idea to keep indexes in their own tablespace?
Does this inhance performance or is it more of a recovery issue?
Does the answer differ from one platform to another?

First part of the Reply

Yes, no, maybe.

The idea, born in the 1980s when systems were tiny and user counts were in the single 
digits, was that you separated indexes from data into separate tablespaces on different 
disks.

In that fashion, you positioned the head of the disk in the index tablespace and the head 
of the disk in the data tablespace and that would be better then seeking 2 times on the 
same disk.

Drives back then were really slow at seeking and typically measured in the 10's to 100's 
of megabytes (if you were lucky)


Today, with logical volumes, raid, NN gigabyte (nn is rapidly becoming NNN gigabytes) 
drives, hundreds/thousands of concurrent users, thousands of tables, 10's of thousands of 
indexes - this sort of "optimization" is sort of impossible.

What you strive for today is to be able to manage things, to spread IO out evenly 
avoiding hot spots.

Since I believe all things should be in locally managed tablespaces with UNIFORM extent 
sizes, I would say that yes, indexes would be in a different tablespace from the data but 
only because they are a different SIZE then the data.  My table with 50 columns and an 
average row size of 4k might belong in a tablespace that has 5meg extents whereas the 
index on a single number column might belong in a tablespace with 512k or 1m extents.

I tend to keep my indexes separate from the data but for the above sizing reason.  The 
tablespaces frequently end up on the same exact mount points.  You strive for even io 
across your disks and you may end up with indexes and data on the same devices.

回复收藏 0 原文

妄断弥空 2024-08-20 03:44:07

这在 80 年代是有意义的，当时用户不多，数据库大小也不是太大。当时，将索引和表存储在不同的物理卷中非常有用。

现在有了逻辑卷、raid等，不需要将索引和表存储在不同的表空间中。

但所有表空间必须以统一的扩展大小进行本地管理。从这个角度来看，索引必须存储在不同的表空间中，因为当索引的表空间有足够的 512Kb 扩展大小时，具有 50 列的表可以存储在 5Mb 扩展大小的表空间中。

回复收藏 0 原文

哭了丶谁疼 2024-08-20 03:44:07

表现。应该具体情况具体分析。我认为将所有内容放在一个表空间中也成为另一个神话！它应该有足够的心轴、足够的 lun 并负责操作系统中的排队。如果有人认为创建一个表空间就足够了，并且与许多表空间一样，而不考虑所有其他因素，这又意味着另一个神话。这取决于！
高可用性。使用单独的表空间可以提高系统的高可用性，以防某些文件损坏、文件系统损坏、块损坏。如果问题仅发生在索引表空间上，则有机会进行在线恢复，并且我们的应用程序仍然可供客户使用。另请参阅： http://richardfoote.wordpress.com/2008/05/02/indexes-in-their-own-tablespace-recoverability-advantages-get-back/
对索引、数据、blob、clob 使用单独的表空间，最终，一些单独的表对于可管理性和成本可能很重要。我们可以使用我们的存储系统来存储我们的 blob、clob，最终归档到具有不同服务质量的不同存储层

回复收藏 0 原文

~没有更多了~