一、表设计
1.采用ER模型，首先遵循范式设计，再根据实际需要进行反规范化设计。
2.库名、表名、字段名必须使用小写字母，“_”分割(TICKET库除外)。
3.库名、表名、字段名不能太长，要见名知意,建议使用名词而不是动词，避免使用系统关键字。
4.表和字段要有注释，说明其含义，对于冗余字段还要特别说明其维护方法，外键字段说明参照与哪个表。
5.建议使用InnoDB存储引擎。
6.尽量保持表行长度较小。一个表中的所有字段长度，不应超过一个数据块(16K)的一半。
7.主键尽量选择AUTO_INCREMENT列，特殊情形可以使用含有实际语义的列。【FAQ】
8.保持字段名和数据类型的一致性，例如member_id就不要使用varchar()。
9.大表要有明确的数据保留策略。
10.存储精确浮点数必须使用DECIMAL替代FLOAT和DOUBLE。
11.建议使用UNSIGNED存储非负数值。
12.建议使用INT UNSIGNED存储IPV4。【FAQ】
13.整形定义中不添加长度，比如使用INT，而不是INT(4)。【FAQ】
14.使用短数据类型，比如取值范围为0-80时，使用TINYINT UNSIGNED。
15.不建议使用ENUM类型，使用TINYINT来代替。
16.尽可能不使用TEXT、BLOB类型。varchar的性能会比text高很多，实在避免不了blob，请拆表。
17.字符个数固定并且较小时建议使用CHAR()，比如MD5、身份证号、性别等。
18.VARCHAR(N)，N表示的是字符数不是字节数，比如VARCHAR(255)，可以最大可存储255个汉字，需要根据实际的宽度来选择N。
19.VARCHAR(N)，N尽可能小，因为MySQL一个表中所有的VARCHAR字段最大长度是65535个字节，进行排序和创建临时表一类的内存操作时，会使用N的长度申请内存。
20.表字符集选择UTF8。
21.使用VARBINARY存储大小写敏感的变长字符串或二进制内容。
22.存储年使用YEAR类型，存储日期使用DATE类型。
23.存储时间（精确到秒）建议使用TIMESTAMP类型，因为TIMESTAMP使用4字节，DATETIME使用8个字节。使用TIMESTAMP时注意update问题。【FAQ】
24.字段尽量定义为NOT NULL。避免使用NULL字段，NULL字段很难查询优化，NULL字段的索引需要额外空间，NULL字段的复合索引无效。
25.将过大字段、访问频率低的字段拆分到单独的表中存储，分离冷热数据。
26.禁止在数据库中使用VARBINARY、BLOB存储图片、文件等。
27.临时库、表名必须以tmp为前缀，日期为后缀。
28.禁止使用分区表。
29.备份库、备份表必须以bak为前缀，日期为后缀。
30.禁止在数据库中存储明文密码，把密码加密后存储。
二、散表
1.对于字段类型简单，字段数不多表，单表数据量建议控制在5000w以下。
2.可以结合使用hash、range、lookup table进行散表。
3.如按日期时间分表需符合YYYY[MM][DD][HH]格式，例如2013071601。年份必须用4位数字表示。例如按日散表user_20110209、 按月散表user_201102。
三、索引规范
1.非唯一索引必须按照“idx_字段名称_字段名称[_字段名]”进行命名，字段名称过长可以使用缩写。
2.唯一索引必须按照“uniq_字段名称_字段名称[_字段名]”进行命名，字段名称过长可以使用缩写。
3.索引名称必须使用小写。
4.索引中的字段数建议不超过3个。
5.单张表的索引数量控制在5个以内。
6.唯一键由3个以下的字段组成。字段是整形时，根据表设计规范，考虑使用唯一键作为主键。
7.唯一键不和主键重复。
8.索引字段的顺序需要考虑字段值的基数，基数大的放在前面。
9.禁止冗余和重复索引。
10.不建议使用外键。
(1) 外键用来保护参照完整性，可在业务端实现
(2) 对父表和子表的操作会相互影响，降低可用性
11.联表查询时，JOIN列的数据类型必须相同，并且要建立索引。
(1) 区分度最大的字段放在前面
(2) 核?SQL优先考虑覆盖索引
(3) 避免冗余和重复索引
(4) 索引要综合评估数据密度和分布以及考虑查询和更新比例
12.不在低基数列上建立索引，例如性别、status、type。
13.ORDER BY，GROUP BY，DISTINCT的字段必须被索引。
14.使用EXPLAIN判断SQL语句是否合理使用索引，尽量避免extra列出现：Using File Sort，Using Temporary。
15.UPDATE、DELETE语句需要根据WHERE条件添加索引。更新频繁的列不适合创建索引。
16.对长度过长的VARCHAR字段建立索引时，添加crc32或者MD5 Hash字段，对Hash字段建立索引。
17.普通长度的字符串依情形使用前缀索引。
18.合理创建联合索引（避免冗余），(a,b,c) 相当于 (a) 、(a,b) 、(a,b,c)。范围查询中高基数值的列在前。如果可以避免回表(在索引中即可完成检测)也可酌情添加联合索引。
19.合理利用覆盖索引。
20.不在索引列进行数据运算或函数运算（会导致无法使用索引，或者全表扫描）。
21.SQL变更需要确认索引是否需要变更并通知DBA。
22.SQL下线时通知DBA下线相关索引。
23.表必须有主键。
(1)不使用更新频繁的列作为主键
(2)尽量不选择字符串列作为主键
(3)不使用UUID MD5 HASH这些作为主键(数值太离散了)
(4)默认使?非空的唯一键作为主键
(5)建议使用自增
24.重要的SQL必须被索引，比如：
(1) UPDATE、DELETE语句的WHERE条件列
(2) ORDER BY、GROUP BY、DISTINCT的字段
四、SQL规范
1.使用prepared statement，可以提供性能并且避免SQL注入。
2.SQL语句中IN包含的值不应过多。连续的数值使用between and代替IN。
3.UPDATE、DELETE语句尽量不用LIMIT。
4.WHERE条件中必须使用合适的类型，避免MySQL进行隐式类型转化。数值类型禁止加引号；字符串类型必须加引号。
5.SELECT语句只获取需要的字段。SELECT、INSERT语句必须显式的指明字段名称，不使用SELECT *，不使用INSERT INTO table()。
6.使用SELECT column_name1, column_name2 FROM table WHERE [condition]而不是SELECT column_name1 FROM table WHERE [condition]和SELECT column_name2 FROM table WHERE [condition]。
7.避免在SQL语句进行数学运算或者函数运算（MySQL不擅长数学运算和逻辑判断）。
8.INSERT语句使用batch提交（INSERT INTO table VALUES(),(),()……），values的个数不应过多。
9.避免使用存储过程、触发器、函数、定时器等，容易将业务逻辑和DB耦合在一起，并且MySQL的存储过程、触发器、函数中存在一定的bug。
10.避免使用大表的JOIN和子查询。
11.使用合理的SQL语句减少与数据库的交互次数。
12.不使用ORDER BY RAND()，使用其他方法替换。
13.建议使用合理的分页方式以提高分页的效率，比如改写limit：
select id from tlimit 10000, 10; => select id from t where id > 10000 limit10;
14.统计表中记录数时使用COUNT(*)，而不是COUNT(primary_key)和COUNT(1)。
15.NULL值不可以直接和比较运算符比较，应使用is null和is not null。
16.不建议使用%前缀模糊查询，例如LIKE “%weibo”，会导致全表扫描（可使用覆盖索引技术解决）。
17.避免不必要的排序，酌情将排序交给应用层去完成。
18.避免SQL提示（USE INDEX,FORCE INDEX等）在代码中出现。
19.用到并行度需谨慎。高并发的SQL语句需要提交给DBA做压测。
20.查询datetime类型的列，不需要使用DATE_FORMAT或STR_TO_DATE()函数。
21.拆分复杂SQL为多个小SQL，避免大事务，整个事务的时间长度不要太长。
22.避免使用OR条件，可以改写为IN。
23.SQL中避免出现now()、rand()、sysdate()、current_user()等不确定结果的函数。
24.避免单条SQL语句同时更新多个表。
25.禁止在从库上执行后台管理和统计类功能的QUERY，可以使用统计类从库。
26.禁止使用负向查询，例如 not in、!=、not like。
27.降低业务耦合度，为sacle out、sharding留有余地。
28.UNION ALL比UNION性能更好。
五、行为规范
1.表结构变更必须通知DBA进行审核。
2.禁止在线上做数据库压力测试，禁止从测试环境直连数据库。
3.禁止有super权限的应用程序账号存在。
4.禁止有DDL、DCL权限的应用程序账号存在。
5.重要项目的数据库方案选型和设计必须提前通知DBA参与。
6.批量导入、导出数据，大批量更新数据如UPDATE、DELETE操作，必须DBA进行审核，并在执行过程中观察服务。
7.产品出现因数据库导致的故障时，如被攻击，必须及时通知DBA，便于维护服务稳定。
8.业务部门程序出现BUG等影响数据库服务的问题，必须及时通知DBA，便于维护服务稳定。
9.业务部门推广活动或上线新功能，必须提前通知DBA进行服务和访问量评估，并留出必要时间以便DBA完成扩容。
10.出现业务部门人为误操作导致数据丢失，需要恢复数据的，必须第一时间通DBA，并提供准确时间地点、误操作语句等重要线索。
11.提交线上建表改表需求，必须详细注明涉及到的所有SQL语句（包括INSERT、DELETE、UPDATE），便于DBA进行审核和优化。
12.不要在MySQL数据库中存放业务逻辑。
六、FAQ
一、表设计
1.要尽量选择AUTO_INCREMENT类型。含有实际语义的列仅适用于读多写少并且读写量悬殊的场景，例如使用member_id做主键。
2.IP地址可以考虑通过使用int unsigned来保存，使用MySQL函数inet_ntoa和inet_aton来进行转化。
3.数值类型括号后面的数字只是表示宽度而跟存储范围没有关系。
4.多列TIMESTAMP，应注意update问题。尤其是为TIMESTAMP列而不是第1列指定自动默认或更新，必须通过将第1个TIMESTAMP列显式分配一个常量DEFAULT值来禁用自动初始化和更新。
http://dev.mysql.com/doc/refman/5.1/zh/column-types.html#timestamp-4-1
七、参考资料
1.mysql系统关键字
http://dev.mysql.com/doc/refman/5.5/en/reserved-words.html
2.mysql开发规范
http://www.iamcjd.com/?p=1237#MySQL-1-3
3.部分数据类型的存储范围
