数据库索引 - 表大小重要吗?

发布于 2024-10-03 01:49:30 字数 288 浏览 14 评论 0原文

我的意思是:与只有 4 列的表相比,具有 20 列的表是否从某个字段(在搜索式查询中使用的字段)建立索引中获益更多?

另外:将索引添加到我不经常搜索但将来可能会搜索的字段有什么危害?添加索引有负面影响吗?这只是它在磁盘上占用的大小,还是添加不必要的索引会使运行速度变慢?

从评论中提取

我正在使用 Postgres(最新版本),并且我有一个表,我将在其中执行大量 LIKE 类型查询等,但这些值无疑会经常更改,因为我的客户访问 CRUD。我应该了解索引的想法吗?他们只是头痛吗?

What I mean is: Does a table with 20 columns benefit more from indexing a certain field (one that's used in search-ish queries) than a table that has just 4 columns?

Also: What is the harm in adding index to fields that I don't search with much, but might later in the future? Is there a negative to adding indexes? Is it just the size it takes up on disk, or can it make things run slower to add unnecessary indexes?

extracted from a comment

I'm using Postgres (latest version) and I have one table that I'll be doing a lot of LIKE type queries, etc but the values will undoubtedly change often since my clients have access to CRUD. Should I can the idea of indexes? Are they just a headache?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(2

残花月 2024-10-10 01:49:30

与只有 4 列的表相比,具有 20 列的表是否能从对某个字段(在类似搜索的查询中使用的字段)建立索引中获益更多?

不,表中的列数与索引的好处没有关系。

索引仅针对指定列中的值;值的频率将影响您的查询将获得多少好处。例如,包含布尔值的列对于索引来说是一个糟糕的选择,因为该值有 50/50 的机会成为其中一个值或另一个值。当所有行按 50/50 分割时,索引不会缩小对特定行的搜索范围。

向我不经常搜索但以后可能会搜索的字段添加索引有什么危害?

索引仅在可以使用时加速数据检索,但它们会对 INSERT/UPDATE/DELETE 语句的速度产生负面影响。索引也需要维护以保持其价值。

Does a table with 20 columns benefit more from indexing a certain field (one that's used in search-ish queries) than a table that has just 4 columns?

No, number of columns in a table has no bearing on benefits from having an index.

An index is solely on the values in the column(s) specified; it's the frequency of the values that will impact how much benefit your queries will see. For example, a column containing a boolean value is a poor choice for indexing, because it's a 50/50 chance the value will be one or the other value. At a 50/50 split over all the rows, the index doesn't narrow the search for a particular row.

What is the harm in adding index to fields that I don't search with much, but might later in the future?

Indexes only speed up data retrieval when they can be used, but they negatively impact the speed of INSERT/UPDATE/DELETE statements. Indexes also require maintenance to keep their value.

南风几经秋 2024-10-10 01:49:30

如果您正在执行 LIKE 查询,您可能会发现索引无论如何都没有多大帮助。虽然索引可能会改进这个查询……

select * from t23
where whatever like 'SOMETHING%'
/

索引不太可能对这些查询有帮助……

select * from t23
where whatever like '%SOMETHING%'
/

select * from t23
where whatever like '%SOMETHING'
/

如果您有自由文本字段并且您的用户需要模糊匹配,那么您应该查看 Postgres 的全文功能。这使用 MATCH 运算符而不是 LIKE,并且需要特殊的索引类型。 了解更多信息。

有一个陷阱,即全文索引比普通索引更复杂,与 相关设计决策并不简单。此外,某些实现还需要额外的维护活动

If you are doing LIKE queries you may find that indexes are not not much help anyway. While an index might improve this query ...

select * from t23
where whatever like 'SOMETHING%'
/

... it is unlikely that an index will help with either of these queries ...

select * from t23
where whatever like '%SOMETHING%'
/

select * from t23
where whatever like '%SOMETHING'
/

If you have free text fields and your users need fuzzy matching then you should look at Postgres's full text functionality. This employs the MATCH operator rather than LIKE and which requires a special index type. Find out more.

There is a gotcha, which is that full text indexes are more complicated than normal ones, and the related design decisions are not simple. Also some implementations require additional maintenance activities.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文