如何调整MySQL中int字段长度，使其适应特定数据范围？

在 MySQL 中，INT 字段的长度看似只是一种显示宽度。实则与存储空间、性能和索引效率息息相关。许多开发者在实际项目中遇到以下痛点：

• 字段定义过大导致磁盘占用冗余。话说回来，
• 索引列过宽使查询变慢。
• 数据迁移时出现“值超出范围”错误。
• 对小范围数据使用 TINYINT/SMALLINT 仍然浪费空间。

1. 了解 INT 长度的真正意义

存储空间

MySQL 中 INT 总是占用 4 字节。无论你写成 INT,INT,或不写长度。按理说，长度参数仅用于显示宽度。不影响实际存储大小或取值范围。

取值范围

• -2 147 483 648 到 2 147 483 647

对性能的影响

• 索引列宽度增加: 每个索引项多占 4 字节。可能导致索引页填充率下降，从而增加磁盘 I/O。
• 排序/分组成本上升: 较大的整数需要更多字节比较，尤其在大表上更明显。
• 内存消耗提高: 查询缓存、临时表等场景会按字段大小分配内存。

说到痛点一。磁盘占用无效浪费

a) 当业务只需要小范围整数时使用默认的 INT 占用一样 4 字节，却让数据结构显得臃肿；b) 在大型 OLAP 程序中，这些冗余会直接转化为磁盘 I/O 的瓶颈。

从痛点二来看，索引效率下降导致查询慢卡顿

a) 索引列过宽导致每条记录需要读取更多字节；b) 大量行的排序/分组操作会因字节数增多而延迟；c) 对于高并发 OLTP 环境，甚至可能触发页面换入换出。

2. 如何根据实际数据范围选择合适的数据类型？

a) 确定最大最小值

1. A+ B 数据预估：`SELECT MIN,MAX FROM table;` 把结果跟你预期的数据区间对照。话说回来，
2. No overflow risk：`IF` 那就换类型。

b) 选型教程

类型 | 可用空间 | 推荐场景 | 示例语句
TINYINT | ±128 / ±256	| 少于 256 的计数、状态码	| `TINYINT UNSIGNED`
SIGNED SMALLINT | ±32k / ±64k	| 小到中等计数、等级编号	| `SMALLINT`
SIGNED MEDIUMINT | ±8M / ±16M	| 大量计数但低于 MEDIUM 范围	| `MEDIUMINT`
SIGNED INT | ±2B / ±4B	| 常规业务主键、订单号等	| `INT`
SIGNED BIGINT | ±9E18 / ±1.8E19	| 超大计数、全局唯一 ID 等	| `BIGINT`

1. MIGRATION PLAN：`ALTER TABLE t MODIFY col BIGINT;` 后使用 `