innodb中联合主键即聚簇索引，决定数据物理存储顺序，支持前缀匹配的高效查询与排序；myisam中仅为普通b树索引，不控制数据存放，查询和插入行为均不同。
PRIMARY KEY 是联合主键的声明方式，但它的实际行为完全取决于存储引擎。InnoDB 和 MyISAM 对联合主键的处理逻辑根本不同，直接导致查询、插入、索引扫描等操作的性能表现差异明显。
联合主键在 InnoDB 中就是聚簇索引的排序依据
InnoDB 的数据物理存放顺序严格按 PRIMARY KEY 定义的列顺序排列，联合主键也不例外。比如 PRIMARY KEY (user_id, create_time)，数据会先按 user_id 分组，组内再按 create_time 升序排列。
这意味着：
- 范围查询如
WHERE user_id = 123 AND create_time BETWEEN '2025-01-01' AND '2025-06-01'能走聚簇索引，I/O 极少 - 但
WHERE create_time > '2025-01-01'（跳过首列）无法利用该联合主键做索引查找，只能全表扫描 - 插入时若
user_id值离散（如 UUID），会导致大量页分裂和随机写，性能骤降
MyISAM 的联合主键只是普通 B 树索引，不控制数据物理位置
MyISAM 中 PRIMARY KEY (a, b) 和 INDEX (a, b) 在结构上没本质区别——都是独立的索引文件（.MYI），叶子节点只存行地址（.MYD 中的 offset）。数据文件本身是纯追加式顺序存储，跟主键定义无关。
所以：
- 即使跳过首列（如只查
b），只要b列有单独索引，就能用；但联合主键本身对b单独查询无效 - 插入性能更稳定，因为不依赖主键顺序，不会引发页分裂
-
COUNT(*)快是因为 MyISAM 缓存了行数，跟是否联合主键无关
联合主键下的 ORDER BY 和 GROUP BY 行为差异极大
InnoDB 能天然利用联合主键的物理顺序加速 ORDER BY a, b 或 GROUP BY a（前缀匹配），无需额外排序；而 MyISAM 即使定义了相同联合主键，也大概率触发 Using filesort，因为数据没按该顺序组织。
典型陷阱：
- 在 MyISAM 表上执行
SELECT * FROM t ORDER BY a, b LIMIT 10，看起来走了主键，实际仍可能排序 - InnoDB 中
GROUP BY a可能利用主键前缀完成松散索引扫描（Loose Index Scan），MyISAM 不支持该优化 - 如果业务依赖
ORDER BY稳定性，仅靠 MyISAM 的联合主键声明不能保证结果物理有序
别忽略引擎切换时的隐式行为变化
把 MyISAM 表 ALTER TABLE ... ENGINE=InnoDB 后，联合主键立刻变成聚簇索引，但原来靠“自然插入顺序”隐式保障的查询性能（比如按时间倒序取最新几条）可能崩掉——因为 InnoDB 会按主键重排所有数据，旧的插入顺序彻底丢失。
更隐蔽的问题：
- MyISAM 的
REPAIR TABLE能恢复损坏的索引，但 InnoDB 没这机制；一旦联合主键索引页损坏，只能从备份恢复 - InnoDB 的
INSERT ... ON DUPLICATE KEY UPDATE依赖联合主键去定位冲突行，MyISAM 不支持该语法 - 主从复制中，基于语句的复制（SBR）下，MyISAM 表的联合主键冲突行为和 InnoDB 可能不一致，尤其涉及
REPLACE INTO
真正影响性能的从来不是“有没有联合主键”，而是“数据怎么落盘”和“查询是否匹配引擎的物理组织逻辑”。InnoDB 把联合主键当命脉，MyISAM 当摆设——选错引擎，再精巧的联合主键设计也救不了查询计划。
