标签: database-indexes

我在Sql Server 2005中工作.我有一个跟踪用户操作的事件日志表,我想确保尽可能快地插入表中.目前该表没有任何索引.添加单个非聚集索引是否会减慢插入速度？或者只是减慢插入的聚集索引？或者我应该只添加聚集索引而不用担心它？

对于我来说,将索引放在日期字段上是否会有任何实际好处,这些日期字段将主要用于使用类似的东西的查询中.

dateField < 'var'

和

'var' BETWEEN dateField1 AND dateField2

搜索得到了很多,但我从来没有对它们进行直接比较"=".

因此,当我遵循Michael Hartl的Ruby on Rails教程时,我注意到在users表中我们为该:email属性添加了一个唯一索引,以提高find方法的效率,因此它不会逐行搜索.到目前为止,我们一直在使用两者find_by_email并find_by_id根据具体情况进行搜索.然而,我们从未为:id属性设置索引 .是否:id自动编入索引,因为它在默认情况下是唯一且顺序的？或者不是这种情况,我应该添加:id搜索索引吗？

我有一个SELECT声明,我想优化.在MySQL的-为了通过优化说,在某些情况下,该指数不能用来优化ORDER BY.具体来说:

在键的非连续部分使用ORDER BY
SELECT*FROM t1 WHERE key2 = constant ORDER BY key_part2;

让我思考,这可能是这种情况.我正在使用以下索引:

UNIQUE KEY `met_value_index1` (`RTU_NB`,`DATETIME`,`MP_NB`),
KEY `met_value_index` (`DATETIME`,`RTU_NB`)

使用以下SQL语句:

SELECT * FROM met_value
WHERE rtu_nb=constant
AND mp_nb=constant
AND datetime BETWEEN constant AND constant
ORDER BY mp_nb, datetime

• 难道是足够删除索引met_value_index1,并与新的排序创建它RTU_NB,MP_NB,DATETIME？
• 我是否必须将RTU_NB包含在该ORDER BY子句中？

使用models.varchar(...)字段创建模型时,varchar_pattern_ops正在创建索引.

这是postgresql中生成的表

              Table "public.logger_btilog"
      Column      |           Type           | Modifiers 
------------------+--------------------------+-----------
 md5hash          | text                     | 
 id               | integer                  | not null
Indexes:
    "logger_btilog_pkey" PRIMARY KEY, btree (id)
    "logger_btilog_md5hash_6454d7bb20588b61_like" btree (md5hash varchar_pattern_ops)

我想varchar_pattern_ops在迁移中删除该索引,并在该字段中添加哈希索引.

我试过这样做:

# models.py
class Btilog(models.Model):
    md5hash = models.TextField(db_index=False)
    [...]

并且在迁移中也强制添加 db_field=False

# 0013_migration.py
# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations


class Migration(migrations.Migration):

    dependencies = [
        ('logger', '0014_btilog_id'),
    ]

    operations = [
        # this should remove all …

在Google上搜索联接表索引时,我遇到了这个问题.

现在,我相信它在接受的答案中提供了一些虚假信息,或者我不明白一切是如何运作的.给出以下表格(在PostGreSQL 9.4上运行):

CREATE TABLE "albums" ("album_id" serial PRIMARY KEY, "album_name" text)
CREATE TABLE "artists" ("artist_id" serial PRIMARY KEY, "artist_name" text)
CREATE TABLE "albums_artists" ("album_id" integer REFERENCES "albums", "artist_id" integer REFERENCES "artists")

我试图从上面提到的问题复制场景,首先在albums_artists表的两列上创建一个索引,然后为每列创建一个索引(不保留两列上的索引).

当使用EXPLAIN命令进行普通的传统选择时,我会期待非常不同的结果,如下所示:

SELECT "artists".* FROM "test"."artists"
    INNER JOIN "test"."albums_artists" ON ("albums_artists"."artist_id" = "artists"."artist_id")
    WHERE ("albums_artists"."album_id" = 1)

但是,当实际运行解释时,我得到的结果与每种情况完全相同(每列上有一个索引,两列上有一个索引).

我一直在阅读文档PostgreSQL的关于索引,并没有作出,我得到的结果任何意义:

Hash Join  (cost=15.05..42.07 rows=11 width=36) (actual time=0.024..0.025 rows=1 loops=1)
  Hash Cond: (artists.artist_id = albums_artists.artist_id)
  ->  Seq Scan on artists  (cost=0.00..22.30 rows=1230 width=36) (actual …

描述：这是性能问题的示例演示。

我们首先创建了两个表，启用了行级安全性，还创建了策略。

表定义：

create table sample_schema.sample_table1(ID numeric(38) PRIMARY KEY NOT NULL,
                 tenant_id VARCHAR(255) NOT NULL,
                 Description VARCHAR(255)
        );

create table sample_schema.sample_table2(ID2 numeric(38) PRIMARY KEY NOT NULL,
                 tenant_id VARCHAR(255) NOT NULL,
                 table1_id numeric (38),
                 Description2 VARCHAR(255)
        );    

索引创建：

CREATE UNIQUE INDEX sample_table1_idx1 ON sample_schema.sample_table1(tenant_id,id);            

启用行级安全性：

ALTER TABLE sample_schema.sample_table1 ENABLE ROW LEVEL SECURITY;   

创建角色：

CREATE ROLE tenant_grp_role_p_id;    

创建策略：我希望策略选择tenant_id列值具有与登录用户相同角色的数据。

CREATE POLICY Tenant_Roles ON  sample_schema.sample_table1 TO tenant_grp_role_p_id USING ((tenant_id) IN ( SELECT rolname FROM pg_roles WHERE    pg_has_role( current_user, oid, 'member')));

创建样本数据：

insert into sample_schema.sample_table1 …

所以我使用 pg_dump 备份了一个表：

pg_dump -U bob -F c -d commerce -t orders > orders.dump

该表有几个列出的索引，例如主键

但是，当我使用 pg_restore 将此表恢复到另一个系统上的开发数据库时：

pg_restore -U bob -d commerce -t orders > orders.dump

未列出主键或索引

我究竟做错了什么？

寻找视图，我可以列出 PostgreSQL 中的所有“无效”对象。在 Oracle 中，我们可以使用 dab_objects.status 列，但我不确定在 PostgreSQL 中是否有一种简单的方法可以做到这一点。

也许，我可以使用以下代码检查无效索引。我怎样才能为其他对象做到这一点？

SELECT pg_class.relname 
FROM pg_class, pg_index 
WHERE pg_index.indisvalid = false 
AND pg_index.indexrelid = pg_class.oid;

用于在数据库表中建立索引的数据结构是 B-Tree（默认，B-Tree、R-Tree、Hash）。既然 B-Tree 中的查找、删除和插入都可以在对数时间内完成，那么为什么只有索引表的读取速度更快，而写入速度却更慢呢？