use index (idx_name)必须紧接from后，仅建议优化器考虑指定索引，不强制使用；若索引不存在或不匹配查询条件，优化器可能忽略提示甚至退化为全表扫描。
MySQL 中用 USE INDEX 指定索引的写法和限制
MySQL 不支持 Oracle 那种 /*+ INDEX(t idx_name) */ 风格的优化器提示，而是用 USE INDEX、FORCE INDEX 或 IGNORE INDEX 语法。它们只能出现在 FROM 子句的表名后，且只对单表生效。
常见错误是把它当注释或塞进 WHERE 里——那完全没效果。另外，如果指定的索引不存在、字段类型不匹配（比如对 VARCHAR 字段用 INT 类型的索引列做条件），优化器会静默忽略该提示，甚至可能退化为全表扫描。
-
USE INDEX (idx_name)：告诉优化器“只考虑这些索引”，但不强制使用；若这些索引都不适用，仍可能选其他索引或走全表扫描 -
FORCE INDEX (idx_name)：更激进，等价于“必须用这个索引，哪怕代价更高”，常用于调试或绕过错误的执行计划 - 多列索引必须完整匹配最左前缀才能被真正利用，
FORCE INDEX (idx_a_b)对WHERE b = ?无效
PostgreSQL 中用 SET enable_indexscan = off 并不等于“强制用索引”
PostgreSQL 没有直接指定索引的 HINT 机制，官方也不推荐硬编码索引选择。所谓“强制用索引”，其实是通过关闭某些访问路径来间接影响计划器——但这非常危险，容易导致查询崩溃或性能雪崩。
例如设 SET enable_indexscan = off 后，优化器不能用任何 B-tree 索引，反而可能被迫用顺序扫描或位图扫描；而设 SET enable_seqscan = off 又可能让简单主键查询变慢，因为即使有索引，也可能因统计信息不准而选错路径。
- 真正可控的方式是调整成本参数：
SET random_page_cost = 1.0（模拟 SSD 随机读快）可提升索引扫描权重 - 临时修改单条语句行为，可用
/*+ IndexScan(t idx_name) */——但这需要安装第三方扩展pg_hint_plan，不是默认功能 - 生产环境禁用
enable_*系列开关，它们作用于整个 session，影响不可控
Oracle 的 INDEX 提示为什么有时失效？
Oracle 的提示语法最灵活，但也最容易误用。/*+ INDEX(t idx_name) */ 看似明确，但实际是否生效取决于访问路径是否兼容。比如对 SELECT * FROM t WHERE c1 = ? AND c2 > ?，若 idx_name 是 (c1, c2) 复合索引，提示有效；但若只是 (c2)，则无法跳过 c1 做范围扫描，提示会被忽略。
- 提示必须放在
SELECT、UPDATE或DELETE关键字正后方，空格和换行都允许，但不能跨语句块 - 别名要一致：
SELECT /*+ INDEX(t1 idx_t1_c) */ * FROM table1 t1中的t1必须与提示里的表别名完全匹配 - 如果目标索引被
DISABLE或处于UNUSABLE状态，提示直接报错ORA-38301: cannot perform DDL on a recycle bin object
SQL Server 的 WITH (INDEX(...)) 要小心锁升级和统计偏差
SQL Server 支持在 FROM 子句中用 WITH (INDEX(idx_name)) 强制索引，但它不是“保证命中”，而是“仅允许走这个索引”。一旦该索引不覆盖查询所需列（比如 SELECT * 而索引是非聚集的），就会触发大量书签查找（Key Lookup），性能可能比不加提示还差。
- 非聚集索引 +
SELECT *→ 大量 RID 或聚集键回表，IO 爆增 - 提示中的索引名必须是物理存在的，大小写敏感（取决于数据库排序规则）
- 如果表做了分区，且提示的索引未对齐分区方案，会报错
Msg 8625, Level 16 - 加提示后，查询计划里
Index Seek可能变成Index Scan，尤其当谓词不满足 SARGable 条件时（如WHERE UPPER(col) = 'X'）
实际执行时，提示只是“建议”，最终是否采纳由优化器基于统计信息、数据分布和成本模型决定。最常被忽略的点是：索引本身是否最新？ANALYZE TABLE / UPDATE STATISTICS / DBMS_STATS.GATHER_TABLE_STATS 没跑，提示就只是纸上谈兵。
