标签: database-indexes

SQL Server中的Insert/Update/Delete语句应使用哪种类型的索引(clustered/nonclustrered).我知道它会产生额外的开销,但与非聚集索引相比,它的性能是否更好？另外哪个索引应该用于SQL Server中的Select语句？

表定义,注意UNIQUE索引:

CREATE TABLE meta
(
  id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  type SET('tag', 'keyword') NOT NULL,
  name VARCHAR(255) NOT NULL,
  user_id INT UNSIGNED NOT NULL,
  UNIQUE (name, type, user_id),
  FOREIGN KEY (user_id) REFERENCES user (id) ON DELETE CASCADE
);

所以MySQL应该WHERE name = 'tag' and type = 'cat'只在搜索中使用索引(仅限最左边的前缀)WHERE type = 'tag'.

我做了:

EXPLAIN SELECT * FROM meta WHERE type = 'tag'

结果是(第五栏possible_keys):

'1', 'SIMPLE', 'meta', 'ALL', NULL, NULL, NULL, NULL, '1', 'Using where' …

GATE1999_2.25

以下哪项是正确的？

A) An SQL query automatically eliminates duplicates
B) An SQL query will not work if there are no indexes on the relations
C) SQL permits attribute names to be repeated in the same relation
D) None of the above

这是GATE 1999竞争考试题.很容易消除选项A和C.请回答选项B是否正确,为什么？

我已经浏览了多个数据库的SQL章节,也在线搜索过,但我没有找到任何关于索引对SQL查询的影响的参考,这可以回答这个问题.

在我的Cockroach数据库中有一个包含以下定义的表:

CREATE TABLE foo_value (
    foo_id_a INT NOT NULL,
    foo_id_b INT NOT NULL,
    value FLOAT NULL,
    create_date_time TIMESTAMP NULL,
    update_date_time TIMESTAMP NULL,
    CONSTRAINT "primary" PRIMARY KEY (foo_id_a ASC, foo_id_b ASC),
    INDEX foo_value_foo_id_a_foo_id_b_idx (foo_id_a ASC, foo_id_b ASC),
    INDEX foo_id_a_idx (foo_id_a ASC),
    INDEX foo_id_b_idx (foo_id_b ASC),
    FAMILY "primary" (foo_id_a, foo_id_b, value, create_date_time, update_date_time)
)

它包含大约400000行.

查询两个ID中的一个很快:

SELECT * FROM foo_db.foo_value WHERE foo_id_a = 123456;
takes 0.071 s

SELECT * FROM foo_db.foo_value WHERE foo_id_b = 123456;
takes 0.086 s

但是查询OR另一个是非常慢的:

SELECT …

我的意思是:具有20列的表是否比仅具有4列的表对索引特定字段(在搜索查询中使用的字段)中获益更多？

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

从评论中提取

我正在使用Postgres(最新版本),我有一个表,我将做很多LIKE类型查询等,但由于我的客户可以访问CRUD,因此值无疑会经常更改.我可以理解索引吗？他们只是头疼吗？

我有一个小问题：主索引和二级索引的性能有什么区别？是什么导致了这种差异？

我在谷歌搜索，我已经看到二级索引存储在另一个表中，所以这会减慢所有操作..但是还有其他一些原因可以证明这种性能下降是合理的吗？

非常感谢

我试图插入/更新我的SQL表有这个定义:

CREATE TABLE `place`.`a_table` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`some_id` bigint(20) NOT NULL,
`someOther_id` bigint(20) NOT NULL,
`some_value` text,
`re_id` bigint(20) NOT NULL DEFAULT '0',
`up_id` bigint(20) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `some_id_key` (`some_id`),
KEY `some_id_index1` (`some_id`,`someOther_id`),
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8mb4;

如您所见,some_id和someOther_id共享一个索引.

我正在尝试执行我的插入/更新语句,如下所示:

INSERT INTO `a_table` (`re_id`,`some_id`,`someOther_id`,`up_id`,`some_value`) VALUES      
(100,181,7,101,'stuff in the memo wow') On DUPLICATE KEY UPDATE 
`up_id`=101,`some_value`='sampleValues'

