如果操作（查询）涉及的表数量增加，是否会影响性能？
对数据库执行的操作数量会降低性能。但是任何查询中涉及的表数量（例如表的连接）会降低性能？
The number of operations performed on database degrade the performance.But the number of tables involved in any query (for example joining of tables) reduce the performance ??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
未必。性能由索引、内部存储结构和查询计划等因素决定。性能和查询涉及的表数量之间没有直接关联。
Not necessarily. Performance is determined by indexes, internal storage structures and query plans among other things. There is no direct correlation between performance and the number of tables involved in a query.
根据经验，数据库操作中涉及的表的数量并不能说明该操作的性能。考虑在多个表上进行主键查找与完全扫描一张大表。
根据经验，向特定数据库操作添加附加表通常会导致可测量的性能下降。通过可衡量，我的意思是数据库将为您提供一个数字来描述两个查询的性能，而第二个查询的数字会更差。如果差异明显，那就是另一个问题了。再次考虑在连接中添加 10 个主键查找，而不是添加一个 90 亿行的表来进行全面扫描。
作为经验法则，不要相信经验法则。例如，如果附加表是内连接且为空，或者包含少量行，或者启用更有效的访问路径（小表的笛卡尔连接以便能够在大表上使用索引），则上述规则是错误的，或……或……或……
As a rule of thumb, the nr of tables involved in a database operation says nothing about the performance of that operation. Think primary key lookups on several tables vs full scanning one big table.
As a rule of thumb, adding an additional table to a specific database operation will in general result in a measurable performance degradation. By measurable, I mean that the database will provide you with a number to describe the performance of both queries and the number for the second query will be worse. If the difference is noticable at all, is another question. Again, think adding 10 more primary key lookups to a join, versus adding one more 9 billion row table to fully scan.
As a rule of thumb, don't trust rules of thumbs. For example, the above rules are wrong if the additional table is inner joined and empty, or contains a small nr of rows, or enables a more efficient access path (cartesian joins of small tables to be able to use index on big table), or ... or .... or..