最近看到一个朋友说自己公司使用的表结构为多对多的关系，现在他们的customer已经860万了，而中间表m_customer_category 也有900多万了，如果按类型查找客户资料的话巨慢，就是customer，m_customer_category,custoemr_category三张表多对多关系，现在使用客户类型快速查找非常慢。
然后自己也想了想这种设计，感觉查询确实非常郁闷，而且想不出它到底有什么优势。
希望大家一起来讨论讨论。
首先Customer与Order不是一对多的关系吗?一个客户可以有多个订单,一个订单只能属于一个客户,如果像我说的,首先表的设计就有问题
不过如果你真要这么设计的话...
首先考虑客户类型和订单状态字段是否有做索引的需要,
select t3.* from(
select * from Customer where customer_type=80
) t1 inner join Customer_Order t2 on t1.customer_id=t2.customer_id
inner join (
select * from Order where order_state='已经到帐'
) t3 on t2.order_id=t3.order_id
无论多对多还是什么多，都必须在两个主表里存储冗余数据，中间表崩溃的可能性非常大，如果中间表损坏，那么你的数据是不是都成了孤岛，尽管中间表使用联合主键来查询速度也不会说很慢，但是如果主表里有冗余数据岂不是根本不用连表，中间表的作用不过就是存储原始数据而已，可作为冗余更新的凭证
个人感觉，Customer_Order这个没啥用，直接用Customer,Order关联不就可以了吗
Customer,Order关联 只需要1对多就可以了，多对多的情况是有的，不过感觉不适用你的需求。
以前公司都不用哪种关联，现在公司都用。我也给问了他们为什么要用，大家说不出所以然来，反正一直都在用，等待答案。
中间表就是用来存放关联关系的，尤其是多对多得时候，如果你只用Customer和Order两张表来存多对多，肯定是可以得，但是，在Customer表里就会有那么几条记录，绝大部分内容都一样，唯独OrderID不一样。这个好像挺浪费空间的。
1.首先要确定的customer与custoemr_category是不是多对多的关系,如果是的话,建议这么做,因为这么做可以尽量的满足范式,至于范式的作用你可以自己去查,当然范式也不是死的,有的时候为了业务的需要也会做一些反范式的设计的,但是一般来说还是尽量按范式来设计.
2.还有就是对于大数据量的优化问题了,索引,分区,数据水平切分等技术,
3.还有就是维护的问题,如果你觉得麻烦可以考虑用级联操作