导入后必须重建索引是因为批量插入会触发频繁索引更新拖慢速度，且导致B+树页分裂不均、统计信息过期，引发查询走错执行计划；需用事务安全重建并检查innodb_file_per_table、磁盘空间和用户权限。
为什么导入班级通信录后必须重建索引
MySQL 的 INSERT 或 LOAD DATA INFILE 导入大量数据时，如果表原有索引（尤其是复合索引或全文索引）未被禁用，每插入一行都会触发索引更新，导致导入速度断崖式下降——10 万条记录可能从 2 秒拖到 120 秒以上。更关键的是，InnoDB 的 B+ 树索引在批量写入后可能出现页分裂不均、统计信息过期等问题，后续 SELECT 查询执行计划容易走错索引，查姓“张”的学生反而全表扫描。
PHP 中安全重建索引的两种实操路径
不要直接在 PHP 里拼接 DROP INDEX + CREATE INDEX，风险高且无法回滚。推荐以下两个经生产验证的方式：
- 对中小规模（ALTER TABLE ... DISABLE KEYS +
ENABLE KEYS（仅 MyISAM 支持，已淘汰，不推荐） - 对主流 InnoDB 表（推荐）：先删索引，再导入，最后重建，但必须包裹在事务 + 异常捕获中
示例关键逻辑：
// 假设通信录表为 class_contacts，需重建的索引是 idx_name_grade
try {
$pdo->beginTransaction();
// 1. 记录原索引定义（可选，用于校验）
$stmt = $pdo->query("SHOW CREATE TABLE class_contacts");
$createSql = $stmt->fetchColumn(1);
// 2. 删除目标索引（注意：不能删主键或唯一约束关联的索引）
$pdo->exec("DROP INDEX idx_name_grade ON class_contacts");
// 3. 执行导入（如 PDO::prepare + execute 批量插入，或调用 LOAD DATA）
importContactsFromCsv($pdo, '/tmp/class.csv');
// 4. 重建索引（显式指定 USING BTREE 防止默认引擎误判）
$pdo->exec("CREATE INDEX idx_name_grade ON class_contacts (name, grade) USING BTREE");
$pdo->commit();
} catch (Exception $e) {
$pdo->rollback();
throw new RuntimeException('索引重建失败：' . $e->getMessage());
}
重建索引前必须检查的三个隐藏条件
很多 PHP 导入脚本卡在重建阶段，不是语法错，而是环境不满足：
立即学习“PHP免费学习笔记（深入）”；
-
innodb_file_per_table=ON—— 若为 OFF，DROP INDEX不释放磁盘空间，重建后表文件仍臃肿 - 磁盘剩余空间 ≥ 原表大小 × 1.2 ——
CREATE INDEX会生成临时排序文件，空间不足直接报ERROR 1206 (HY000): The total number of locks exceeds the lock table size - 用户权限包含
INDEX和ALTER—— 仅INSERT权限不够，常见于运维分配的只读账号误用于导入
比重建索引更省事的替代方案
如果通信录数据本身无高频实时查询需求（比如仅用于导出 PDF 名册），其实可以跳过重建索引：
- 导入前用
ANALYZE TABLE class_contacts更新统计信息，让优化器重估行数分布 - 对低频字段（如“家庭住址”）不建索引，改用
WHERE name LIKE '王%'+ 覆盖索引idx_name_id减少 I/O - 把通信录拆成两张表：
class_contacts_basic（含 id/name/grade，建索引）和class_contacts_detail（含电话/地址/家长姓名，无索引），用 JOIN 按需查
真正耗时的从来不是 SQL 语句本身，而是没想清楚“这个索引到底为谁服务”。通信录导入后立刻重建，很多时候只是惯性动作，而不是必要操作。
