thinkphp6支撑万级并发需精准索引治理：where字段优先建索引，高频等值查询用唯一索引，联合索引按等值→范围→排序顺序设计，json字段须提取虚拟列再索引，并用explain验证执行计划。
ThinkPHP6 要稳定支撑 1 万并发请求，MySQL 索引优化不是“加几个索引”就能解决的，而是需结合查询模式、数据分布、TP6 的实际调用习惯，做精准、分层、可验证的索引治理。核心目标是：让高频查询走索引、避免回表、杜绝全表扫描，同时控制写入开销不明显上升。
WHERE 条件字段必须建索引
这是最直接有效的起点。TP6 中大量使用 where() 链式方法，只要该字段出现在 WHERE 中且查询频次高，就应优先建索引。
- 用户登录场景：手机号（
mobile）、邮箱（email）这类唯一性高、筛选性强的字段，建唯一索引（UNIQUE INDEX） - 订单列表页：常查
user_id = ? AND status = ?，适合建联合索引INDEX idx_user_status (user_id, status)，注意顺序——等值查询字段放前，范围字段（如create_time）放后 - 软删除场景：ThinkPHP 默认用
delete_time IS NULL筛选有效数据，该条件高频出现，建议在delete_time上建普通索引（即使值多为 NULL，InnoDB 仍能索引非 NULL 值）
JSON 字段内部键要“提取+索引”
TP6 常用 JSON 字段存扩展信息（如 extra），但 MySQL 不支持对 JSON 列直接建有效索引。直接写 where('extra->>\'$.action\'', 'login') 会全表扫描。
- 必须用 MySQL 虚拟列把键值“拎出来”：
ALTER TABLE logs ADD COLUMN v_action VARCHAR(32) GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(extra, \'$.action\'))) VIRTUAL; - 再对虚拟列建索引：
CREATE INDEX idx_v_action ON logs(v_action); - TP6 查询改用普通字段：
LogModel::where('v_action', 'login')->select();—— 这样才能命中索引
组合索引要按“最左前缀+选择性”排序
单列索引堆砌不如一个设计合理的联合索引。TP6 的 where()->order()->limit() 链式调用，天然适配组合索引覆盖。
- 例如订单表常用查询：
OrderModel::where('status', 1)->where('pay_time', 'between', [$s, $e])->order('id desc')->select();
对应索引应为INDEX idx_status_paytime_id (status, pay_time, id) - 原则：等值条件字段（
status）放最左；范围条件（pay_time）居中；排序字段（id）放最后，可实现“索引覆盖”，无需回表 - 避免冗余：已有
(a,b,c)索引，就不必再单独建(a)或(a,b)索引
用 EXPLAIN 验证，别信“写了 where 就走索引”
TP6 生成的 SQL 是否真用了索引，必须看执行计划。在开发/预发环境对关键接口开启慢日志 + EXPLAIN 分析。
- 在 TP6 中临时启用原生分析：
Db::query('EXPLAIN ' . $query->buildSql()); - 重点关注
type（应为ref/range/index，非ALL），key（是否显示索引名），rows（扫描行数是否显著下降） - 常见失效场景：对索引字段用函数（
WHERE DATE(create_time) = '2026-08-17'）、隐式类型转换（WHERE mobile = 13800138000字符串字段传整型）、OR 拆分不当
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
