必须将with(index())紧贴表名或别名后、在from子句中且位于where前，仅对紧邻基表生效；多表join需为每张表单独添加，视图内无效，写错位置或语法即报错或静默失效。
SQL Server 存储过程中怎么写 WITH(INDEX()) 才生效
必须把 WITH(INDEX()) 紧贴在表名或别名后面，不能放在 WHERE 后、不能当注释、也不能写在存储过程定义头里。它只对紧邻的那张基表起作用。
-
FROM orders o WITH (INDEX(ix_orders_user_id))✅ 正确：括号完整，位置紧贴别名 -
FROM orders o WITH (FORCESEEK(ix_orders_user_id))✅ 更强约束，但要求WHERE条件可 SARGable（比如不能用UPPER(status)） -
FROM orders o INDEX = ix_orders_user_id❌ 语法错误，SQL Server 直接报错 -
FROM orders o WITH (INDEX(ix_orders_user_id)) JOIN users u⚠️ 注意：users表没加提示，优化器可能选错驱动表
多表 JOIN 时，每张表都要单独加提示；漏一个，整个执行计划就可能偏离预期。
MySQL 存储过程中 FORCE INDEX 的位置和写法陷阱
FORCE INDEX 必须出现在 FROM 子句的表名之后、WHERE 之前，且不能跨表复用——每个表都要独立指定。
-
SELECT * FROM orders FORCE INDEX (idx_status_created) WHERE status = 'shipped'✅ 生效 -
SELECT * FROM orders WHERE status = 'shipped' FORCE INDEX (idx_status_created)❌ 语法错误，MySQL 解析失败 -
SELECT * FROM orders AS o FORCE INDEX (idx_status_created)✅ 可行，但后续所有列引用必须用o.status，不能混用orders.status -
UPDATE orders FORCE INDEX (idx_user_id) SET status = 'done' WHERE user_id = 123✅ UPDATE 也支持，但风险更高（回表+锁范围扩大）
别名和提示要严格匹配；写错位置或漏括号，不是静默忽略，而是直接报错或执行计划不变。
视图 + 存储过程组合下索引提示为什么总失效
索引提示无法穿透视图。你在存储过程中写 SELECT * FROM my_view WITH (INDEX())，SQL Server 报错，MySQL 则直接忽略——因为提示已丢失上下文，底层基表根本看不到它。
- SQL Server 报错：
Incorrect syntax near the keyword 'WITH' - MySQL 不报错但不生效：视图展开后提示已剥离，执行计划里
key列仍是NULL - 真正有效的做法：把提示下推到视图定义内部的
SELECT语句中（需有修改视图权限） - 更稳妥的替代：别依赖提示，改用覆盖索引 + 定期
ANALYZE TABLE+ 拆分大查询
试图在视图外“打补丁”加提示，99% 是白忙活。
强制索引后为什么 EXPLAIN 显示用了索引但实际还是慢
FORCE INDEX 或 WITH(INDEX()) 只保证“使用该索引”，不保证“高效使用”。看到 key 非空就以为优化成功，是常见误判。
- 复合索引未满足最左前缀：索引是
(user_id, status, created_at)，但查询只写WHERE status = 'x'→ 即使强制，也无法走索引 - 隐式类型转换：
WHERE user_id = '123'（user_id是INT）→ 索引失效，强制也无效 - 函数导致不可 SARGable：
WHERE YEAR(created_at) = 2024→ 强制指定created_at上的索引也没用 - 强制非覆盖索引 + 大量回表：
SELECT *走二级索引，再回主键查所有字段，I/O 成倍增加
真正要盯的是 EXPLAIN FORMAT=JSON 里的 used_key_parts 和 rows_examined_per_scan，而不是只看 key 列有没有值。
