主题
面试速答（先看这里）
**一句话结论：**我们在上面的文章中讲过一种优化MySQL 中 like查询的方案，那就是将列反转然后存储并创建索引。
60秒标准回答：
我们在上面的文章中讲过一种优化MySQL 中 like查询的方案，那就是将列反转然后存储并创建索引
而 Oracle 中已经支持了一种反向键索引的方式。加入一个字段的值为"hollis_chuang"，那么反向键索引就是以反转后的值作为索引的 key，即"gnauhc_silloh"
反向键索引的主要好处就是可以优化 like 的查询性能 ，like "%hollis_chuang" 可以被优化成"gnauhc_silloh%"，这样就可以利用最左前缀匹配进行索引精确查询了
**答题顺序：**结论 → 原理/机制 → 关键流程 → 场景与取舍 → 易错点
回答主线：
- **要点1：**而 Oracle 中已经支持了一种反向键索引的方式。
- **要点2：**反向键索引的主要好处就是可以优化 like 的查询性能 ，like "%hollis_chuang" 可以被优化成"gnauhc_silloh%"，这样就可以利用最左前缀匹配进行索引精确查询了。
- **要点3：**反向键索引还有一个好处，那就是通过反转键值的顺序，从而分散了插入点，减少了热点问题 。
- **要点4：**在高并发插入的环境中，如热点的秒杀场景，会有非常频繁的数据插入，并且插入的数据都是连续的，那么就会出现热点块，而使用反向键索引就可以减少由于插入操作引起的I/O热点。
- **要点5：**但是需要注意的是，反向键索引不适合范围查询，因为键值的字节序反转后，原本连续的数值可能在物理存储上变得不连续。
**记忆锚点：**反向键索引 → like → hollis_chuang → gnauhc_silloh → 转然后存储并创建索引 → 以反转后的值作为索引
关键取舍：
- 反向键索引的主要好处就是可以优化 like 的查询性能 ，like "%hollis_chuang" 可以被优化成"gnauhc_silloh%"，这样就可以利用最左前缀匹配进行索引精确查询了。
- 创建反向键索引的SQL命令如下： 但是需要注意的是，反向键索引不适合范围查询，因为键值的字节序反转后，原本连续的数值可能在物理存储上变得不连续。
易错提醒：
- 创建反向键索引的SQL命令如下： 但是需要注意的是，反向键索引不适合范围查询，因为键值的字节序反转后，原本连续的数值可能在物理存储上变得不连续。
加分表达：
- 我们在上面的文章中讲过一种优化MySQL 中 like查询的方案，那就是将列反转然后存储并创建索引。
- 如果使用反向键索引，则变成1001，2001和3001，这样存储的位置就更加分散一些。
追问准备：
- 围绕「反向键索引」：底层原理是什么？使用时有哪些边界和常见坑？
- 围绕「like」：底层原理是什么？使用时有哪些边界和常见坑？
- 围绕「hollis_chuang」：底层原理是什么？使用时有哪些边界和常见坑？
- 如果线上出现异常，你会如何定位、验证并规避？
典型回答
我们在上面的文章中讲过一种优化MySQL 中 like查询的方案，那就是将列反转然后存储并创建索引。
而 Oracle 中已经支持了一种反向键索引的方式。加入一个字段的值为"hollis_chuang"，那么反向键索引就是以反转后的值作为索引的 key，即"gnauhc_silloh"。
反向键索引的主要好处就是可以优化 like 的查询性能，like "%hollis_chuang" 可以被优化成"gnauhc_silloh%"，这样就可以利用最左前缀匹配进行索引精确查询了。
反向键索引还有一个好处，那就是通过反转键值的顺序，从而分散了插入点，减少了热点问题。假设有一个顺序增加的键，如1001, 1002, 1003等。在标准的B-树索引中，这些键将连续存储，可能导致特定部分的数据库页过于频繁地更新。如果使用反向键索引，则变成1001，2001和3001，这样存储的位置就更加分散一些。
在高并发插入的环境中，如热点的秒杀场景，会有非常频繁的数据插入，并且插入的数据都是连续的，那么就会出现热点块，而使用反向键索引就可以减少由于插入操作引起的I/O热点。
创建反向键索引的SQL命令如下：
plain
CREATE INDEX my_reverse_index ON my_table(my_column) REVERSE;但是需要注意的是，反向键索引不适合范围查询，因为键值的字节序反转后，原本连续的数值可能在物理存储上变得不连续。所以，用起来要慎重！