VARCHAR字段索引未生效主因是尾部空格或隐式类型转换；TINYINT比ENUM更适合状态字段；TIMESTAMP因选择性低影响索引效率；联合索引应按过滤强度排序，等值字段在前、范围字段在后。
为什么 VARCHAR 字段上建了索引却没走？
常见现象是：明明对 name VARCHAR(255) 加了索引，但 SELECT * FROM users WHERE name = 'alice' 执行计划里显示 type: ALL（全表扫描）。根本原因常是字段实际存储值带尾部空格，或查询条件隐式类型转换——比如把数字当字符串查：WHERE name = 123。MySQL 会把 123 转成字符串再比较，但这个过程可能让索引失效。
实操建议：
- 用
SHOW CREATE TABLE users确认字段定义和索引是否真实存在，注意索引名是否拼错 - 检查查询条件是否与字段类型严格一致：字符串字段必须用引号，避免
WHERE id = '123'（id是INT）这类隐式转换 - 用
EXPLAIN FORMAT=TRADITIONAL SELECT ...查看key和possible_keys是否匹配，重点看Extra列是否出现Using where; Using index或Using filesort
TINYINT 和 ENUM 哪个更适合做状态字段？
很多人用 ENUM('active','inactive','pending') 图省事，但它在排序、新增枚举值、跨版本迁移时容易出问题。而 TINYINT UNSIGNED 配合应用层映射更可控，且索引效率更高——因为整型比较比字符串前缀比较快，且占用空间固定（1 字节），无字符集/排序规则开销。
实操建议：
- 状态字段优先选
TINYINT UNSIGNED，用注释或字典表说明含义，比如status TINYINT UNSIGNED COMMENT '0:inactive, 1:active, 2:pending' - 避免
ENUM中文枚举值（如ENUM('启用','禁用')），一旦字符集不一致或排序规则变更，ORDER BY可能错乱 - 如果必须用字符串状态，改用
CHAR(10)并加索引，比VARCHAR(20)更利于索
引压缩和范围扫描
DATETIME 和 TIMESTAMP 对索引选择性的影响
两者都支持索引，但 TIMESTAMP 存储的是 Unix 时间戳（4 字节），DATETIME 是日期时间字符串格式（8 字节）。高并发写入场景下，TIMESTAMP 因精度限制（秒级）和自动更新行为，可能导致大量行拥有相同值，从而降低索引选择性——也就是区分度变差，优化器更倾向放弃使用该索引。
实操建议：
- 记录创建/更新时间，用
DATETIME；需要时区自动转换且数据量极大（如日志表），再考虑TIMESTAMP - 如果经常按时间范围查（如
WHERE created_at BETWEEN '2025-01-01' AND '2025-06-30'），确保字段没被函数包裹：WHERE DATE(created_at) = '2025-01-01'会让索引完全失效 - 对时间字段建索引时，优先建联合索引的最左前缀，例如
(status, created_at)比单列created_at在复合查询中更高效
联合索引中字段顺序怎么排才不浪费？
顺序不是按字母或使用频率排，而是按「过滤强度 + 查询模式」定。比如用户表有 city VARCHAR(50)、age TINYINT、gender CHAR(1)，常查「北京的女性用户」，那 (city, gender, age) 比 (age, city, gender) 更好——因为 city 值分布广（选择性高），能快速筛掉大部分行；而 gender 只有两个值，放前面会导致索引树第一层就分裂成两支，后续字段几乎无法利用。
实操建议：
- 把等值查询字段放前面（如
WHERE city = ? AND gender = ?），范围查询字段（>,BETWEEN）放最后 - 避免在联合索引中间插入函数或计算，如
(city, UPPER(name), age)——UPPER(name)会让该字段之后的所有字段无法用于索引查找 - 用
SELECT COUNT(DISTINCT city)/COUNT(*) AS selectivity FROM users估算选择性，高于 0.1 的字段更适合放索引左侧
最易被忽略的一点：索引不是建得越多越好。每个索引都会拖慢写入速度，且 MySQL 优化器在面对过多索引时可能选错执行计划。上线前务必用真实数据量 + 慢查询日志验证索引是否真被用上。
