navicat建索引卡住是因mysql执行alter table add index时默认采用保守策略，触发全表扫描、mdl锁及可能的copy算法；需手动指定algorithm=inplace和lock=shared，并确保innodb_buffer_pool_size充足、无长事务阻塞。
Navicat 里点“确定”保存索引却卡住几十秒甚至超时，不是界面卡顿，而是 MySQL 正在后台执行 ALTER TABLE ... ADD INDEX，这个 DDL 操作本身会阻塞、锁表、扫描全表——尤其对大表，慢是必然的，不是 Navicat 的 bug。
为什么建索引会触发全表扫描和锁表
MySQL（InnoDB）在 8.0 之前默认不支持在线加索引；即使 8.0+ 启用了 ALGORITHM=INPLACE，只要表数据量大、索引字段区分度低或存在大量重复值，仍需遍历每行构建 B+ 树。这个过程：
- 会持有
MDL（元数据锁），阻塞其他 DDL 和部分 DML（如INSERT/UPDATE/DELETE） - 若未开启
innodb_online_alter_log_max_size或日志空间不足，会退化为拷贝表方式（COPY算法），更慢且占双倍磁盘空间 - Navicat 默认不显式指定
ALGORITHM和LOCK级别，MySQL 自行决策，常选最保守（也最慢）路径
Navicat 可视化建索引时没配参数，等于裸跑 DDL
Navicat 的“索引”页只让你选字段和类型，但关键执行参数它不暴露：
- 没地方填
ALGORITHM=INPLACE或ALGORITHM=COPY - 无法设置
LOCK=NONE（仅当满足严格条件才允许）、LOCK=SHARED或LOCK=DEFAULT - 不提示你当前表是否满足 online DDL 条件（比如：不能有全文索引、不能是临时表、外键约束有限制等）
结果就是 Navicat 发出的语句类似：ALTER TABLE orders ADD INDEX idx_user_status (user_id, status)，MySQL 按默认策略执行，大概率锁表 + 全量重建。
大表建索引前必须手动干预的三件事
别依赖 Navicat 点确定——先切到查询编辑器，手动执行带控制参数的语句：
- 确认是否支持 online：
SELECT @@innodb_default_row_format, @@innodb_file_per_table;（都应为Dynamic和ON） - 查当前是否有长事务：
SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5;，有则等其结束，否则 DDL 会被挂起 - 用显式语法建索引：
ALTER TABLE orders ADD INDEX idx_user_status (user_id, status) ALGORITHM=INPLACE, LOCK=SHARED;（LOCK=SHARED允许并发读，但阻塞写；若业务可接受短时写停顿，比默认更可控）
真正容易被忽略的性能断点
建索引慢，有时根本不是 DDL 本身的问题：
-
innodb_buffer_pool_size设置过小（比如默认 128MB），导致索引构建过程中频繁刷脏页、IO 拉垮 - 磁盘是机械硬盘（HDD）或 IOPS 不足的云盘，
ALTER TABLE是重度顺序读 + 随机写，对 IO 压力极大 - 表上有触发器或外键级联操作，MySQL 会在索引构建期间额外校验约束，进一步拖慢
- Navicat 连接配置里启用了“自动提交”但没关“查询超时”，界面上显示“执行中…”，其实是客户端主动中断了连接，而 MySQL 后台仍在跑（变成孤儿任务）
