phpEnv本地环境索引优化需与生产一致：WHERE高频字段须建索引，单值等值优先唯一索引，状态字段宜入复合索引前置位，前缀索引适配长文本，复合索引顺序须匹配查询条件，避免函数、隐式转换及通配符前置导致失效，善用覆盖索引并定期ANALYZE TABLE。
phpEnv 是本地开发环境套件，本质仍是 Apache + PHP + MySQL 组合，数据库索引优化逻辑和生产环境完全一致——不因“本地”而降低标准，也不因“没流量”就跳过索引设计。
WHERE 条件字段必须加索引
所有在 where 中高频出现的字段，只要不是低基数（如 is_deleted、gender），都应单独或联合建索引。ThinkPHP 的 where('user_id', 123)、Laravel 的 ->where('status', 'paid') 都属于典型场景。
- 单值等值查询（如
email = ?）优先用单列唯一索引：CREATE UNIQUE INDEX idx_user_email ON users (email); - 状态类字段（如
status）若配合时间范围使用，不要单独建索引，应纳入复合索引前置位 - phpEnv 默认 MySQL 版本多为 5.7 或 8.0，支持前缀索引，对长文本字段（如
title）可限制长度：ADD INDEX idx_article_title (title(32));
复合索引顺序必须匹配查询条件顺序
MySQL 的最左前缀原则不会因 phpEnv 环境而失效。你在本地写的 where('category_id', 5)->where('price', '>', 99)，如果索引是 (price, category_id)，那它基本等于没建。
- 先看 WHERE 中字段出现顺序：若代码中固定是
user_id在前、created_at在后，索引就该建为(user_id, created_at) - 范围查询（
>、BETWEEN、LIKE 'abc%'）之后的字段无法命中索引，所以created_at > ? AND status = ?应建(created_at, status)，但实际更推荐(status, created_at)—— 因为status筛选性通常更强，且能覆盖status = ?单独查询 - phpEnv 下可通过 phpMyAdmin 直接执行
EXPLAIN SELECT ...，观察type是否为ref或range，key是否显示你建的索引名
避免索引失效的写法（本地最容易忽略）
本地开发时图省事写的 SQL，上线后一模一样会出问题。phpEnv 不会帮你绕过索引失效逻辑。
立即学习“PHP免费学习笔记（深入）”；
- 禁止在索引字段上用函数：
WHERE YEAR(created_at) = 2025→ 改成WHERE created_at >= '2025-01-01' AND created_at - 禁止隐式类型转换：
WHERE user_id = '123'（字段是 INT）→ 字符串强制转整型可能丢索引，统一用整型参数 -
LIKE '%keyword'必然全表扫描；LIKE 'keyword%'可走索引；LIKE '%keyword%'建议交给全文索引或 Elasticsearch，别硬扛 - ThinkPHP 的
whereRaw()和 Laravel 的whereRaw()容易写出破坏索引的表达式，每次用都要手动EXPLAIN验证
用好覆盖索引减少回表
回表是性能隐形杀手，在 phpEnv 小数据量下不明显，但一旦数据过万，延迟会陡增。覆盖索引意味着“只查索引就拿到全部要的字段”，不用再回主键索引树取数据行。
- 例如查询常用组合：
SELECT id, name, email FROM users WHERE status = 1，可建覆盖索引：ALTER TABLE users ADD INDEX idx_status_cover (status, id, name, email); - 注意字段顺序：
WHERE条件字段放最左，SELECT 字段按需跟在后面；不要把大字段（如TEXT）塞进索引 - phpEnv 下可用
EXPLAIN查看Extra列是否含Using index—— 有就是覆盖索引生效了 - 框架里容易忽略这点：Laravel 的
select(['id','name'])配合对应覆盖索引，比select('*')快得多，尤其在列表页
真正容易被忽略的是：phpEnv 环境下没人盯慢查询日志，也没人定期 ANALYZE TABLE。但表统计信息不准，优化器就会选错执行计划——哪怕索引建对了，也可能不走。建议每周手动跑一次 ANALYZE TABLE xxx;，或者在迁移脚本末尾加上这句。
