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