索引提示必须写在具体DML语句中且位置严格：SQL Server用WITH(INDEX())或WITH(FORCESEEK)紧贴表名，MySQL用FORCE INDEX()或USE INDEX()紧跟表名、WHERE前；视图内无效，强制索引需配合SARGable条件与覆盖索引。
不能在存储过程定义语句里“加个配置”就让所有查询走指定索引——索引提示必须出现在具体的 SELECT、UPDATE 或 DELETE 语句中，且语法、位置、生效条件都极敏感。
SQL Server 中必须用 WITH(INDEX()) 或 WITH(FORCESEEK) 写在表名后
提示不是注释，也不是存储过程参数，它只对紧邻的基表生效。写错位置（比如放在 WHERE 后面）或漏掉括号，SQL Server 直接报错或静默忽略。
-
FROM orders o WITH (INDEX(ix_orders_user_id))✅ 正确：WITH 紧贴表别名 -
FROM orders o WITH (FORCESEEK(ix_orders_user_id))✅ 更强约束：强制 Seek，但要求 WHERE 条件可 SARGable（不能对字段用CONVERT、UPPER()等） -
FROM orders o INDEX = ix_orders_user_id❌ 错误：语法不合法 -
FROM orders o WITH (INDEX(ix_orders_user_id)) JOIN users u ...⚠️ 注意：users 表没加提示，优化器可能为它选错驱动表
MySQL 中只能用 FORCE INDEX() 或 USE INDEX()，且必须紧跟表名
FORCE INDEX 是硬性指令，USE INDEX 是软性建议；二者都必须写在 FROM 子句的表名之后、WHERE 之前，否则 MySQL 解析失败。
-
SELECT * FROM orders FORCE INDEX (idx_orders_status) WHERE status = 'shipped'✅ 生效 -
SELECT * FROM orders WHERE status = 'shipped' FORCE INDEX (idx_orders_status)❌ 报错：syntax error near 'FORCE' -
SELECT * FROM orders AS o FORCE INDEX (idx_orders_status)✅ 可行，但后续所有列引用必须用别名o.status，不能混用orders.status -
FORCE INDEX绕过统计信息——如果某 status 值占比从 2% 涨到 45%，查询可能从毫秒级退化成秒级，且无任何警告
视图 + 存储过程组合下，索引提示基本失效
无论是 SQL Server 还是 MySQL，索引提示都无法穿透视图。你在存储过程中写 SELECT * FROM my_view WITH (INDEX(...))，SQL Server 报错，MySQL 直接忽略。
- SQL Server 报错：
Incorrect syntax near the keyword 'WITH' - MySQL 不报错但不生效：视图展开后，提示已丢失上下文，底层基表看不到这个指令
- 真正有效的做法：把提示下推到视图定义内部的 SELECT 语句中（如果权限允许且视图可控）
- 更稳妥的替代：别依赖提示，改用覆盖索引 + 更新统计信息 + 拆分复杂视图
最常被忽略的一点：强制索引是临时止痛药，不是诊断报告。一旦用了 FORCESEEK 或 FORCE INDEX，你得同步确认 WHERE 条件是否真的能利用该索引的前导列，以及该索引是否已包含 SELECT 需要的所有字段（避免回表）。否则，表面走了索引，实际性能可能更差。
