SQL索引怎么创建_详细步骤拆解实现完整应用场景【教程】-SQL-PHP中文网

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

sql索引怎么创建_详细步骤拆解实现完整应用场景【教程】

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 单独条件就用不上这个索引

线上加索引可能锁表、拖慢写入，尤其大表。不同数据库策略不同：

MySQL 5.6+：默认支持 ALGORITHM=INPLACE，不锁表（但仍有短暂元数据锁），推荐显式写法：
ALTER TABLE logs ADD INDEX idx_log_type_time (log_type, create_time) ALGORITHM=INPLACE, LOCK=NONE;
PostgreSQL：直接用 CONCURRENTLY，完全不阻塞读写：
CREATE INDEX CONCURRENTLY idx_user_email ON users(email);（注意：不能在事务块中执行）
小提醒：加索引前先 EXPLAIN 确认原查询是否真走全表扫描；加完再 EXPLAIN ANALYZE 验证效果

建了索引却没用上？多半掉进这些坑里：

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

对索引列做函数/运算：如 WHERE YEAR(create_time) = 2024 → 改成 WHERE create_time >= '2024-01-01' AND create_time
隐式类型转换：user_id 是 BIGINT，但写成 WHERE user_id = '123' → 字符串强制转数字，索引失效
LIKE 通配符开头： WHERE name LIKE '%张%' 无法用索引；可考虑全文索引或倒排表替代
OR 条件混用无索引列： WHERE a = 1 OR b = 2，若只有 a 有索引，整个条件可能放弃索引 → 拆成 UNION 或补全索引

不只是“能用”，还要“用得好”：

前缀索引节省空间：对长文本字段（如邮箱、URL），不必索引全字段：
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);
部分索引（PostgreSQL / MySQL 8.0+）只索引满足条件的数据：
CREATE INDEX idx_active_orders ON orders(user_id) WHERE status = 'paid';（大幅缩小索引体积，提升写入速度）