SQL索引需建表前预判、线上安全添加并避开失效陷阱。主键自动建聚簇索引;外键和高频查询字段应手动建索引;组合索引遵循最左前缀原则;MySQL用ALGORITHM=INPLACE,PostgreSQL用CONCURRENTLY;避免对索引列使用函数或运算。

SQL索引不是“建了就快”,关键在选对字段、用对类型、避开常见坑。下面按真实开发节奏,一步步带你从建表前预判到上线后优化,覆盖大多数业务场景。
别等慢查询报警才加索引——那已经晚了。建表阶段就要结合主键、唯一性、高频查询条件做预判:
CREATE TABLE user (id BIGINT PRIMARY KEY, name VARCHAR(50)),id 列天然带高效索引,不用额外加user_id 是外键,且常用于 JOIN 或 WHERE user_id = ?,就该立刻建:CREATE INDEX idx_order_user_id ON orders(user_id);
WHERE status = 'paid' AND created_at > '2024-01-01',建 INDEX idx_status_created ON orders(status, created_at);但反过来查 created_at 单独条件就用不上这个索引线上加索引可能锁表、拖慢写入,尤其大表。不同数据库策略不同:
ALGORITHM=INPLACE,不锁表(但仍有短暂元数据锁),推荐显式写法:ALTER TABLE logs ADD INDEX idx_log_type_time (log_type, create_time) ALGORITHM=INPLACE, LOCK=NONE;
CONCURRENTLY,完全不阻塞读写:CREATE INDEX CONCURRENTLY idx_user_email ON users(email);(注意:不能在事务块中执行)EXPLAIN 确认原查询是否真走全表扫描;加完再 EXPLAIN ANALYZE 验证效果建了索引却没用上?多半掉进这些坑里:
WHERE YEAR(create_time) = 2024 → 改成 WHERE create_time >= '2024-01-01' AND create_time
user_id 是 BIGINT,但写成 WHERE user_id = '123' → 字符串强制转数字,索引失效WHERE name LIKE '%张%' 无法用索引;可考虑全文索引或倒排表替代WHERE a = 1 OR b = 2,若只有 a 有索引,整个条件可能放弃索引 → 拆成 UNION 或补全索引不只是“能用”,还要“用得好”:
CREATE INDEX idx_user_email_prefix ON users(email(32));(前32字符足够区分大部分邮箱)SELECT id, name, email FROM users WHERE status = 'active',可建:CREATE INDEX idx_status_cover ON users(status, id, name, email);
CREATE INDEX idx_active_orders ON orders(user_id) WHERE status = 'paid';(大幅缩小索引体积,提升写入速度)基本上就这些。索引不是越多越好,而是刚好够用、刚好命中、刚好不拖累写入。每次加索引前,问自己三个问题:这个查询真的慢吗?慢在哪一步?加了这个索引,其他写操作会变卡吗?答案清楚了,再动手。
以上就是SQL索引怎么创建_详细步骤拆解实现完整应用场景【教程】的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号