应按数据实际范围选择最小整数类型并区分char/varchar使用场景：整数优先tinyint、smallint，启用unsigned；字符串中定长用char，变长varchar需精准设长，禁用text存短文本。
如果您在设计MySQL数据库表结构时发现磁盘占用异常偏高或查询响应变慢，则很可能是由于字段类型选择过大或不匹配实际数据特征。以下是针对不同数据类别选择最优字段类型的实操方法：
一、整数类型：按数值范围选用最小可行类型
整数类型字节数直接决定存储开销与索引效率，过大的类型会成倍增加主键和外键的B+树节点体积，拖慢范围扫描与JOIN性能。应依据业务实际最大值选择最小可容纳类型。
1、确认字段取值上限：统计现有或预估未来5年该字段最大可能值，例如订单ID当前最高为876万，远低于INT UNSIGNED的42亿上限。
2、优先尝试TINYINT：适用于状态码（0-9）、性别（0/1）、启用标志（0/1）等仅需0–255范围的场景。
3、用SMALLINT替代INT：当最大值≤65535（如部门编号、商品分类ID）时，SMALLINT(2字节)比INT(4字节)节省50%空间。
4、启用UNSIGNED属性：若字段绝无负值（如点击量、库存数），添加UNSIGNED可使正数范围翻倍，从而允许选用更小类型。
5、禁用BIGINT作为默认ID：除非使用雪花算法或日均写入超千万级记录，否则INT UNSIGNED已完全满足用户ID、订单号等核心主键需求。
二、字符串类型：区分固定与可变长度场景
CHAR与VARCHAR的存储机制差异显著影响页内密度与I/O次数。固定长度字段使用CHAR可避免行迁移与碎片；变长内容使用VARCHAR可防止空间浪费，但需警惕长度定义冗余。
1、对长度恒定字段强制使用CHAR：身份证号（18位）、国家代码（2位）、MD5哈希值（32位）、订单状态码（如'PAID'、'SHIP'固定4字符）均适用CHAR(N)。
2、VARCHAR长度必须精确收敛：例如邮箱字段最大实测长度为126字符，则定义VARCHAR(126)，而非盲目设为VARCHAR(255)——后者在UTF8MB4下将额外占用2字节长度头，且可能触发二级索引截断限制。
3、禁用TEXT存储短文本：标题、简介、标签等长度通常
4、ENUM替代有限字符串集合：如“订单状态”仅有'created'、'paid'、'shipped'、'delivered'四种取值，使用ENUM('created','paid','shipped','delivered')仅占1字节（≤255选项）或2字节（≤65535选项），远优于VARCHAR(20)平均占用20+字节。
三、小数类型：金融类必须用DECIMAL，非精度场景慎用FLOAT
FLOAT和DOUBLE采用IEEE 754二进制浮点表示，无法精确表达十进制小数（如0.1+0.2≠0.3），在金额、税率、库存重量等场景将引发不可接受的累计误差；而DECIMAL以字符串方式存储并执行定点运算，保障绝对精度。
1、货币字段统一使用DECIMAL(M,D)：例如价格字段定义为DECIMAL(10,2)，表示共10位数字含2位小数，最大支持99999999.99，存储严格按十进制编码，无舍入偏差。
2、禁用FLOAT存储金额：即使显示正常，SUM()或AVG()运算后可能出现0.00000001级误差，线上支付系统曾因此触发对账失败告警。
3、科学计算或传感器读数等允许误差场景，可选用FLOAT(单精度，4字节)替代DOUBLE(双精度，8字节)，节省50%空间。
4、避免DECIMAL过度留白：DECIMAL(20,10)虽支持极大范围，但若业务中价格始终在0.01–99999.99之间，应收缩为DECIMAL(10,2)，减少每行存储开销与排序内存消耗。
四、日期时间类型：按语义与时区需求精准匹配
DATETIME与TIMESTAMP虽都表示时间戳，但物理存储、时区行为及范围差异巨大。错误混用不仅浪费空间，还可能导致跨时区业务逻辑错乱或2038年问题。
1、记录业务固有时点（如订单创建时间、合同签署日）必须用DATETIME：其8字节存储不依赖时区，范围1000–9999年，避免因服务器时区变更导致数据偏移。
2、仅当需自动时区转换且时间范围可控时选用TIMESTAMP：4字节存储，范围1970–2038年，插入时自动转为UTC、查询时转回会话时区，适合记录登录日志、操作审计等事件时间。
3、纯日期或纯时间字段拆分使用DATE（3字节）或TIME（3字节）：比DATETIME节省5字节/行，例如生日字段只需DATE，打卡时间只需TIME。
4、禁止使用VARCHAR或INT存储时间：前者无法利用索引范围查询，后者丧失可读性与内置函数支持，且INT(11)存储Unix时间戳仍受限于2038年溢出风险。
五、空值与约束：用NOT NULL + 默认值替代NULL容忍
NULL值在InnoDB中并非“不占空间”，而是在行记录头中设置一个单独的NULL位图（每列1 bit），且会导致索引无法覆盖全字段、优化器估算失真、JSON生成异常等问题。主动规避NULL可提升压缩率与查询稳定性。
1、所有非业务必需为空的字段均设为NOT NULL：包括创建时间、更新时间、状态字段、数量字段等。
2、为NOT NULL字段配置合理默认值：如created_at默认CURRENT_TIMESTAMP，status默认0（待处理），quantity默认0，避免应用层传NULL或空字符串。
3、枚举型字段用TINYINT NOT NULL替代VARCHAR NOT NULL：例如将'gender' VARCHAR(10)改为gender TINYINT NOT NULL DEFAULT 0，值0=未知、1=男、2=女，节省至少9字节/行并杜绝非法字符串输入。
4、确需表达“未知”语义时，用专用标记值代替NULL：如年龄字段设为TINYINT NOT NULL DEFAULT 255，约定255代表“不详”，既节省空间又保持索引完整性。
