mysql 5.6前add index全程锁表；5.6起部分支持inplace但非绝对免锁，需满足innodb_file_per_table=on且无text/blob字段；函数在where中会导致索引失效；联合索引字段顺序应按过滤性、范围性、排序性优化；optimize table本质重建表，慎用，优先alter table … engine=innodb；无明确性能问题勿随意调整索引。
ALTER TABLE … ADD INDEX 会锁表吗
在 MySQL 5.6 之前，ALTER TABLE ... ADD INDEX 默认全程锁表，写操作全阻塞。5.6 起支持 ALGORITHM=INPLACE（需满足条件），但不是所有情况都免锁——比如对大表加唯一索引，仍可能触发拷贝重建。
- 确认是否真正“在线”：执行前查
SHOW VARIABLES LIKE 'innodb_file_per_table'，必须为ON；且索引字段不能含TEXT/BLOB等大对象类型 - 用
pt-online-schema-change更稳妥：它通过影子表+触发器同步数据，适合生产环境百 GB 级表，但要注意主从延迟放大风险 - 避免在业务高峰执行：即使走 INPLACE，CPU 和 I/O 压力仍会陡增，监控
Threads_running和Innodb_row_lock_time_avg
WHERE 条件里用了函数，索引还生效吗
不生效。像 WHERE YEAR(created_at) = 2023 或 WHERE UPPER(name) = 'ABC'，MySQL 无法直接使用 created_at 或 name 上的索引，因为索引 B+ 树存的是原始值，不是函数结果。
- 改写为范围查询：
WHERE created_at >= '2023-01-01' AND created_at ，能走索引且更精确 - 需要函数检索时，建函数索引（MySQL 8.0+）：
CREATE INDEX idx_name_upper ON users ((UPPER(name))) - 注意隐式转换陷阱：
WHERE mobile = 13812345678（字段是VARCHAR）会触发全表扫描，应统一为字符串比较
联合索引字段顺序怎么排才不白建
顺序决定索引能否被 WHERE、ORDER BY、GROUP BY 复用。核心原则：等值查询字段放前，范围查询字段放后，排序/分组字段尽量靠右但不能破坏最左前缀。
- 例如查询
WHERE status = 'done' AND created_at > '2023-01-01' ORDER BY updated_at，建(status, created_at, updated_at)比(created_at, status, updated_at)更有效——前者能跳过status过滤后直接定位范围，后者因created_at是范围条件，status就无法利用索引排序 - 高频单字段查询别依赖联合索引覆盖：如果常查
WHERE user_id = ?，单独建user_id索引比塞进联合索引更轻量 - 字段选择性（distinct 值占比）高的放前面：比如
is_deleted（只有 0/1）就不该放联合索引首位
索引碎片高了，OPTIMIZE TABLE 真的要跑吗
不一定。对 InnoDB 表，OPTIMIZE TABLE 实际执行的是 ALTER TABLE ... FORCE，本质重建表——会引发长事务阻塞、磁盘空间翻倍、主从延迟飙升。碎片本身不直接影响查询性能，除非页利用率长期低于 50% 且伴随大量随机 I/O。
- 先看真实碎片：查
information_schema.INNODB_SYS_TABLES和INNODB_SYS_INDEXES，算DATA_FREE / (DATA_LENGTH + INDEX_LENGTH)，>25% 再考虑处理 - 优先用
ALTER TABLE t ENGINE=InnoDB替代OPTIMIZE：语义相同但更明确，且可加ALGORITHM=INPLACE控制方式 - 日常预防比事后清理重要：批量删除后及时
DELETE FROM t WHERE ... LIMIT 1000分批，避免单次产生大量空闲页
索引维护最麻烦的从来不是语法，而是判断“此刻要不要动”——查不到慢查询、没监控告警、没观察到 I/O 峰值，就别碰线上大表的索引结构。