Questions tagged «index»

我有一个大约有6000万行的表，该表按状态划分为53个子表。这些表“继承”大表，如下所示： CREATE TABLE b2b_ak (LIKE b2b including indexes, CHECK ( state = 'AK') ) INHERITS (b2b8) TABLESPACE B2B; 我的问题是：如果在copy语句完成后才在b2b8上建立索引，那么子表会继承索引吗？换句话说，我想这样做： Create b2b8 Create b2b8_ak inherits b2b8 COPY b2b8 FROM bigcsvfile.csv CREATE INDEX CONCURRENTLY 事实证明，已经在子表上创建了所有索引。

9 postgresql  index  copy 

这两个表具有相同的结构，并且每个表中都有19972行。为了练习索引，我创建了两个具有相同结构的表并创建了 clustered index on persontb(BusinessEntityID) 和 nonclustered index on Persontb_NC(BusinessEntityId) 和表结构 BusinessEntityID int FirstName varchar(100) LastName varchar(100) -- Nonclusted key on businessentityid takes 38% SELECT BusinessEntityId from Persontb_NC WHERE businessentityid BETWEEN 400 AND 4000 -- CLustered key businessentityid takes 62% SELECT BusinessEntityId from persontb WHERE businessentityid BETWEEN 400 AND 4000 …

9 sql-server  sql-server-2008-r2  index 

我正在尝试为包含多个索引列的SQLite DB估计数据库大小（在磁盘上）。这些列的类型为（SQLite）Integer和String。用这些列估算每行的大小很简单，但是由于索引，我不确定如何考虑额外的每行填充。最好的方法是什么？

9 index  sqlite  size 

我是索引编制的新手，并介绍了索引编制的基础知识。我可以在相应表的索引部分内找到主键约束的默认聚集索引，但是创建外键约束后，我找不到任何索引。 现在我有一个要求，应该在其中实施索引以提高性能。我已经读过关于索引外键以提高JOIN结果的性能的信息。 我是否需要将外键列添加到其他非聚集索引中，或者外键具有默认索引？ 如果我的SQL表结构如下并且我使用t1_col3的WHERE子句进行了JOIN查询，如何有效地实现索引 table1 table2 ------ ------ t1_col1(pk) t2_col1(pk) t1_col2 t2_col2 t1_col3 t2_col3 t1_col4 t2_col4 t2_col1(FK)

9 sql-server  index 

我有以下查询，使用MariaDB 10 / InnoDB： SELECT id, sender_id, receiver_id, thread_id, date_created, content FROM user_message WHERE thread_id = 12345 AND placeholder = FALSE ORDER BY date_created DESC LIMIT 20 该查询根据给定的条件获取消息，并按创建日期排序。 我的覆盖范围超过(thread_id, date_created)。 当运行EXPLAIN时，使用正确的索引，尽管查询使用的是语句中间不在索引中的列，但我得到的输出为“在哪里使用”。我可以将任何值用于“占位符= x”，并且结果相同。 如果我将排序更改为使用另一列，则EXPLAIN正确指示“在哪里使用。使用文件排序”。 我正在抓头。有人可以阐明这一点吗？我希望看到的是，由于覆盖列无法完全使用，因此需要额外的文件排序。

8 index  innodb  mariadb  covering-index 

