数据库相关
1.表达是否概念的字段，必须使用isxxx的方式命名，数据类型是unsigned tinyint(1表示是，0表示否)，如删除标记字段：is_deleted
2.请用表达清晰的字段意思来表示字段的意义。比如该字段就是表示是否删除的状态，亲不要使用意义不明显的status，而是使用is_deleted。具象 > 抽象
3.小数类型用decimal，禁止使用float和double。
4.varchar是可变字符串，不预选分配存储空间的话，长度不要超过5000个字符。如果超过则用text，独立一张表，用主键对应，避免影响到其他字段的索引效率。
5.每张表必备的三个字段：id（unsigned bigint）、gmt_create（datetime类型）、gme_modified（datetime类型）
6.字段允许适当冗余，以提高查询性能，但必须考虑数据一致性。冗余的字段必须不是频繁修改的字段，不是varhar超长字段(更不能是text字段)。
7.单表行数超过500万行或者单表容量超过2GB才推荐进行分库分表(如果预计三年都达不到这个数据量，不要在创建表的时候就分库分表!)
8.超过三个表禁止使用join，两张表也尽量不要使用join
9.在varchar字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，页面搜索严禁左模糊或者全模糊，如果需要则通过搜索引擎来解决。
充分利用好最左前缀匹配特性！
11.利用延迟关联或者子查询优化超多也分页场景。 pageIndex很大的分页问题
我们知道，当我们表里数据多，我们可以使用分页查询，但是当我们页数很多的时候，我们页码很大的情况下，效率也是会非常低的。
MySQL并不是跳过 offset行，而是取 offset+N行，然后返回放弃前offset行，返回N行，那当 offset特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行SQL改写。
按照这么建议，我们这样来优化我们的sql语句：
// 优化前 SELECT id, cu_id, name, info, biz_type , gmt_create, gmt_modified, start_time, end_time, market_type , back_leaf_category, item_status, picuture_url FROM relation WHERE biz_type = '0' AND end_time >= '2014-05-29' ORDER BY id ASC LIMIT 149420, 20; // 优化后 SELECT a.* FROM relation a, ( SELECT id FROM relation WHERE biz_type = '0' AND end_time >= '2014-05-29' ORDER BY id ASC LIMIT 149420, 20 ) b WHERE a.id = b.id
解释：其实这里就是通过使用覆盖索引查询返回需要的主键,再根据主键关联原表获得需要的数据。这样就是充分利用了索引！
12. 如果有全球化需要，均以utf-8编码。如果需要存储表情，选择utf8mb4进行存储。
未完，待续（日志规范、设计规范等等）
由于时间有限，今天重点就自己实施验证了上面一些例子，关于其它的，后续有空还会补充完整这篇博文的。
借用灰太狼一句名言：我一定会回来的
个人建议的编码规范
阿里手册已经涉及到的，此处不再提了。本处仅提出个人的一些建议，不喜勿喷
仅代表着我个人的意见，我觉得OK的地方。大家如果觉得好的话，可以帮顶，如果大家对我个人提出的规范有什么想法和建议，非常非常欢迎提出来或者指正，毕竟我个人的经验还不是很足，需要指点、优化。
1.约定大于配置，配置大于编码
2.能约定好的规范，就不要多写一个适配器去兼容
3.除非需要更高的可见性，否则应将所有的域都声明为私有域。
4.除非需要某个域是可变的，否则应将其声明为final域
