数据库索引通过B+树等结构加速WHERE、ORDER BY及JOIN查询，但需遵循最左前缀原则、避免函数操作和隐式转换；PHP中应结合EXPLAIN分析、慢日志监控与区分度评估合理创建索引。
数据库索引是提升 PHP 应用查询性能最直接有效的手段之一，但盲目添加或忽略索引反而会拖慢系统——关键在于理解索引如何工作、何时生效、以及在 PHP 与数据库交互中哪些操作真正受益于它。
索引如何加速 WHERE 和 ORDER BY 查询
当 PHP 执行类似 SELECT * FROM users WHERE email = ? 的语句时，若 email 字段没有索引，MySQL 必须逐行扫描全表（全表扫描）；加上 B+ 树索引后，查找时间从 O(n) 降至 O(log n)，万级数据可能从秒级降到毫秒级。同理，ORDER BY created_at LIMIT 10 若 created_at 已建索引，数据库可直接按索引顺序取前 10 条，无需额外排序。
- 复合索引（如
(status, created_at)）对WHERE status = 1 ORDER BY created_at DESC高效，但对WHERE created_at > '2024-01-01'无效（最左前缀原则） - 字符串字段使用前缀索引需权衡：比如
INDEX (title(50))节省空间，但仅对前 50 字符匹配有效 - PHP 中用 PDO 或 MySQLi 绑定参数不影响索引使用，但拼接 SQL 字符串导致无法复用执行计划，间接削弱索引收益
JOIN 查询中索引的协同作用
PHP 常通过多表关联获取业务数据，例如：SELECT u.name, p.title FROM users u JOIN posts p ON u.id = p.user_id。此时若 posts.user_id 缺少索引，MySQL 在连接时会对每条用户记录遍历全部 posts 行，复杂度飙升。而给外键字段加索引，能让连接过程走索引嵌套循环（Index Nested-Loop Join），极大降低 I/O 开销。
- 被驱动表（通常是 JOIN 右侧）的关联字段必须有索引，否则易触发全表扫描
- 联合主键或唯一约束自动包含索引，但普通外键字段需手动创建索引
- 使用
EXPLAIN查看 PHP 发起的查询执行计划，重点关注type列是否为ref或range，而非ALL
索引失效的常见 PHP 场景
即使字段建了索引，PHP 层某些写法也会让数据库“视而不见”。例如在 WHERE 条件中对索引列使用函数：WHERE YEAR(created_at) = 2024，会导致 created_at 索引失效；又如模糊查询写成 LIKE '%关键词'，前导通配符使索引无法定位起始位置。
立即学习“PHP免费学习笔记（深入）”；
- 避免在索引字段上做隐式类型转换：PHP 传入字符串 ID
'123'查询INT主键，MySQL 可能放弃索引（尤其在严格模式下） - 使用
IN时注意数量：WHERE id IN (1,2,3,...,2000)过长列表可能触发优化器改用全表扫描，可考虑分批或临时表 - PHP 中用
array_unique()或array_filter()在内存里处理数据，代替在 SQL 中用DISTINCT或复杂条件，有时比强行索引更高效
监控与优化建议：从 PHP 日志出发
单纯看 SQL 是否走索引不够，要结合真实流量。可在 PHP 错误日志或中间件中记录慢查询（如执行超 200ms 的语句），再用 EXPLAIN FORMAT=JSON 分析瓶颈。对于高频接口，还可开启 MySQL 的 slow_query_log 并配合 pt-query-digest 统计热点 SQL。
- 新增索引前先用
SELECT COUNT(DISTINCT column) / COUNT(*) AS selectivity FROM table评估区分度，低于 0.01 的低区分度字段（如gender）建索引意义不大 - 定期清理冗余索引：多个索引覆盖相同前缀（如已有
(a,b)，再建(a)就多余），可通过sys.schema_unused_indexes视图识别 - PHP 部署时启用 OPcache 并配置合理 TTL，避免因脚本重复编译掩盖数据库层性能问题
