索引在SQL中有吸引力吗?

不是指数会糟糕。它把索引放在错误的列上会很糟糕。

还有20张桌子?我建议你读一读 database design 首先,或者向我们解释你的问题的背景。

索引(或索引)并不糟糕。在过去的几十年里,很多非常聪明的人花了相当多的时间来确保这一点。

然而,你的模式,缺乏同样的专业知识和努力,可能会非常糟糕。

YMMV公司。

简而言之: 指标糟糕吗:是和否

更长的答案: 如果使用得当的话,它们不会很烂。也许你应该开始阅读索引是如何工作的,为什么它们可以工作,为什么有时它们不工作。

http://www.sqlservercentral.com/articles/Indexing/

没有索引是不好的,但是您必须注意如何使用它们,否则它们会影响查询的性能。

为什么要创建只有一列的表?这可能是正常化的一步远。在优化性能时,数据库设计是最重要的考虑事项之一

第二:索引

对于索引扫描来说,数据库表中有多少记录并不重要。由于使用了(平衡的)二叉树搜索,将记录数量加倍只会导致一个额外的搜索步骤。

确定表的主键后,SQL将自动在该列上放置聚集索引。聚集索引的性能非常好。此外,还可以在SELECT、JOIN、WHERE、GROUP BY和ORDER BY语句中经常使用的列上放置非聚集索引。请记住,索引有一定的重叠,尽量不要将聚集索引包含到非聚集索引中。

同样有趣的是索引上的填充因子。是否要优化表的读取(高填充因子-更少存储,更少IO)或写入(低填充因子-更多存储,更少重建数据库页)。

第三:分区
使用分区的原因之一是优化数据访问。假设您有100万条记录,其中50万条记录不再相关,而是存储用于存档。在这种情况下,您可以决定对表进行分区,并将500000条旧记录存储在慢速存储上,而将其他500000条记录存储在快速存储上。

衡量就是知道
了解发生了什么的最好方法是测量cpu和io发生了什么。Microsoft SQL server有一些工具,比如Profiler和Management Studio中的执行计划,这些工具将告诉您查询的持续时间、读/写次数和cpu使用情况。此外,执行计划还将告诉您正在使用哪些索引或是否正在使用索引。令你惊讶的是,你可能会看到一个表扫描,尽管你没有预料到。

假设我有一个包含大量行和一列的表,我想为其建立索引,它可以有20个值之一。如果我在列上放一个索引,它会很大吗?

索引大小将与行数和索引值的长度成比例。

索引不仅保留索引值,还保留指向行的某种指针( ROWID 在里面 Oracle , LCID PostgreSQL ,主键输入 InnoDB 等等)。

如果你有 10,000 行和1个不同的值 10000个

如果是,为什么?如果我将数据分成20个表,每个表对应一个列的值,那么索引大小将很小,但是索引效果将是相同的

事实上,这种技术有时在这种所谓的分区索引中使用。它有它的优点和缺点。

标准的b树索引最适合于具有相当选择性的索引,本例不适合这种情况。您不会说您使用的是什么DBMS;Oracle有另一种类型的索引,称为位图索引,它更适合OLAP环境中的低选择性索引(因为这些索引维护成本高昂,不适合OLTP环境)。

乐观主义者将根据统计数据来决定是否认为索引将有助于在最快的时间获取数据;如果不这样做,optmiser将不会使用它。

对不起,我不太明白你说的“大”是什么意思。

• 如果索引是非聚集的,那么只有与索引相关的数据才会出现在叶页上。然后,取决于你有多少其他索引,再加上像填充因子这样的细节,你的索引可能是有效的,也可能不是有效的。一般来说,如果表中没有大量索引,那么应该是安全的。

• 索引的效率还将取决于要进入列的20个值的数据类型。如果这些是预定义的值,那么它们的详细信息可能应该在具有简单主键数据类型(如Int/Number)的查找表中。然后将该列作为外键添加到表中,并在列上添加索引。

索引纯粹是为了性能。如果索引不能提高您感兴趣的查询的性能,那么它就很糟糕。

至于磁盘的使用,你必须权衡一下你的担忧。不同的SQL提供程序构建索引的方式不同,但是作为客户机,您通常相信它们尽了最大的努力。在您所描述的情况下,聚集索引可能对大小和性能都是最佳的。

它将足够大,可以按排序顺序保存所有行的这些值。