1:表当中的id字段在创建表的时候可以选择int not null auto_increment,但是可以不设置为主键，
例子：合伙人公司地址
例子说明：多数情况下是通过partner_comany_id字段来获取相应的合伙人地址信息，主键若设置为partner_company_id对于实际的应用场景会有比较大的性能提升，但是partner_company_id不具有唯一性，在实际情况当中可以将district_id或者province_id,city_id,district_id作为组合主键。
结论：主键并不等于int not null auto_increment,主键可以用在提升查询效率的相应字段
2：对于同一个属性有多个值的情况可以创建从属表，用于单独存储多个值的属性
例子：合伙人公司地址
例子说明：该表的情况是每一个district_id都会占据一行记录，对于同一个city来说可能会有好几个distrct_id,这几行记录会有冗余的公司id，省份id等信息；
可以提取出与district有关的信息列，建立一个从属表，从属表当中增加字段指向父表当中关于城市信息的字段
结论：对于多值属性，若是值的数量比较多或者数量不确定，可以使用从属表，有利于扩展和减少冗余信息；若值的数量比较少或者比较固定可以不采取，毕竟分表对于sql有些情况的查询，涉及的表数量会多一个表；
3：项目当中有些联表查询使用select p.name,k.name2 from p,k where k.id=p.id;
例子：上面的写法利用的是利用的是笛卡尔积,然后通过where条件对数据进行过滤 效率比较低
结论：对于联表查询很多情况可以利用左外连接，右外连接或者全连接，来避免出现笛卡尔积的情况；例如上面的情况可以使用全连接select p.name k.name2 from p join k on k.id=p.id;
4：对于属性的值属于一个枚举范围情况
例子：Shop
例子说明:目前的涉及主要是靠服务端程序来对输入进行名称与数值的转化，还有就是通过注解约定数值和名称的对应关系('店铺类型；1：到店，2：到店&配送，3：服务类, 4:外卖为主'
)；
不足：
1，数据库缺少约束，本身不能避免插入范围之外的数值，比如shop表的相应type列插入5
优化建议：
1：在数据库本身增加约束；主要有两种方式，a：将相应列改为type int check (type in(1,2,3,4))
b,type enum('1','2','3','4')
前者增加约束检查，后者将值控制在枚举范围之内；,当然这两种方法在增加和删除枚举属性个数的时候会有一点麻烦，但是都可以克服
2：根据枚举数值建立一张新表；其中shop的相应type列改为外键指向改新表
结论：数据库本身对于枚举值应该加以约束，防止程序的不正确操作；如果不想根据枚举建立新表，也可以通过第一条建议的两种方案加强数据库本身的防错功能。
5：对于将照片数据，数据库里面只存储图片链接
缺点：不能使用数据库本身的关于事物的支持，并发删除或者更新会导致一些bug；删除数据库相应的行时候，不能自动删除相应的图片，长时间可能导致存放图片数据的地方积压很多用不上的图片数据；图片数据的获取不能利用数据库的权限；不能利用数据库的备份功能；
优点：好处也很多
结论：缺点可以忽略，或者优点更有利于开发的话 也可以只存储链接；
6：索引随着插入删除的频繁交替，可能平衡状态会不佳，这个时候可以通过optimize table或者analyze table来重建索引
7：一条精心设计的复杂SQL查询，相比于那些简单的查询来说，不得不使用很多的jion，关联子查询，和其他让SQL引擎难以优化和快速执行的操作符。程序员直觉地认为越少SQL执行次数性能越好，如果SQL查询的复杂度都相同时的确如此，但是另一方面，一个怪兽般的SQL查询的开销可能成为指数级别增长，而使用多个简单的查询却有更好的效果。
8：