bio*_*geo 6 mysql sql performance
我是SQL的新手,关系而不是分层次地考虑我的数据集对我来说是一个很大的转变.我希望能够对性能(包括存储空间和处理速度)以及使用数字行ID作为主键而不是更有意义的字符串值的设计复杂性有所了解.
具体来说,这是我的情况.我有一个表("父")有几百行,其中一列是字符串标识符(10-20个字符),这似乎是表的主键的自然选择.我有一个第二个表("child"),其中包含数十万(或可能数百或更多)行,其中每一行引用父表中的一行(因此我可以在子表上创建外键约束).(实际上,我有两个类型的表,其中包含一组复杂的引用,但我认为这可以解决这个问题.)
所以我需要子表中的一个列,它为父表中的行提供标识符.天真地,似乎创建列像VARCHAR(20)这样的东西来引用第一个表中的"自然"标识符会导致在存储空间和查询时间方面的巨大性能损失,因此我应该包括父表中的数字(可能是auto_increment)id列,并将其用作子项中的引用.但是,由于我加载到MySQL中的数据还没有这样的数字ID,这意味着增加了我的代码的复杂性和更多的错误机会.更糟糕的是,由于我正在进行探索性数据分析,我可能想要查看父表中的值而不对子表执行任何操作,因此我必须小心不要意外地破坏关系删除行并丢失我的数字ID(我可能通过将id存储在第三个表或类似的东西来解决这个问题.)
所以我的问题是,是否存在我可能没有意识到的优化,这意味着一个包含数十万或数百万行的列,一遍又一遍地重复几百个字符串值比它首次出现的浪费少？我不介意效率的适度折衷,有利于简单,因为这是用于数据分析而不是生产,但我担心我会把自己编码到一个角落,我想要做的每件事都花费了大量的时间跑步.
提前致谢.
我不会主要关注空间方面的考虑.整数键通常占用四个字节.varchar将占用1到21个字节,具体取决于字符串的长度.因此,如果大多数只是几个字符,则varchar(20)键将占用比整数键更多的空间.但不是非常多.
顺便说一句,两者都可以利用索引.因此,访问速度并没有特别的不同(当然,较长/可变长度的密钥会对索引性能产生边际影响).
使用自动递增的主键有更好的理由.
您确实需要为记录中的四个字节支付额外的功能,这些记录专用于可能看起来不太有用的内容.然而,这样的效率还为时过早,可能不值得付出努力.