建完表先看一眼，PRIMARY 那一行已经在了。
课件第 9 页说主码上应该建唯一索引，DBMS 建表时就替你建好了。
Non_unique 那一栏是 0，就是唯一索引，重复的主码进不来。
那还需要自己在主码上再建一个吗？
课件那条索引建在 supid 上，照敲一遍看看。
建得上，可是两行索引管同一列，后一个白占空间还拖慢写入。
课件那条索引建在主码列上，主码自带索引，这一条是多余的。
为什么 MySQL 不拦住这种重复的索引？
DROP INDEX 之后再看一眼，回到只剩主码那一行。
真要建就建在常查的列上，比如按供应商名称找。
字典前面只要一份目录，同一份印两遍，翻起来不会更快。
包含表按订单查明细，orderid 是外码也是最常用的查询条件。
联合主码只帮到 orderid，单查 commodityid 用不上，得自己补一个。
联合索引像电话簿，先按姓排再按名排，只知道名字是查不动的。
把两列的顺序调过来，结论会变吗？
地址表的性别只有男女两种，先算一算它能把数据分成几堆。
性别把四行只分成两堆，查一次还要扫一半，索引救不了。
多少行的表上，性别索引才可能有点用？
课件第 9 页说主码索引还能避免重复值录入，试一次。
两条都报 1062，一条是主码挡的，一条是刚加的唯一索引挡的。
| 索引 | 作用 |
|---|---|
| 普通 | 只管查得快 |
| 唯一 | 还管不重复 |
手机号加唯一约束，现实里合适吗？
课件第 8 页讲的聚集，在 MySQL 里主码已经替你做了。
PRIMARY 那一行就是聚簇索引，行按主码顺序排着存，找到码就找到行。
所以主码短一点划算，每个二级索引里都要再带一份主码。
主码用很长的字符串，代价在哪儿？
头一句先删干净，两张表建起来，索引挨个看一遍。
两张表最后各两个索引：主码那一个是白送的，另一个是自己想清楚才加的。
索引多一个，写入慢多少？