但是例外就是char和varchar如果在定义表的时候，长度一致，就可以利用索引JOIN，反正不行。例如，char(20)和varchar(20)可以利用索引，char(20)和varchar(25)则不行，不管varchar里面实际存储的值是多长。
4.18 如果两个字段列的字符集不同，不推荐JOIN字符集不同的列，索引失效，容易引起慢查询故障。
V 完整性设计规范采用数据库系统实现数据的完整性，这不但包括通过标准化实现的完整性而且还包括数据的功能性。
5.1 主键约束每个表要求有主健，主健字段或组合字段必须满足非空属性和唯一性要求。
5.2 NULL值（1）由于NULL值在参加任何运算时，结果均为NULL，所以尽可能把字段定义为NOT NULL。对于所有声明为NOT NULL的字段，必须显式指定默认值。
（2）不要使用count(列名)或者count(常量)来替代 count(*)，count(*)是SQL92定义的标准统计行数的语法，跟数据库无关，跟null和非null无关。
说明：count(*)会统计值为null的行，而count(列名)不会统计此列为null的行。
（3）count(distinct col)计算该列除null之外不重复的行数
注意：count(distinct col1, col2)，如果其中一列全为null，那么即使另一列有不同的值，也返回0。
（4）当某一列的值全为null，count(col)的返回结果为0，但sum(col)的返回结果为null，因此使用sum()时需要注意NPE问题。
例如，可以使用ISNULL()来判断是否为NULL值，来避免sum的NPE问题：
SELECT IF(ISNULL(SUM(g)), 0, SUM(g)) FROM table;
（5）NULL与任何值的直接比较都为null。
NULL<>NULL的返回结果是NULL，而不是false。
NULL=NULL的返回结果是NULL，而不是true。
NULL<>1的返回结果是NULL，而不是true。
5.3 视图使用原则为了在应用程序和数据库之间提供一层抽象，可以为应用程序建立视图而不必直接访问表。使用试图可以简化操作，不用关注表结构的定义，可以把经常使用的数据集合定义成视图；屏蔽了表结构变化对用户的影响， 表增加列对视图没有影响，具有一定的独立性。此外，用户对视图不可以随意的更改和删除，可以保证数据的安全性。视图是虚拟的数据库表，在使用时要遵循以下原则：
A. 尽可能减少使用视图。
B. 视图中如果嵌套使用视图，级数不要超过3级。
C. 由于视图中只能固定条件或没有条件，所以对于数据量较大或随时间的推移逐渐增多的表，不宜使用视图。
D. 除特殊需要，避免类似SELECT * FROM [Table Name] 而没有检索条件的视图
E. 视图中尽量避免出现数据排序的SQL语句。
VI 安全性设计规范 6.1 数据库账号使用规范严格管理程序的专用账号，禁止用户使用此账号进行数据操作。 请使用开发人员专用只读账号进行数据查询。
6.2 用户与权限为不同用户设定允许的权限，管理和使用权限分离。确定每个用户对数据库表的操作权限，如查询、新增、更新等。每个用户拥有刚好能够完成任务的权限。
严格把控好管理权限，只将管理权限赋予管理员。禁止有super权限的应用程序账号存在。禁止有DDL、DCL权限的应用程序账号存在。
6.3 用户密码管理用户帐号的密码必须进行加密处理，确保在任何地方查询都不会出现密码的明文。
VII 开发行为规范 7.1 总则（1） 业务部门推广活动或上线新功能，必须提前通知DBA，并留出必要时间以便DBA完成压力评估和扩容 ；
（2） 单表多次alter操作必须合并一次操作；
例如：
要给表t增加一个字段aa,同时给已有的字段bb建立索引，通常的做法分为两步:
alter table t add column aa varchar(10);
然后增加索引:
alter table t add index idx_bb(bb);
正确的做法是:
alter table t add column aa varchar(10),add index idx_bb(bb);
（3） 怀疑有性能瓶颈的SQL及早提交DBA调优，避免上线出现性能问题；
（4） 批量更新数据，必须通知DBA进行审核，并在执行过程中观察服务及主从延迟；
（5） 重要业务库的变更，须告知DBA重要等级、是否数据备份和执行时间要求；
（6） 避免在业务高峰期批量更新、查询数据库；
（7） 提交线上建表改表需求，必须详细注明涉及到的所有SQL语句，便于DBA进行审核和优化；
（8） 所有DDL和DML语句必须要在运维平台上提交申请，禁止口头或通过聊天工具传送需求；