索引提示必须写入具体DML语句中，位置语法极敏感：SQL Server需紧贴表名用WITH(INDEX())或FORCESEEK，MySQL需在FROM后WHERE前用FORCE INDEX()，视图和存储过程中无效，且仅为临时干预手段。
不能在存储过程定义处加索引提示，必须写进具体 SELECT/UPDATE/DELETE 语句里，且位置、语法、生效条件极敏感——写错一行就失效或报错。
SQL Server 中 WITH(INDEX()) 必须紧贴表名
SQL Server 的索引提示不是注释，也不是参数，它只对紧邻的基表生效。WITH (INDEX()) 必须直接跟在表名或别名后，中间不能有换行、空格以外的字符；漏括号、放错位置（比如写在 WHERE 后）都会导致报错或静默忽略。
-
FROM orders o WITH (INDEX(ix_orders_user_id))✅ 正确：提示绑定到o表 -
FROM orders o WITH (FORCESEEK(ix_orders_user_id))✅ 更强约束：强制 Seek，但要求WHERE条件可 SARGable（不能对字段用UPPER()、CONVERT()等） -
FROM orders o INDEX = ix_orders_user_id❌ 语法非法，SQL Server 直接拒绝解析 - 多表 JOIN 时，每个表都要单独加提示：
JOIN users u WITH (INDEX(pk_users))，漏一个就可能让驱动表选错
MySQL 中 FORCE INDEX() 必须紧跟表名且在 WHERE 前
MySQL 不允许把 FORCE INDEX() 当作存储过程语法成分来声明，它只能作为 DML 语句的一部分，且位置极其严格：必须出现在 FROM 子句中表名之后、WHERE 之前，否则直接语法报错。
-
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%，查询可能从毫秒级退化成秒级，且无任何警告
视图 + 存储过程组合下，索引提示基本无效
索引提示无法穿透视图定义。你在存储过程中写 SELECT * FROM my_view WITH (INDEX())，SQL Server 直接报错 Incorrect syntax near the keyword 'WITH'；MySQL 则不报错但完全忽略，因为视图展开后提示已丢失上下文，底层基表根本看不到这个指令。
- 真正有效的做法：把提示下推到视图定义内部的
SELECT语句中（前提是权限允许且视图可控） - 更稳妥的替代方案：别依赖提示，优先更新统计信息、消除隐式转换、设计覆盖索引
- TiDB 等少数数据库支持
qb_name提示精确定位嵌套查询块，但 SQL Server 和 MySQL 均不支持
强制索引是临时干预手段，不是长期解法
索引提示本质是绕过优化器的代价估算，在统计不准、数据倾斜突变、隐式转换未清理等特定场景下快速止血。但它不解决根本问题：一旦数据分布变化、索引失效或查询条件改写，原来有效的提示可能立刻变成性能瓶颈。
-
WITH (FORCESEEK)在WHERE条件不可 SARGable 时会直接报错，而非降级为扫描 -
FORCE INDEX在 MySQL 中不校验索引是否覆盖查询列，若需回表且数据量大，性能反而更差 - 所有主流数据库都强调：优先通过
UPDATE STATISTICS（SQL Server）、ANALYZE TABLE（MySQL）保持统计信息新鲜，比硬编码提示更可持续
最容易被忽略的一点：索引提示只作用于单个基表，不控制连接顺序、不保证执行计划全局最优。哪怕每个表都加了提示，优化器仍可能因驱动表选择错误、内存估算偏差等原因生成低效计划——这时候需要的是连接提示（如 USE_NL、LEADING）或重写逻辑，而不是继续堆索引提示。
