大数据量表索引优化关键在精准匹配查询模式：优先为WHERE、JOIN、ORDER BY中高频字段建复合索引，遵循最左前缀原则；高区分度字段前置，避免函数操作导致失效；配合覆盖索引、分区和定期统计更新，确保索引高效可用。
直接用 CREATE INDEX 建索引不难，但对大数据量表（比如单表超 10 万行），建得不合理反而拖慢查询、卡住写入，甚至引发锁表。关键不在“会不会建”，而在于“建在哪、怎么建、什么时候建”。
哪些字段值得建索引？看查询实际怎么用
只给真正参与查询逻辑的字段建索引，不是所有字段都上：
-
WHERE 条件里的列：比如
WHERE status = 'paid' AND created_at > '2025-01-01'，status和created_at就是候选； -
ORDER BY 或 GROUP BY 的列：如
ORDER BY user_id DESC，user_id排序频繁就值得索引； -
JOIN 关联字段：例如
orders.user_id = users.id，两边都建议有索引； -
区分度高的列优先：比如
email（几乎唯一）比gender（只有男/女）更适合做索引，后者建了也基本不走索引。
怎么写 CREATE INDEX 才高效？避开常见坑
基础语法没错，但细节决定成败：
- 普通单列索引：
CREATE INDEX idx_user_status ON orders (status); - 联合索引更常用（推荐）：
CREATE INDEX idx_orders_status_time ON orders (status, created_at);—— 注意顺序：把区分度高、过滤性强的字段放前面（如status只有几种值，但加了时间范围后结果集小，所以status放前更利于最左前缀匹配）； - 字符串字段用前缀索引：
CREATE INDEX idx_user_name ON users (name(10));—— 不必索引全文，前 10 个字符已能很好区分大部分姓名； - 唯一性明确就用唯一索引：
CREATE UNIQUE INDEX idx_user_email ON users (email);—— 既加速查询，又防重复数据。
大数据量建索引要特别注意什么？
千万级表建索引可能耗时几分钟甚至更久，期间可能阻塞写操作（取决于 MySQL 版本和配置）：
-
避开业务高峰执行：比如凌晨或低峰期运行
CREATE INDEX； -
确认存储引擎支持在线 DDL：MySQL 5.6+ 的 InnoDB 支持
ALGORITHM=INPLACE，可减少锁表时间（可显式加上：CREATE INDEX ... ALGORITHM=INPLACE, LOCK=NONE;）； - 别一次性建太多索引：每多一个索引，INSERT/UPDATE/DELETE 就多一份维护开销，还占磁盘空间；
-
建完立刻验证是否生效：用
EXPLAIN SELECT ...看key字段是否命中你刚建的索引，避免“建了等于没建”。
建完不是终点：定期看看它还健不健康
索引会老化、会失效，尤其数据分布变化大之后：
- 用
SHOW INDEX FROM orders;查看索引基本信息； - 查
information_schema.STATISTICS或用sys.schema_unused_indexes（MySQL 8.0+）识别长期未被使用的索引； - 如果某索引
Cardinality极低（远小于表总行数），说明区分度差，考虑删掉； - 表数据大量变更后，可执行
ANALYZE TABLE orders;更新统计信息，帮优化器更好选索引。
