我在数据库中有一个规范化的表 - 比如说
(ID, name, age)
这里，每个条目对应一个人，ID是该表的关键。
非关键字段经常访问 - 通过名称字段搜索此表通常足以完成一件事。
因此，我可以在名称字段上放置一个索引，因此，该表也会在此字段上编入索引。
首席技术官表示，这张表将分为N个表格 - 每个表格一个 非关键字段（在这种情况下N = 2）：
(ID, name)
(ID, age)
他建议这可以快速访问查询。当像这样分解时，这两个表中的每一个 将ID作为密钥仍然存在，并且表不会在其他字段上编制索引。
我认为，这并不能提供快速访问 - 甚至会降低速度：
没有索引意味着在查询上再次搜索整个表
附加表格访问权限以获取原始表格的整行（姓名和年龄） 而不是在找到匹配的行时在相应的行上同时获取它们。
这里缺少什么？
TIA
答案 0 :(得分：0)
您的推理绝对正确，建议的解决方案不会带来任何好处，甚至会使您描述的方式更加严重。
将索引添加到经常搜索的字段会产生更好的结果，但根据搜索方法，实现的好处可能会受到限制。例如，搜索部分匹配（name LIKE '%whatever%'）可能无法有效使用索引。
根据您使用的数据库，我可能会采用其他技术来加快速度，例如：内存缓存，全文索引等。
答案 1 :(得分：0)
简短的回答是，它会降低整体性能并且设计糟糕。除此之外，您应该维护外键约束，以便在不需要删除（ID，年龄）的情况下（如果需要）（ID，名称）将无法删除。这些FK约束将增加它们自己的开销。或者，您可以选择不实施FK，但随后打开数据集以获得不匹配的记录。使用不能为您编写函数的常用ORM工具可以实现此方案。另一方面，通过功能，您可以使用事务并确保一起通过或失败。写作甚至都是如此。如果，例如玛丽史密斯结婚，她的名字改为玛丽怀特，该怎么办？最重要的是，我们需要改变她的年龄。现在使用所提出的设计，谨慎的做法是确保在一个数据库事务中更新两个表，这会增加更多的复杂性
然后是MySQL维护问题。添加超出设计需要的表格也会妨碍维护工作，并增加MySQL自身索引维护开销的负担。
因此，除了降低数据库性能之外，由于增加了无用的复杂性，它还会降低开发人员的工作效率。
如果性能真的是这样一个问题，而你的数据集确实那么大，并且你真的需要快速的文本查找等，那么更好和广泛使用的技术就是使用像Sphinx这样的东西。
老实说，听起来他可能已经阅读了有关分片的内容，并完全误解了他正在阅读的内容。