选对字段类型需依据数据本质四要素：存什么、怎么用、会不会变、精不精确。整数优先INT，小范围用TINYINT，超21亿选BIGINT；金额等精确场景必用DECIMAL；字符串按长度与国际化需求选CHAR/NVARCHAR/VARCHAR(MAX)；时间按语义选DATETIME/DATE/TIMESTAMP；布尔推荐TINYINT(1)。
选对字段类型，不是靠猜，而是看数据本质——要存什么、怎么用、会不会变、精不精确，这四点决定了类型选得对不对。
整数类字段怎么挑
INT最常用，范围够大（-21亿到+21亿），适合用户ID、订单号、评分这类常规整数。如果确定不会超255，比如状态码（0=待处理，1=完成，2=失败），用TINYINT更省空间；要是系统规模极大，ID可能突破21亿，就得上BIGINT。注意：所有整数类型都不需要写长度（比如INT(11)里的11只是显示宽度，不影响存储能力），无符号（UNSIGNED）能翻倍扩大正数范围，比如TINYINT UNSIGNED可存0~255。
- TINYINT：1字节，0~255（无符号）或-128~127（有符号）
- SMALLINT：2字节，适合小范围计数器、年级、年份
- INT：4字节，绝大多数主键和业务编号的默认选择
- BIGINT：8字节，日志流水号、大型平台用户ID、高并发订单号
带小数的数不能乱用FLOAT
金额、库存数量、百分比这些必须精确的场景，一律用DECIMAL，比如DECIMAL(10,2)表示最多10位数字，其中2位小数——存9999999.99刚好，超了会报错或截断。FLOAT/DOUBLE是近似值，存在二进制浮点误差，比如0.1+0.2≠0.3，金融系统绝不能用。如果只是记录温度、测量值等允许微小误差的数据，FLOAT可以接受。
- DECIMAL(M,D)：M是总位数，D是小数位，必须指定，不可省略
- MONEY（SQL Server特有）：专为货币设计，自动处理精度与格式，但跨数据库兼容性差
- FLOAT：单精度，约6~7位有效数字；DOUBLE：双精度，约15位，仍属近似存储
字符串字段别只盯VARCHAR
VARCHAR(255)确实是万金油，适合用户名、标题、地址等长度不定的文本。但如果字段内容固定且极短（如性别“M/F”、状态“Y/N”、国家代码“CN”），CHAR(2)反而更高效——定长读取快，无额外长度字节开销。涉及中文、多语言或未来可能国际化时，优先选NVARCHAR（Unicode支持），哪怕英文多也建议用，避免乱码隐患。TEXT/NTEXT用于超长内容（如文章正文、日志详情），但现代应用中常被VARCHAR(MAX)替代。
- CHAR(n)：固定长度，存“男”会补空格到n位，比较时需TRIM
- NVARCHAR(n)：Unicode可变长，推荐用于所有新表的文本字段（n≤4000）
- VARCHAR(MAX)：最大2GB，替代TEXT，支持LIKE、全文索引等操作
时间与逻辑字段要按语义选
DATETIME覆盖1753–9999年，精度到毫秒级的三分之一秒，适合记录创建时间、交易时间等关键业务时间点。DATE只存日期（YYYY-MM-DD），比如生日、合同生效日。TIMESTAMP在MySQL中带自动更新特性（如ON UPDATE CURRENT_TIMESTAMP），适合记录最后修改时间；SQL Server中则倾向用DATETIME2获得更高精度和更广范围。布尔型别硬套BIT或BOOLEAN——多数场景用TINYINT(1)或直接用BIT，存0/1即可，语义清晰又兼容性强。
- DATETIME：通用强兼容，推荐大多数时间字段首选
- DATE：纯日期场景，节省空间，避免时间部分干扰
- TINYINT：模拟布尔（0=No，1=Yes），比BIT在ORM和导出时更稳妥
基本上就这些。类型不是越多越好，而是够用、准确、易维护。建表前花两分钟想清楚字段的真实用途，比后期改结构省十倍力气。
