数据库缺失索引批量添加提升检索速度
数据库查询变慢，最常见的原因之一是缺少合适的索引。
你不需要手动一条一条写 CREATE INDEX，本文教你用三个步骤批量补上缺失索引，安全且高效。
一、准备工作：确认环境与权限
开始前，请确认你有以下条件：
- 数据库管理工具（如 Navicat、DBeaver）或命令行终端
- 拥有目标库的
SELECT和CREATE INDEX权限 - 准备好一张“待优化表”列表（可以先挑业务压力较大的几张表执行）
如果你用命令行，需要先连接数据库：
mysql -u 用户名 -p 数据库名PostgreSQL 则用：
psql -U 用户名 -d 数据库名二、批量添加缺失索引的核心操作
1. 找出缺失索引
以 MySQL 为例，执行以下 SQL 检查慢查询并推断缺失索引：
SELECT * FROM sys.schema_table_statistics
WHERE rows_fetched > rows_read
ORDER BY rows_fetched DESC LIMIT 20;如果 sys 不可用，可以借助 慢查询日志 定位高扫描行数的查询，再手动分析 WHERE 条件列。
2. 生成批量添加 SQL
假设你已确定一组列需要加索引，可以将它们整理成列表，然后用脚本批量生成 SQL。手动的通用写法：
CREATE INDEX idx_column1 ON table_name (column1);
CREATE INDEX idx_column2 ON table_name (column2);小技巧：把多条语句写入一个 SQL 文件（如add_indexes.sql），然后在命令行运行：
mysql -u root -p database_name < add_indexes.sql这会一次性提交多个索引创建，出错时会跳过并显示错误，不会影响已成功的语句。
3. 分批量大小执行（避坑重点）
大表一次创建太多索引会导致长时间锁表。建议每批只加 2-3 个索引，完成后观察几分钟，再执行下一批。
- MySQL 可以使用
ALTER TABLE ... ADD INDEX代替CREATE INDEX，效果相同 - 如果使用
pt-online-schema-change（Percona Toolkit）可做到在线添加索引，零停机
三、避坑指南：哪些索引不该加
- 不要给低选择性列加索引：性别、状态等只有两三个值的列，加索引帮助不大；
- 避免索引冗余：如果已有复合索引 (a,b)，再单独加 (a) 属于重复，需要先检查现有索引：
SHOW INDEX FROM 表名;- 警惕外键列索引：外键列通常加索引可以提高关联查询，但如果该列极少参与关联，索引反而拖慢写入。
- 批量执行前务必备份：哪怕只是加索引，也建议先在测试环境验证，生产环境选业务低峰期执行。
四、效果验证：确认检索速度提升
加完索引后，必须验证效果。
推荐两种方式：
- 执行慢查询前后对比：找到之前慢的 SQL，用
EXPLAIN查看是否走索引：
EXPLAIN SELECT * FROM 表名 WHERE 列名 = '值';如果 type 从 ALL（全表扫描）变成 ref 或 range，说明生效。
- 用 EXPLAIN ANALYZE（MySQL 8.0.18+） 直接看到执行耗时变化：
EXPLAIN ANALYZE SELECT ...输出中的 actual time 会从几百毫秒降到毫秒级。
五、高频问题解答（FAQ）
Q: 添加索引时表被锁，业务中断怎么办？
A: 推荐使用 pt-online-schema-change 或 MySQL 8.0 的原生 ALGORITHM=INPLACE 方式，可减少锁表时间。对于 PostgreSQL，默认 CREATE INDEX 不会阻塞读取但会阻塞写入，建议用 CONCURRENTLY 参数。
Q: 添加索引后查询反而变慢？
A: 常见原因是索引选择错误（比如列顺序不对）或新索引未被用到。检查 EXPLAIN，必要时使用 FORCE INDEX 强制测试。
Q: 如何监控批量添加进度？
A: MySQL 可以用 SHOW PROCESSLIST; 查看当前正在执行的 CREATE INDEX 和已经运行的时间。
Q: 能否自动智能推荐缺失索引？
A: MySQL 的 sys.schema_unused_indexes 可以找出从不使用的索引，反过来结合 sys.schema_index_statistics 可分析缺失索引，但最终判断仍需人工。
如果你按照本文操作，建议先从一张小表开始测试，熟练后再推广到核心业务表。
遇到异常时，优先回顾避坑部分，会帮你省去很多麻烦。
