昨天面對某客戶域做表關聯的時候發現了。
有兩張相同內容的主表。但是表的設計結構並不相同：
（每個領域都有主表，每次往這個領域（庫）添加新表的時候一般都會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。