我的意思是:具有 20 列的表是否比仅具有 4 列的表更受益于索引某个字段(用于搜索查询)?
另外:向我不经常搜索但将来可能会在以后搜索的字段添加索引有什么害处?添加索引是否有负面影响?仅仅是它在磁盘上占用的大小,还是添加不必要的索引会使事情运行得更慢?
从评论中提取
我正在使用 Postgres(最新版本),并且我有一个表,我将执行很多 LIKE 类型查询等,但是由于我的客户可以访问 CRUD,因此这些值无疑会经常更改。我应该能想到索引的想法吗?他们只是头疼吗?
我的意思是:具有 20 列的表是否比仅具有 4 列的表更受益于索引某个字段(用于搜索查询)?
另外:向我不经常搜索但将来可能会在以后搜索的字段添加索引有什么害处?添加索引是否有负面影响?仅仅是它在磁盘上占用的大小,还是添加不必要的索引会使事情运行得更慢?
从评论中提取
我正在使用 Postgres(最新版本),并且我有一个表,我将执行很多 LIKE 类型查询等,但是由于我的客户可以访问 CRUD,因此这些值无疑会经常更改。我应该能想到索引的想法吗?他们只是头疼吗?
具有 20 列的表是否比仅具有 4 列的表更受益于索引某个字段(用于搜索查询)?
不,表中的列数与拥有索引的好处无关。
索引仅基于指定列中的值;值的频率将影响您的查询将看到多少好处。例如,包含布尔值的列对于索引来说是一个糟糕的选择,因为该值有 50/50 的可能性是一个或另一个值。在对所有行进行 50/50 拆分时,索引不会缩小对特定行的搜索范围。
将索引添加到我不经常搜索但将来可能会在以后搜索的字段有什么害处?
索引仅在可以使用时加快数据检索,但它们会对 INSERT/UPDATE/DELETE 语句的速度产生负面影响。索引也需要维护以保持其价值。
如果您正在执行 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 并且需要特殊的索引类型。 找到更多。
有个坑,就是全文索引比普通索引复杂,相关的设计决策也不简单。还有一些实现需要额外的维护活动。