昨天面对某客户域做表关联的时候发现了。
有两张相同内容的主表。但是表的设计结构并不相同：
（每个领域都有主表，每次往这个领域（库）添加新表的时候一般都会join 主表，从而有唯一的主键id）
这两个表提供了这个领域的主键（id）.
在这个
+------------+------------+----------+--+
| col_name | data_type | comment |
+------------+------------+----------+--+
| id | int | |
| name | string | |
| phone | string | |
| gender | string | |
| cardno | string | |
| age | string | |
| school | string | |
| quora | int | |
..
...
..
目测有60个字段这是一张宽表.
+------------+------------+----------+--+
+------------+------------+----------+--+
| col_name | data_type | comment |
+------------+------------+----------+--+
| id | int | |
| value1 | string | |
| type1 | string | |
| value2 | string | |
| type2 | string | |
| age | string | |
| school | string | |
| quora | int | |
目测有不到10个字段
+------------+------------+----------+--+
这是一张窄表
select type1,type2 from thistable group by type1,typ2;
发现类型数据有14种类左右
这样就相当于把第一个宽表的数据（可能剔除了不重要的字段）然后完全放开，行数暴增。
==============================================================================
我讲一下怎么用设计性能原理还要留给大家去分析：
每次都要从其他表抽取数据关联这个表id(唯一主键)，比如这个第三方表名字叫第三方客户信息 没有id这列（毕竟id列是我们在自己的系统自己生成的），
只有用户名和手机号+（第三方提供的字段（比如一周洗几次澡）），我们用name+ phone去作为join on的条件关联主表窄表，得到新的有主键的表。
select id ,max(a.字段) from 第三方表 a
join
(select id,value1 as phone,value2 as name from 主表窄表 where type1=‘MOBILE_PHONE’ and type2='NAME' group by id,value1,value2) b
on a.phone=b.phone and a.name=b.name
group by id.
note:上面的group by 的作用主要是为了去重。
但是为什么这样设计？这又是对内存和计算效率（时间）之间的权衡
应该是减少对内存的需求。因为join关联必定要生成一个中间表。如果是宽表内存太大，但是窄表牺牲了关联效率。毕竟行数倍增原来十多倍。关于join的原理请看我另一份博客。
年前和项目老大聊了一会。他设计这个报表。感觉大佬的想法很nice。