这是一个创建于 2800 天前的主题，其中的信息可能已经有所发展或是发生改变。
题主在上学读书期间学习数据库课程时，涉及到多对多关联的表结构设计都是采用标准化的解决方式，即增加一张关联表用以保存两个实体之间的联系（例如经典的 student / course / student_course_mapping 这样三张表）
然而在实际工作中，发现系统的业务逻辑较为复杂时（实体之间多对多关系的场景比较普遍），数据库中会充斥很多这样的关联表，然后为了实现页面上某个较为复杂的查询操作，往往需要 join 多张表才能满足需求，以学生 /课程的场景为例，为了查询某个班所有学生所选修的课程的详细信息，就至少需要 join 上述三张表，如果页面上需要查询的条件更多，那么还要再 join 更多的表才能满足一次查询要求，这样显然会大大增加 SQL 语句的执行时间，不知道大家在工作中遇到这样的情况，都有什么好的实践方案么？
题主之前也使用过空间换时间的方案，也即把这样多对多的关系拆分成两个一对多的关系，不知道是否存在更优的解决方案？
PS ：顺带请教另一个问题，一个页面中如果存在着非常复杂的查询条件，例如需要模糊查询某个人的名字、某个地点，以及其他一些精确检索条件，对于多个模糊搜索（诸如 like '%XXX%'）条件如果做优化才能最大程度的保证 SQL 执行性能？
然而在实际工作中，发现系统的业务逻辑较为复杂时（实体之间多对多关系的场景比较普遍），数据库中会充斥很多这样的关联表，然后为了实现页面上某个较为复杂的查询操作，往往需要 join 多张表才能满足需求，以学生 /课程的场景为例，为了查询某个班所有学生所选修的课程的详细信息，就至少需要 join 上述三张表，如果页面上需要查询的条件更多，那么还要再 join 更多的表才能满足一次查询要求，这样显然会大大增加 SQL 语句的执行时间，不知道大家在工作中遇到这样的情况，都有什么好的实践方案么？
题主之前也使用过空间换时间的方案，也即把这样多对多的关系拆分成两个一对多的关系，不知道是否存在更优的解决方案？
PS ：顺带请教另一个问题，一个页面中如果存在着非常复杂的查询条件，例如需要模糊查询某个人的名字、某个地点，以及其他一些精确检索条件，对于多个模糊搜索（诸如 like '%XXX%'）条件如果做优化才能最大程度的保证 SQL 执行性能？
 |
1
buliugu 2017-03-30 15:56:55 +08:00
异常复杂的搜索条件就上 solr 吧，或者 es
|
 |
2
jimzhong 2017-03-30 16:24:22 +08:00
模糊搜索似乎不是 SQL 的强项。
我也很好奇多个表 Join 怎么优化。 |
 |
3
awanabe 2017-03-30 16:29:22 +08:00
可以在 mapping 表冗余 a,b 表的数据。
如果 a ， b 表更新不多的话， 可以把 a ， b 数据存入缓存（ redis ）中。 到时候只要去对应关系+缓存即可，单表查询会很快。 join 优化，就是在执行的时候， 尽可能不要出现大表 x 大表的全表扫描情况。。这样笛卡尔乘积爆炸。 |
 |
4
Sharuru 2017-03-30 16:31:46 +08:00
比起性能更注重关系。
通过 ER 图直接生成对应实体 Entity ，使用 ORM 的方法去 get 想要的数据。 至于性能？堆硬件。 |
Select Language