我很困惑我在vfp数据库中的每个表的主键和外键上创建索引的优点和缺点。
我一般都知道,如果表有索引,我们可以在互相加入和过滤记录时获得更好的性能 但是当我在表上创建索引时,VFP会在磁盘上创建一个新文件CDX。因此,如果我有10个带主键索引的表,我将有10个CDX文件,总共我将在磁盘上有20个数据文件。磁盘上需要更多空间。例如,
CREATE TABLE orders( ;
odrid I AUTOINC PRIMARY KEY, ;
cusid I, ;
odrcode V(10) ;
)
INDEX ON cusid TAG cudid && index on FOREIGN KEY
它将创建两个文件orders.dbf和orders.cdx。 是否值得在主键和外键上创建索引? 如果索引或没有索引,性能如何不同?
答案 0 :(得分:4)
在每个表的主键和外键字段上创建索引标记是Visual Foxpro数据库中的标准做法。如您所见,执行此操作的典型方法是使用“Index On fieldName Tag Tagname”方法。这将为每个.DBF表创建一个.CDX索引文件。这样做可确保您的查询可以优化。在将记录添加,更改或删除到表中时,.CDX索引文件也会自动更新。
所以是的,值得为每个表以.CDX的形式创建索引标记。不创建索引标记可能会对查询和过滤产生负面影响,尤其是当表中的行数增加时。
答案 1 :(得分:3)
请注意,指数不是"免费" - 所以不要索引你不需要索引的东西。
每次更改文件(添加,更改,删除)时,还必须根据索引表达式和索引过滤条件对相关索引记录进行加密/更改/删除。
大多数情况下,索引文件明显小于原始数据表 - 但是当索引开始上升时,最终可能会有一个大于原始DBF的CDX文件。虽然"磁盘空间很便宜" - 管理该空间内的数据会变得更加昂贵 - 特别是对于索引(因为原始DBF文件只是在表的末尾添加记录 - 索引必须进行更多操作以保持记录顺序)。
指数显然是高效设计的一个非常重要的组成部分,但不要过度指责所有内容,否则会对性能产生负面影响。
答案 2 :(得分:2)
您将没有多个CDX文件 - CDX代表复合索引。因此,如果您创建50个索引标记,它们将全部位于同一CDX中。
除非您在INDEX ON语句中指定单独的非结构CDX文件。因此,如果您正在索引MyTable.DBF并且执行:
Index On field1 tag field1 Of Field1.cdx
Index On field2 tag field2 Of Field2.cdx
...确实会创建多个CDX文件。然而大多数人只是:
Index On field1 tag field1
Index On field2 tag field2
...这意味着所有索引都在一个名为MyTable.Cdx
的结构CDX中您不需要在任何字段上创建索引,包括主键,除非在代码中的Rushmore可优化表达式中使用该字段。例如,SELECT-SQL,SET FILTER,COUNT等。
答案 3 :(得分:2)
绝对使用索引。在FoxPro的早期开发中,当你有一个带索引的表时,你没有复合索引,并且必须显式打开每个表与关联的索引,例如
use YourTable Exclusive
Index on SomeColumn to myIndex1.idx
index on AnotherColumn to myOtherIndex.idx
etc.
then, during your app, you would
use YourTable index myIndex1, myOtherIndex, etc
如果您没有打开所有索引文件并添加或删除,它们就不会同步。
当CDX(复合索引)发挥作用时,数据库会自动打开索引文件,因此它们总是保持同步...所以,上面的内容将转换为......
use YourTable Exclusive
Index on SomeColumn TAG SomeColumn
index on AnotherColumn TAG AnotherCol
// Note... a maximum of 10 characters to identify the "tag" name of the index.
etc.
then, during your app, you would
use YourTable
将自动打开所有复合索引文件,以确保所有索引都可用于查询优化。
现在,如果您有10个表都带有“ID”列,则每个单独的.CDX文件都可以拥有自己的“ID TAG ID索引”作为有效的标记引用,而不会与其他表索引引用冲突。
此外,由于其他人已经说过,你可以让一个表索引20多个索引组合,但仍然将它全部放在一个.CDX文件中,另一个表只有2个索引标记,所以你总能看到这些表在“pair”(。dbf和.cdx)中......除非你的表有一个备忘录字段,否则你也会有.fpt文件。
答案 4 :(得分:2)
指数不是圣杯,但显然更重要的是了解它们如何运作,以及拉什莫尔技术如何利用它们来提高查询的表现:
请花一点时间阅读:
--- Visual FoxPro and Rushmore optimization ---
--- Understanding Rushmore ---
--- Making Rushmore rush more ---
TL; DR:是的,几乎所有的时间都是创建索引,多索引或表达式索引,或者根本不是索引(这就是数据相关命令上有一个no-use-index选项的原因)在VFP上),不要担心磁盘空间,现在它很便宜。
答案 5 :(得分:1)
我曾经在一个长途经销商工作,而且我们的许多FoxPro表都接近2 GB的限制,并且由于Novell服务器中的数据损坏,我每晚都负责重新索引所有表(最终死亡)。
我们在应用程序中取得了出色的性能,这在相当慢的计算机上(1998-1999),这主要是因为Rushmore对我们的应用程序而言是惊人的。通常,我们在每个主键,每个外键以及我们的客户服务部门必须用来为客户提供服务的每个数据(每个电话号码)上都有索引。
一个专家提示给您-有时您可以通过在执行使用Rushmore的操作之前先确定“ ORDER”已启动来获得令人难以置信的速度。像“将订单设置为0”(零)和“向...复制”或“ [任何内容]为”。
FoxPro的Rushmore非常强大,以至于微软购买了FoxPro,并将该技术以改进的形式引入了SQL Server(我相信它仍然是)。
但是...由于过早的优化被认为是邪恶的。只需根据需要添加索引(当性能需要提高时)。可以满足您的要求,并让您以后有机会收取咨询费,并且看起来像超级英雄。
您的最终想法。索引和Rushmore优化非常擅长提高性能,如果是我,我将找到一种方法以某种方式创建RAMDISK并在其上构建索引。这样可以减少物理空间,并且仍然可以利用出色的性能。 RAM很便宜,但是话又说回来,我不知道为什么您的客户端要求您最小化磁盘使用。