我是一个拥有200多名用户的成长型公司的四人团队的一员.是时候对我们的专有软件进行大规模重构了,我们非常高兴能够构建一个理想的系统,我们知道它可以承受至少5年以上的增长.然而,我们正在使用关系数据库,虽然我们正在制作一些相当不错的设计,但我有一种迫在眉睫的感觉,即此产品可能会比我们希望未来更慢.
我担心的是我们对外键关系的使用.它们非常适合数据完整性,这就是我们与它们合作的原因.如果我们想要更改某人的用户名,则会在所有相关位置更改它.那很棒.问题是,我们不是 - 我们通过他们的ID相关联,因此唯一的主要好处是获得关系密钥索引所获得的性能.
所有这些指数堆积如山,给我一个红旗.我们有一些表只是链接表,有三个关系键.他们肯定有自己的位置,我们非常有信心减少我们将要进行的查询.但是,我接着想 - 我们有10,000行,其中10,000行,另一行10,000,我们想添加一行.巴姆!新指数*4.
这令人担忧.我们会陷入任何陷阱,经验丰富的个人提出的建议是什么？
我开始对MySQL的内存使用感兴趣.所以我在这看着这个:
http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html
我很高兴看到节省内存的前景(例如)只需要一个签名的smallint,我在许多地方使用unsigned int.然后我读到了varchars ......
"VARCHAR(M) - 如果列值需要0 - 255字节,则长度+ 1个字节"
什么？!现在在我看来,好像存储一个varchar会消耗这么多内存,我甚至不会对我的int与smallint感到兴奋,因为它被varchar字段大大黯然失色.所以我来这里询问这是否属实,因为它根本不可能？varchars真的那么可怕吗？或者我真的不会因为我的小发现而感到兴奋吗？
编辑:对不起!我应该更清楚.所以,假设我存储了一个包含7个字符的varchar,意思是8个字节.那意味着它使用与存储在BIGINT列中的数字相同的数字？这就是我所关心的.
mysql varchar database-design memory-management mysql-management