我目前有一个数据库，有很多很多关联。我有许多变化的服务，有许多工作人员谁可以执行的变化，然后有他们自己的细节如名称，角色等...许多协会导致查询缓慢
在10服务3变化各20人中最多4附加到每个服务甚至做一些事情，因为获得所有变化和与他们相关的工作人员需要4s。
有没有办法减少这些需要一段时间才能处理的查询？我通过在DBM中进行急切的加载来减少查询，以减少1 + N问题带来的问题，但仍然只是一个测试阶段的长时间查询。
是否有一个结构可以帮助使这种嵌套的多对多关联更快地选择？
也许将过去服务级别的所有内容合并到一个带'TYPE'列的单个表中？我只是不知道足够的知道解决方案，将这个4S查询变成300MS查询...任何建议都会有所帮助。
表格模式将很高兴看到这个问题。就一般的MySQL性能而言，确保您研究磁盘对齐，设置适当的块大小，并针对此特定问题检查执行计划并评估添加索引。
答：可能重构数据以提高查询效率。这通常意味着冗余（重复值）的折衷，这会使插入/更新/删除算法过于复杂。
没有看到架构以及正在运行的查询（查询？），无法诊断问题。
我认为最可能的解释是，MySQL没有合适的索引可用来有效地满足正在运行的查询（查询？）。运行EXPLAIN query对于显示访问路径非常有用，并提供合适的索引是否可用，是否正在考虑索引，是否统计数据是最新的等等。
但是，您还提到了“N + 1“的性能问题和”急切加载“，这使我相信你可能会使用ORM（比如ADO Entity Framework，Hibernate等）。这些是性能问题的臭名昭着的来源，发布大量SQL语句（N + 1），或者做一个单独的查询，它连接了几条不同的路径，这些查询产生了一个庞大的结果集，查询本质上是在进行半交叉连接。
为了真正诊断性能问题，您确实需要发布实际的SQL语句，并且在开发环境中，启用MySQL通用日志将捕获正在发布的SQL以及基本时序。
我建议你添加你当前正在使用的数据库表模式。 – Sparky
请添加您的数据库架构，一些示例数据和您正在使用的查询。制作一个小平台也是有帮助的。 – Barmar