本系列开启一个数据库性能之旅，一起看看各主流数据库对于性能做了哪些背后的优化，本节先从索引检索层面分析。本章不是讲索引如何优化数据检索效率的，主要是降如何在索引的基础上再提升文本排序检索效率。
基础知识（请自行跳过）
索引是什么？
数据库索引，通常简称为****索引，是一种数据结构，其主要作用是加快提数据表上数据检索的速度。
索引一般是从表中选定列（column, 一个或多个列）的数据建立存储副本，通过“键”或指向其对应行位置的链接。
索引可以简单理解成一本字典的目录。目的是提高检索数据的效率，是****典型的空间换时间的理念。
索引通过提前把部分表中数据（列）提前排序存放起来。
问题来了。
看看各个厂商怎么解决这个问题：
PostgreSQL
Abbreviated Keys
PostgreSQL在9.5版本中引入了Abbreviated Keys用来对于字符类型的排序优化，PG的官档介绍对于create index可以提升3倍。Numeric排序也能优化。贡献者： Peter Geoghegan
实现原理，通过对前边几个字符的压缩做预判断，可以大幅提升索引排序效率，如果前边字符相同数据较多，会有小部分性能损耗，见下边网友测试。
测试方案：
- 短随机 – 1,000,000 random, unique, strings, 5 characters long
- 长随机 – 1,000,000 random, unique, strings, 80 characters long
- 长随机-前缀相同 – 1,000,000 random, unique, strings, 80 characters long, but first 20 characters have only 100 different possibilities, and the prefix is 18 zeros, and then 2 digits
测试结果：
| table: | 9.4: | 9.5: | difference: |
|---|---|---|---|
| 短随机 | 3,801.084 ms | 1,069.608 ms | – 71% |
| 长随机 | 7,696.992 ms | 4,359.055 ms | – 43% |
| 长随机-前缀相同 | 23,795.578 ms | 24,538.389 ms | + 3% |
网友测试参考链接：
官方测试连接：
www.postgresql.org/message-id/…
发布后禁止使用：
9.5版本发出之后出了严重问题，某些场景下会引起索引损坏，在某些场景禁止使用，9.5.2中直接禁用了。
wiki.postgresql.org/wiki/Abbrev…
后续迭代 9.6
对于 uuid, bytea, char(n) 都能使用"abbreviated" keys加快排序速度。
增加了text_pattern_ops，varchar_pattern_ops和bpchar_pattern_ops操作符的"abbreviated" keys支持
特性介绍参考链接：
Peter Geoghegan的博客
