InnoDB使用utf8mb4时能否按字节长度限制CHAR类型？

针对你需要存储数十亿条数据、行空间宝贵的需求，同时要实现类似CHAR(50)（但以字节为长度单位）的效果，以下是几种可行方案：

1. 可变长度存储+触发器字节校验（兼顾可读性与空间） #

使用VARCHAR(50) CHARACTER SET utf8mb4定义字段，同时通过触发器强制校验字节长度不超过50：

CREATE TRIGGER check_byte_length_before_insert
BEFORE INSERT ON your_table
FOR EACH ROW
BEGIN
    IF LENGTH(NEW.your_column) > 50 THEN
        SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '字符串字节长度超过50限制';
    END IF;
END;

-- 同理创建UPDATE触发器
CREATE TRIGGER check_byte_length_before_update
BEFORE UPDATE ON your_table
FOR EACH ROW
BEGIN
    IF LENGTH(NEW.your_column) > 50 THEN
        SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '字符串字节长度超过50限制';
    END IF;
END;

• 优势：数据完全可读，VARCHAR仅存储实际需要的字节（加1-2字节长度前缀），比utf8mb4下的CHAR(50)（固定占用200字节）节省大量空间。
• 劣势：触发器会增加写入操作的性能开销，批量插入数十亿条数据时需评估性能影响。

2. 二进制类型存储（极致空间效率） #

直接使用VARBINARY(50)或BINARY(50)类型：

• VARBINARY(50)：可变长度，最多存储50字节，实际占用空间为数据字节数+1-2字节前缀，空间利用率最高。
• BINARY(50)：固定50字节长度，适合需要固定行宽的场景。
• 读取时若需可读性，可通过CONVERT(your_column USING utf8mb4)转换为字符串。
• 优势：无额外校验开销，严格按字节长度限制，存储效率最优。
• 劣势：原始存储为二进制，默认查询结果不可读，需手动转换。

3. 应用层前置校验+数据库兜底（平衡性能与可读性） #

在应用层写入数据前，先校验字符串的utf8mb4字节长度是否≤50，同时在数据库端通过检查约束做兜底校验：

ALTER TABLE your_table ADD CONSTRAINT check_byte_length CHECK (LENGTH(your_column) <= 50);

• 优势：避免触发器的性能损耗，数据保持可读，应用层控制更灵活。
• 劣势：依赖应用层逻辑的准确性，需确保所有写入路径都做了校验。

额外说明 #

utf8mb4下的CHAR(50)是按字符数定义，每个字符最多占4字节，因此固定占用200字节，完全不符合你的空间需求。上述方案中，若优先兼顾可读性和空间，方案1或3更合适；若追求极致空间效率，方案2是最优选择。

内容的提问来源于stack exchange，提问作者Aran Sumishii