我目前有一个有很多多对多关联的数据库。我的服务有很多变化，有很多员工可以执行变化，然后他们有自己的详细信息，比如姓名、角色等......
在 10 项服务中，每项服务有 3 种变化，每项服务的 20 名员工中最多有 4 名员工甚至会做一些事情，例如获取所有变化，并且与他们相关的员工需要 4 秒。
有没有办法可以减少这些需要一段时间才能处理的查询？我已经通过在我的 DBM 中进行预加载来减少查询，以减少由 1+N 问题引起的问题，但是对于测试阶段来说，4s 仍然是一个很长的查询。
是否有一种结构可以帮助更快地选择这种嵌套的多对多关联？
也许将超过服务级别的所有内容组合到一个带有“TYPE”列的表中？？我只是没有足够的知识来了解将这个 4s 查询变成 300MS 查询的解决方案......任何建议都会有所帮助。
A:可以重组数据以提高查询效率。这通常意味着权衡冗余（重复值），这会使插入/更新/删除算法过于复杂。
如果没有看到架构和正在运行的查询（查询？），就不可能诊断出问题。
我认为最可能的解释是 MySQL 没有合适的索引来有效地满足正在运行的查询（查询？）。运行 anEXPLAIN query有助于显示访问路径，并了解是否有合适的索引可用、是否正在考虑索引、统计信息是否是最新的等。
但是您还提到了“N+1”性能问题和“急切加载”，这让我相信您可能正在使用 ORM（如 ADO 实体框架、Hibernate 等）。这些都是臭名昭著的性能问题来源，发出许多 SQL 语句 (N+1)，或者执行一个查询，该查询确实连接了几个不同的路径，这会产生一个巨大的结果集，其中查询本质上是一个半交叉连接。
要真正诊断性能问题，您确实需要发出实际的 SQL 语句，并且在开发环境中，启用 MySQL 常规日志将捕获发出的 SQL 以及基本时间。
很高兴看到这个问题的表模式。就一般 MySQL 性能而言，请确保您研究磁盘对齐，设置适当的块大小，并针对此特定问题检查您的执行计划并评估添加索引。