tinyint比int更能缓解内存寻址压力，因其仅占1字节，可使innodb索引页单页多存3倍键值，降低b+树高度与内存/磁盘寻址次数；而int占4字节，宽字段加剧缓存行浪费、临时表内存预分配膨胀及null位图开销。
直接结论：选小不选大、定长不盲用、NULL要慎用——数据类型不是“够用就行”，而是“刚好够用”才真正降低内存寻址压力。
为什么TINYINT比INT更能缓解内存寻址压力
内存寻址压力不仅来自数据体积，更来自CPU对齐、缓存行填充和索引树节点分裂。InnoDB的B+树索引页默认16KB，字段越宽，单页能存的键值越少，树高越容易增加，每次查询需要更多次内存寻址（甚至磁盘I/O）。
-
TINYINT占1字节，INT占4字节：同样存年龄0–120，用TINYINT可让主键或二级索引单页多存3倍键值，显著减少树层级 - 字段宽度影响
row_format=COMPACT下的变长字段头开销：VARCHAR(50)和VARCHAR(255)都用2字节长度头，但后者在排序/临时表中可能触发更大内存分配 - MySQL 8.0+ 对
ENUM和SET的内部存储优化有限，且迁移成本高，不推荐替代数值类型
VARCHAR(50) 与 VARCHAR(255) 在内存中的实际差异
表面看只是长度声明不同，但在内存寻址链路上差异明显：临时表、排序缓冲区、JOIN缓存都会按声明最大长度预分配空间，而非按实际内容。
- 执行
ORDER BY name时，若name是VARCHAR(255)，MySQL 默认按255字节为每行预留空间，哪怕实际只存5个字符 -
tmp_table_size和max_heap_table_size限制的是“内存临时表总容量”，宽字段会更快耗尽配额，迫使落盘到磁盘临时表（Created_tmp_disk_tables计数上升） - 建议做法：根据业务真实上限设长，如用户名≤32字符 → 用
VARCHAR(32)；手机号固定11位 → 用CHAR(11)
NOT NULL + 默认值如何减少索引结构内存开销
InnoDB索引记录中，每个可为NULL的字段需额外1字节的NULL位图（NULL bitmap），且优化器在估算执行计划时对NULL字段的统计信息更模糊，易导致错误选择全表扫描。
- 例如
status TINYINT NULL DEFAULT NULL比status TINYINT NOT NULL DEFAULT 0多占1字节/行（位图），千万级表就是近1MB纯开销 - 复合索引中含NULL字段时，
(a, b, c)若c允许NULL，WHERE a=1 AND b=2无法利用索引最左前缀高效定位，可能退化为范围扫描 - 时间字段别用
DATETIME NULL，改用DATETIME NOT NULL DEFAULT '1970-01-01 00:00:00'或TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
DECIMAL(10,2) 与 FLOAT 在内存和寻址上的隐性成本
浮点类型看似省空间，但精度丢失会导致查询条件失效（如 WHERE amount = 99.99 匹配失败），进而触发全表扫描——这才是最大的内存寻址压力来源。
-
FLOAT占4字节，DECIMAL(10,2)内部以二进制字符串形式存储，实际占5字节，但保证精确比较，索引可100%命中 - 涉及
GROUP BY或ORDER BY时，FLOAT因精度问题可能生成大量近似但不等值的分组，撑大内存临时表 - 金额、比例、计数类字段，一律用
DECIMAL；仅科学计算等允许误差场景才考虑FLOAT/DOUBLE
真正容易被忽略的点是：数据类型选择的影响不在单行，而在索引结构、临时表分配、执行计划稳定性这三层叠加效应上。改一个字段类型，可能让原本每秒处理2000 QPS的查询，在高峰时因多一次内存寻址或一次磁盘临时表而跌到800 QPS——这种衰减不会报错，只会悄悄拖慢整个系统。