设定 我有一个约115,382,254行的巨大表。该表相对简单，并且记录了应用程序的处理操作。 CREATE TABLE [data].[OperationData]( [SourceDeciveID] [bigint] NOT NULL, [FileSource] [nvarchar](256) NOT NULL, [Size] [bigint] NULL, [Begin] [datetime2](7) NULL, [End] [datetime2](7) NOT NULL, [Date] AS (isnull(CONVERT([date],[End]),CONVERT([date],'19000101',(112)))) PERSISTED NOT NULL, [DataSetCount] [bigint] NULL, [Result] [int] NULL, [Error] [nvarchar](max) NULL, [Status] [int] NULL, CONSTRAINT [PK_OperationData] PRIMARY KEY CLUSTERED ( [SourceDeviceID] ASC, [FileSource] …

8 sql-server  index  partitioning  azure-sql-database 

对于支持哈希索引的每个Postgres版本，都有警告或注意，至少在8.3版之前，哈希索引比btree索引“相似或更慢”或“不更好” 。从文档： 版本7.2： 注意：由于哈希索引的用途有限，因此通常应优先选择B树索引而不是哈希索引。我们没有足够的证据表明即使进行=比较，哈希索引实际上也比B树更快。而且，散列索引需要更粗的锁。参见第9.7节。 版本7.3（以及最高8.2）： 注意：测试表明PostgreSQL的哈希索引与 B树索引相似或比B树索引慢，并且哈希索引的索引大小和构建时间要差得多。在高并发下，哈希索引的性能也很差。由于这些原因，不鼓励使用哈希索引。 版本8.3： 注意：测试表明PostgreSQL的哈希索引的性能并不比B树索引好，并且哈希索引的索引大小和构建时间要差得多。此外，哈希索引操作目前还没有进行WAL记录，因此在数据库崩溃后可能需要使用REINDEX重建哈希索引。由于这些原因，目前不鼓励使用哈希索引。 他们声称在此版本8.0线程中，从未发现哈希索引实际上比btree更快的情况。 即使是在9.2版中，根据该博客文章（2016年3月14日）： AndréBarbosa撰写的Postgres哈希索引，除编写实际索引外，其他任何方面的性能提升也几乎没有。 我的问题是那怎么可能？ 根据定义，哈希索引是一个O(1)操作，其中btree是一个O(log n)操作。那么，O(1)查找比查找正确的分支然后查找正确的记录要慢（或什至类似于）的可能性如何呢？ 我想知道索引理论到底有什么可能！

8 postgresql  index  btree  hashing 

我有一个堆表，该表占用约104 GB的磁盘空间，近30亿行。我正在尝试在[ WeekEndingDate]列上的此表上创建聚簇索引。我在数据文件中有大约200 GB的可用空间，在tempdb中有大约280 GB的可用空间。 我尝试了两种不同的方法。首先是使用以下命令直接在表上创建索引： CREATE CLUSTERED INDEX CX_WT_FOLD_HISTORY ON WT_FOLD_HISTORY (WeekEndingDate ASC) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = ON, IGNORE_DUP_KEY = OFF , ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, DATA_COMPRESSION = PAGE) 我尝试了SORT_IN_TEMPDB = ON和OFF。使用时，ON它会填满tempdb，并OFF填满数据驱动器。 另一种方法是使用所需索引创建一个新的空白表，然后将堆中的记录插入到新表中。填满数据驱动器后，此操作也失败。 关于该怎么做的其他建议。我读过的大多数内容都表明，在创建索引时，需要大约1.2倍的表大小才能用作工作空间。我有更多的方法，但仍然失败。任何建议，将不胜感激。 这是我原来的堆表结构： CREATE TABLE [dbo].[WT_FOLD_HISTORY]( [WeekEndingDate] …

8 sql-server  sql-server-2008  index  clustered-index 

我正在尝试SQLite3使用json_extract表达式在（3.18）中创建索引。我的目标是执行只需要索引即可产生结果的查询。这样做的原因是json_extract操作昂贵，在较大的数据集和/或值上进行操作时会降低性能。我得出结论，我需要一个覆盖指数来满足我的需求。 步骤1-使用标准表结构测试理论 CREATE TABLE Player ( Id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, FirstName TEXT NOT NULL, MiddleName TEXT, LastName TEXT NOT NULL ); CREATE INDEX Player_FirstName ON Player ( FirstName ASC, LastName ASC ); EXPLAIN QUERY PLAN SELECT FirstName, LastName FROM Player WHERE LENGTH(LastName) > 10 ORDER BY FirstName …

8 index  optimization  execution-plan  sqlite 

在查看实际的执行计划时，即使查询所用的时间少于1秒，它也会显示缺少的索引。 SELECT Account.AccountID, Account.Name FROM account LEFT OUTER JOIN accountfeaturesetting afs ON afs.accountid = account.accountid and afs.featureid = 'Schedules' and afs.settingid = 'EditReasons' WHERE ISNULL(afs.Value, '0') = '0' AND EXISTS (SELECT 1 FROM program WHERE program.AccountID = account.AccountID AND program.Active = 1 AND (program.ScheduleEditReasonFlags <> 0 OR program.ScheduleEditReasonFields <> 0)) …

8 sql-server  index  execution-plan 

在MySQL，MyISAM和InnoDB中，不是索引的列是否与索引一起在磁盘上排序？ 我开始写一个错误的想法： 我认为可能不会，因为它们没有索引。如果将它们排序，则意味着它们是索引。 这是不正确的，因为每个索引列均按其自身内容的顺序排序，但是我要询问的是每一行（或仅某些列）及其相应索引的排序。 解释一下，我说：这对于使选择行的范围（按索引并排在一起）的速度更快很有用。例如，如果我想select * where id >1000 and id<2000（MySQL语法中可能有错误，我不太了解），那么可以快速从磁盘读取id列本身，因为它的1000到2000的单元可能一起位于物理磁盘上。但是可以将与id 1000到2000对应的其他列内容写入物理磁盘上的不同位置。如果还对它们进行了排序，则读取速度会更快。我认为，也许MySQL会自动对物理磁盘上的该列进行排序，以实现此类操作。 它们是否在其他类型的数据库（PostgreSQL等）中排序？ 12月27日：从这两个答案中可以看到，在存在聚集索引/主键的情况下，简单行本身并未在物理磁盘上排序（正如我认为的那样/可能），甚至聚集索引也是没有排序，如果它是b树，我已经阅读了有关b树的信息，并且据我了解，它的节点停留在磁盘上的随机位置。

8 mysql  index  database-internals 

我有一个表，其中包含从文本文档中提取的数据。数据存储在名为"CONTENT"GIN 的列中，为此我创建了该索引： CREATE INDEX "File_contentIndex" ON "File" USING gin (setweight(to_tsvector('english'::regconfig , COALESCE("CONTENT", ''::character varying)::text), 'C'::"char")); 我使用以下查询在表上执行全文搜索： SELECT "ITEMID", ts_rank(setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') , plainto_tsquery('english', 'searchTerm')) AS "RANK" FROM "File" WHERE setweight(to_tsvector('english', coalesce("CONTENT",'')), 'C') @@ plainto_tsquery('english', 'searchTerm') ORDER BY "RANK" DESC LIMIT 5; “文件”表包含25万行，每个"CONTENT"条目均包含一个随机词和一个文本字符串，所有行均相同。 现在，当我搜索一个随机单词（整个表中有1个匹配项）时，查询运行非常快（<100毫秒）。但是，当我搜索所有行中都存在的单词时，查询运行非常慢（10分钟或更长时间）。 EXPLAIN ANALYZE显示对于1命中搜索，先执行位图索引扫描，再执行位图堆扫描。对于慢速搜索，将执行Seq扫描，这花费了很长时间。 当然，在所有行中都有相同的数据是不现实的。但是，由于我无法控制用户上载的文本文档，也无法控制用户执行的搜索，因此可能会出现类似的情况（搜索数据库中出现率很高的术语）。在这种情况下，如何提高搜索查询的性能？ 运行PostgreSQL 9.3.4 查询计划EXPLAIN ANALYZE： …

8 postgresql  performance  index  postgresql-9.3  full-text-search 

我正在调整一些索引，看到一些问题想听取您的建议 在1个表上有3个索引 dbo.Address.IX_Address_ProfileId [1 KEY] ProfileId {int 4} Reads: 0 Writes:10,519 dbo.Address.IX_Address [2 KEYS] ProfileId {int 4}, InstanceId {int 4} Reads: 0 Writes:10,523 dbo.Address.IX_Address_profile_instance_addresstype [3 KEYS] ProfileId {int 4}, InstanceId {int 4}, AddressType {int 4} Reads: 149677 (53,247 seek) Writes:10,523 1-我真的需要前两个索引，还是应该删除它们？ 2-正在运行的查询使用profileid = xxxx的使用条件，以及其他使用profileid = xxxx且InstanceID = xxxxxx的使用条件。为什么优化器选择第三索引而不是第一索引或第二索引？ 我也正在运行一个查询，使每个索引上的Lock等待。如果我得到这些计数，应该怎么做才能调整该指数？ Row …

8 sql-server  index  index-tuning 

我正在为一个跟踪使用时间的分析系统设计一个模式，并且需要查看特定日期范围内的总使用时间。 举一个简单的例子，这种查询类型将经常运行： select sum(diff_ms) from writetest_table where time_on > ("2015-07-13 15:11:56"); 在人口众多的表上，此查询通常需要7秒钟左右。它有约3500万行，运行在Amazon RDS（db.m3.xlarge）上的MySQL上的MyISAM。 摆脱WHERE子句可以使查询仅花费4秒，而添加第二个子句（time_off> XXX）则需要增加1.5秒，从而使查询时间达到8.5秒。 因为我知道通常会完成这些类型的查询，所以我想优化一些东西，使其更快，最好在5秒以下。 我从在time_on上添加索引开始，尽管它大大加快了WHERE“ =”查询，但对“>”查询没有影响。有没有一种方法可以创建可以加快WHERE“>”或“ <”查询的索引？ 或者，如果还有其他建议可以查询此类查询的性能，请告诉我。 注意：我使用“ diff_ms”字段作为非规范化步骤（它等于time_off-time_on），这将聚合的性能提高了大约30％-40％。 我正在使用以下命令创建索引： ALTER TABLE writetest_table ADD INDEX time_on (time_on) USING BTREE; 在原始查询上运行“ explain”（使用“ time_on>”）时，time_on是“ possible_key”，而select_type是“ SIMPLE”。“额外”列显示“在何处使用”，“类型”为“全部”。添加索引后，该表显示“ time_on”是“ MUL”键类型，由于同一时间可以出现两次，因此这似乎是正确的。 这是表模式： CREATE TABLE `writetest_table` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, …

8 mysql  performance  index  select  myisam 

我们正在解决与供应商长期存在的问题。他们的软件倾向于冻结并每周停止一次或两次工作，从而严重干扰我们的运营。尽管我们向他们发送了许多GB的日志和数据库备份，但他们无法确定原因。最近，他们开始暗示问题出在我们的维护上，而不是软件方面（尽管没有长期运行的查询，CPU / RAM / IO压力，甚至在出现问题时出现死锁）。特别是他们说我们的索引是一个问题。 尽管我认为MS不赞成使用该工具，但他们最喜欢使用的工具是DBCC showcontig。他们特别着迷于扫描密度和范围碎片。为了消除借口，我建立了一些积极的夜间维护措施，以小于90％的扫描密度或大于10％的碎片重建索引。这多少使它们脱离了扫描密度列，但是它们仍然专注于范围碎片。DBCC showcontig即使在几个小时之前重建的索引上也显示出高度碎片。下面是dbcc_showcontig和sys.dm_db_index_physical_stats的结果，它们指向的表是“可能的问题”。 DBCC SHOWCONTIG 已扫描的页面................................：1222108 扫描范围.....................：152964 范围开关.....................：180904 平均 每个范围的页数...........................：8.0 扫描密度[最佳计数：实际计数] ..：84.44％[152764：180905] 逻辑扫描碎片..................：3.24％ 扩展扫描碎片....................：35.97％ 平均 每页可用字节数.....................：692.5 平均 页面密度（完整）.....................：91.44％ sys.dm_db_index_physical_stats index_type_desc alloc_unit_type_desc Avg_fragmentation_in_percent page_count CLUSTERED INDEX IN_ROW_DATA 3.236803129 1222070 NONCLUSTERED INDEX IN_ROW_DATA 0.680074642 48230 NONCLUSTERED INDEX IN_ROW_DATA 0.093237195 48264 NONCLUSTERED INDEX IN_ROW_DATA 0.03315856 48253 NONCLUSTERED INDEX …

8 sql-server  performance  index