索引字段越短、B+树层级越浅，磁盘I/O越少；前缀索引、联合索引顺序、索引数量、覆盖索引冗余、唯一索引锁机制均需权衡读写性能。
索引字段越短，B+树层级越浅
MySQL 的 PRIMARY KEY 和二级索引都基于 B+ 树，树的高度直接决定磁盘 I/O 次数。每层节点能存的键值数量，和单个索引项大小强相关：字段越长（比如用 VARCHAR(255) 存邮箱但只用前 20 位区分），页内能放的键就越少，树就更容易变高。
实操建议：
- 对字符串字段建索引时，优先考虑
INDEX (email(32))而非全字段，前提是业务上前 N 位已具备足够区分度 - 避免在
TEXT或长VARCHAR上直接建普通索引；若必须搜索，改用前缀索引或倒排（如FULLTEXT） - 联合索引中把等值查询字段放前面，排序/范围字段放后面——顺序错会导致索引截断失效
索引不是越多越好，写放大和内存压力会反噬读性能
每次 INSERT/UPDATE/DELETE 都要同步更新所有相关索引。一个表有 5 个索引，写操作实际可能触发 5 次 B+ 树分裂+页写入。更隐蔽的问题是：索引总大小超过 innodb_buffer_pool_size，会导致频繁换页，SHOW ENGINE INNODB STATUS 中能看到大量 Pages made young 或 Pages read ahead 异常值。
判断依据：
- 用
SELECT SUM(index_length) FROM information_schema.TABLES WHERE table_schema = 'db' AND table_name = 't';查索引总字节数 - 对比
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';，若索引体积 > 70% 缓冲池，就要警惕 - 慢查日志里反复出现
Using index condition却仍慢，可能是索引太多导致缓存命中率低
覆盖索引能省掉回表，但字段冗余会拖慢写入和备份
覆盖索引（SELECT a,b FROM t WHERE a=1，且 INDEX(a,b) 存在）确实避免了聚簇索引回查，但 b 字段被重复存两份：一份在聚簇索引叶子页，一份在二级索引叶子页。这意味着：
iWebShop是一款基于PHP语言及MYSQL数据库开发的B2B2C多用户开源免费的商城系统，系统支持自营和多商家入驻、集成微信商城、手机商城、移动端APP商城、三级分销、视频电商直播、微信小程序等于一体，它可以承载大数据量且性能优良，还可以跨平台，界面美观功能丰富是电商建站首选源码。iWebShop开源商城系统 v5.14 更新日志：新增商品编辑页面规格图片上传优化商品详情页面规格图片与主图切
- 插入一行，
b值要写两次；更新b，也要同步改两个位置 -
mysqldump或物理备份时，数据文件体积增大，网络传输和恢复时间拉长 - 如果
b是JSON或大文本，这种冗余代价远超查询收益
权衡做法：
-- 好：高频查询且 b 很小（如 status TINYINT） CREATE INDEX idx_a_b ON t(a, b);-- 小心：b 是 VARCHAR(500) 或 TEXT -- 更优解：只建 idx_a，用 JOIN 或应用层二次查询补 b
唯一索引和普通索引在并发写入时表现不同
唯一索引（UNIQUE KEY）要求插入前做唯一性校验，InnoDB 必须加 next-key lock 锁住插入间隙；而普通索引只需在插入后加记录锁。高并发 INSERT 场景下，前者更容易引发锁等待甚至死锁。
典型现象：
- 批量导入时，
Duplicate entry报错少但Lock wait timeout多 → 可能是唯一索引锁冲突 - 用
INSERT ... ON DUPLICATE KEY UPDATE时，唯一索引会强制走唯一扫描，比普通索引多一次查找 - 如果业务能接受应用层去重（如先
SELECT再INSERT），有时宁可去掉唯一约束，靠代码逻辑保一致性
真正难平衡的，从来不是“要不要加索引”，而是“这个索引在最差写负载下，会让主库延迟多少秒”。线上调优时，pt-index-usage 和 sys.schema_unused_indexes 只能告诉你“没用过”，没法告诉你“加了会不会拖垮写入”。得看 SHOW PROFILE FOR QUERY 里的 innodb_rows_inserted 和锁等待时间。