我希望因为我没有指定id,所以它将作为插入/更新规则返回到索引键(some_id_index1).但是,它只是插入.

显然这是不正确的.我在这做错了什么？

嗨,我希望我能得到一些关于如何优化我的数据库的帮助,所以它不需要一年.我知道要加快速度,我需要添加索引,但我不确定我应该添加它们.

继承我数据库中的三个表:

CREATE TABLE IF NOT EXISTS `journeyPattern2` (
  `journeyPatternId` int(11) NOT NULL AUTO_INCREMENT,
  `serviceId` int(11) NOT NULL,
  `direction` enum('inbound','outbound') NOT NULL,
  PRIMARY KEY (`journeyPatternId`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `journeyPatternTimingLink2` (
  `journeyPatternTimingLinkId` int(11) NOT NULL AUTO_INCREMENT,
  `journeyPatternId` int(11) NOT NULL,
  `from` varchar(15) NOT NULL,
  `to` varchar(15) NOT NULL,
  `direction` enum('inbound','outbound') NOT NULL,
  `runTime` varchar(15) NOT NULL,
  PRIMARY KEY (`journeyPatternTimingLinkId`),
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

CREATE TABLE IF NOT EXISTS `line` (
  `lineId` int(11) …

编辑

这不是关于空间的问题，而是关于索引的唯一性，它会影响查询计划。

就基数而言，哪个索引场景更高：

一种

Table:
(
  Col1 smallint,
  Col2 smallint
)

在哪里

Range Col1 : 0 - 1000
Range Col2 : 0 - 1000

和 上的复合索引(Col1, Col2)，始终按顺序查询。

乙

桌子：

(
  Col1_2 int
)

在哪里

Range Col1_2 : 0 - 1000^2

以及(Col1_2)结合 Col1 和 Col2 组件的存储和查询的单个索引。

我基本上要问的是，将多个小数字组合在一起（散列）更好（如在索引使用中），还是没有区别？

我运行以下查询来估计从内存读取的索引页（缓冲区命中）与从磁盘读取的索引页的比率

select
    t.schemaname, 
    t.relname as "Table Name", 
    io_i.indexrelname as "Index Name", 
    case when (io_i.idx_blks_hit <> 0 or io_i.idx_blks_read <> 0) then 
    round(io_i.idx_blks_hit/(io_i.idx_blks_hit::numeric + 
    io_i.idx_blks_read::numeric), 4) else null end as "Index Hit Ratio" 
from 
    pg_stat_user_tables t
    join pg_statio_user_indexes io_i on io_i.relid = t.relid 
order by "Index Hit Ratio" desc;

我有几个指数，这个比率太低（低于 0.7）。请告知可能的原因以及如何改进。

我有一个conversation_views包含列的表：user_id | conversation_id | viewed_at

还有一个INDEX on conversation_views (conversation_id, user_id)

我想查询：

select
  max(viewed_at)
from conversation_views
where
  conversation_id=%L
  and user_id=%L

通过此索引，该查询的性能是否良好，或者我可以使用其他策略吗？我正在使用 Postgres 9.6.12。

来自数据库系统概念

我们使用术语哈希索引来表示哈希文件结构以及辅助哈希索引。严格来说，哈希索引只是二级索引结构。 永远不需要哈希索引作为聚簇索引结构，因为如果文件本身是通过哈希进行组织的，则不需要在其上使用单独的哈希索引结构。但是，由于哈希文件组织提供了与索引提供的记录相同的直接访问，因此我们假装通过哈希组织的文件也具有聚类哈希索引。

“二级索引”和“非聚集索引”（我从书中了解到）的概念是否相同？

哈希索引永远不会是聚簇索引吗？

您是否可以重新解释或解释为什么“永远不需要哈希索引作为聚簇索引结构”的原因是“如果文件本身是通过哈希组织的，则不需要在其上使用单独的哈希索引结构”？如果“文件本身不是通过散列来组织的”，该怎么办？

谢谢。