大表在查询性能和结构修改、备份、恢复等运维方面存在很多弊端。可以用历史数据归档，分库分表、选择其它类型数据库等手段来控制数据量大小。
（6）数据表分类说明
根据应用的实际需要和特点，可以将数据表进行如下分类：
A. 基本数据表：描述业务实体的基本信息。例如：人员基本信息、单位基本信息等。
B. 标准编码表：描述属性的列表值。例如：职称、民族、状态等。
C. 业务数据表：记录业务发生的过程和结果。例如：人员调动登记、变更通知单等。
D. 系统信息表：存放与系统操作、业务控制有关的参数。例如：用户信息、权限、用户配置信息等。
E. 统计数据表：存放业务数据统计值。例如：通知单统计、人员类别统计等。
F. 临时处理表：存放业务处理过程中的中间结果。
G. 其他类型表：存放应用层的日志、消息记录等。
3.2 字段设计原则（1）完善的字段说明
涉及数据字段新增、变更，必须提供字段说明，需要及时更新字段注释。
（2）选择符合存储需要的最小的数据类型
一般来说，应该使用能正确存储和表示数据的最小类型。如果不确定需要什么数据类型，则选择不会超出范围的最小类型。选择更简单的数据类型。例如，整数类型的比较其代价小于字符类型的比较，因为字符集和排序规则使字符比较更复杂。
（3）合理的字段默认值
字段尽可能有默认值，字符型的默认值为一个空字符串，数字型的默认为数值0。 尽可能把字段定义为NOT NULL。对于字段能否NULL，应该在SQL建表脚本中明确指明，不应使用缺省。
（4）所有布尔类型字段数据类型是unsigned tinyint，数值0表示为假；数值1表示为真（根据表的字段意义：比如Disabled = 1表示 Disabled 值为真，可以表示数据被逻辑删除）
（5）避免使用 ENUM 类型
ENUM 类型的 ORDER BY 操作效率低，需要额外操作。
（6）MySQL最大行大小不能超过64KB（65535字节），所以一个表中的字段不要太多，理论上建议不要超过30个。
（7）如果存储的字符串长度几乎相等，推荐使用CHAR定长字符串类型。
（8）VARCHAR是可变长字符串，不预先分配存储空间，长度不要超过2000，如果存储长度大于此值，定义字段类型为text或blob，独立出来一张表，用主键来对应，避免影响其他字段索引效率。TEXT 和 BLOB 的主要差别是 BLOB 能够保存二进制数据；而 TEXT 只能保存字符数据。在程序设计时，尽可能不使用TEXT、BLOB类型。
（9）区分使用DATETIME和TIMESTAMP，两者都可用来表示YYYY-MM-DD HH:MM:SS类型的日期。两种都保存日期和时间信息，毫秒部分最高精确度都是6位数。建议使用TIMESTAMP(3)。
A. TIMESTAMP占用4字节，DATETIME占用8字节，当保存毫秒部分时两者都使用额外的空间 （1-3 字节）。
B. TIMESTAMP的取值范围比DATETIME小得多，不适合存放比较久远的日期。TIMESTAMP只能存储从 \'1970-01-01 00:00:01.000000\' 到 \'2038-01-19 03:14:07.999999\' 之间的时间。而DATETIME允许存储从 \'1000-01-01 00:00:00.000000\' 到 \'9999-12-31 23:59:59.999999\' 之间的时间。
C. TIMESTAMP的插入和查询受时区的影响。如果记录的日期需要让不同时区的人使用，***使用 TIMESTAMP。
（10）根据实际需要选择能够满足应用的最小存储的日期类型。如果应用只需记录“年份”，那么用1个字节的YEAR类型完全可以满足，而不需要用4个字节来存储的DATE类型。这样不仅可以节约存储，还可以提高表的操作效率。
（11）小数类型为decimal，禁止使用float和double。因为float和double在存储的时候，存在精度损失问题，这是浮点数特有的问题。因此在精度要求比较高的应用中（比如货币）要使用定点数而不是浮点数来保存数据。浮点数指的就是含有小数的值，浮点数插入到指定列中超过指定精度后，浮点数会四舍五入，MySQL 中的浮点数指的就是 float 和 double，定点数指的是 decimal，定点数能够更加精确的保存和显示数据。
（12）字段允许适当冗余，以提高性能，但是必须考虑数据完整性。冗余字段应遵循：
A. 不是频繁修改的字段。
B. 不是varchar超长字段，更不能是text字段。
C. 需要维护冗余字段的数据完整性。
3.3 主键设计原则（1）一定要有显式的主键。
（2）针对InnoDB，在无特殊需求的情况下，建议使用与业务无关的自增ID作为主键。
（3）自增字段做主键时，字段类型必须是bigint 。