1.MySQL 查阅慢是甚么新体验？
绝大多数网络应用情景都是读多写少，业务方法论更多分布在写上。对读的要求大概是要快。那么都有甚么其原因会引致我们完成一次出众的慢查阅呢？
1.1 检索
在信息量并非很大时，大多慢查阅能用检索解决，大多慢查阅也即使检索片面而产生。
MySQL 检索如前所述 B+ 树，这句话相信复试都背烂了，接着就能问最左后缀检索、 B+ 树和各种树了。
说到最左后缀，前述是女团检索的采用规则，采用合理女团检索能有效的提升查阅速度，为何呢？
即使检索楚溪春。假如查阅条件包涵在了女团检索中，比如存在女团检索（a,b)，查阅到满足用户 a 的历史记录后会直接在检索内部判断 b 是否满足用户，减少无法正常进行单次。同时，假如查阅的列正好包涵在女团检索中，即为全面覆盖检索，无须无法正常进行。检索准则估计都晓得，前述开发中也会建立和采用。难题可能将更多的是：为何建了检索还慢？
1.1.1 甚么其原因引致检索失灵建了检索还慢，大多是检索失灵（未采用），需用 explain 分析。检索失灵常用其原因有 :
where 中采用 != 或 <> 或 or 或函数或函数（右侧）like 句子 % 结尾数组难于’’检索表头界定渡过低，如异性恋未相匹配最左后缀(一屁股就晓得老丘托韦了) 为何那些作法会引致失灵，成形的 MySQL 也有自己的设想。
1.1.2 那些其原即使何引致检索失灵假如要 MySQL 给一个理据，还是那棵 B+ 树。
函数操作方式当在 查阅 where = 右侧采用函数或函数时，如表头 A 为数组型且有检索, 有 where length(a) = 6查阅，这时传达一个 6 到 A 的检索树，代普雷在树的第二层就迷路了。
显式切换显式隐式和显式字符串代码切换也会引致那个难题。
显式隐式对 JOOQ 此种架构来说一般倒不会再次出现。显式字符串代码切换在连表查阅时倒可能将再次出现，即连表表头的类型相同但字符串代码不同。毁坏了Roybon至于 Like 句子 % 结尾、数组难于 ’’ 其原因大致相同，MySQL 认为对检索表头的操作方式可能将会毁坏检索Roybon就机敏的强化掉了。
不过，对如异性恋此种界定渡过低的表头，检索失灵就并非即使那个其原因。
1.1.3 异性恋表头为何不要加检索为何检索界定度低的表头不要加检索。盲猜效率低，效率的确低，有时甚至会等于没加。对非聚簇检索，是要无法正常进行的。假如有 100 条数据，在 sex 表头建立检索，扫描到 51 个 male，需要再无法正常进行扫描 51 行。还不如直接来一次全表扫描呢。
所以，InnoDB 引擎对此种情景就会放弃采用检索，至于界定度多低多少会放弃，大致是某类型的数据占到总的 30% 左右时，就会放弃采用该表头的检索，有兴趣能试一下。
1.1.4 有甚么好用且简单的检索方法前面说到大多慢查阅都源于检索，怎么建立并用好检索。这里有一些简单的准则。
检索楚溪春：异性恋表头不适合建检索，但确实存在查阅情景怎么办？假如是多条件查阅，能建立联合检索利用该特性强化。全面覆盖检索：也是联合检索，查阅需要的信息在检索里已经包涵了，就不会再无法正常进行了。后缀检索：对数组，能只在前 N 位添加检索，避免不必要的开支。假如的确需要如关键字查阅，那交给更合适的如 ES 或许更好。不要对检索表头做函数操作方式对确定的、写多读少的表或者频繁更新的表头都应该考虑检索的维护成本。1.1.5 如何评价 MySQL 选错了检索有时，建立了猛一看挺正确的检索，但事情却没按计划发展。就像 “为啥 XXX 有检索，根据它查阅还是慢查阅”。
此刻没准要自信点：我的代码不可能将有 BUG，肯定是 MySQL 出了难题。MySQL 的确可能将有点难题。
此种情况常用于建了一大堆检索，查阅条件一大堆。没采用你想让它用的那一个，而是选了个界定度低的，引致过多的扫描。造成的其原因基本有两个：
信息统计不准确：能采用 analyze table x重新分析。强化器误判：能 force index强制指定。或修改句子引导强化器，增加或删除检索绕过。但根据我浅薄的经验来看，更可能将是即使你建了些没必要的检索引致的。不会真有人以为 MySQL 没自己机灵吧？
除了上面那些检索其原因外，还有下面那些不常用或者说不好判断的其原因存在。
1.2 等 MDL 锁
在 MySQL 5.5 版本中引入了 MDL，对一个表做 CRUD 操作方式时，自动加 MDL 读锁；对表结构做变更时，加 MDL 写锁。读写锁、写锁间互斥。
当某句子拿 MDL 写锁就会阻塞 MDL 读锁，能采用show processlist命令查看处于Waiting for table metadata lock状态的句子。
1.3 等 flush
flush 很快，大多是即使 flush 命令被别的句子堵住，它又堵住了 select 。通过show processlist命令查看时会发现处于Waiting for table flush状态。
1.4 等行锁
某事物持有写锁未提交。
1.5 当前读
InnoDB 默认级别是可重复读。设想一个情景：事物 A 开始事务，事务 B 也开始执行大量更新。B 率先提交， A 是当前读，就要依次执行 undo log ，直到找到事务 B 开始前的值。
1.6 大表情景
在未二次开发的 MYSQL 中，上亿的表肯定算大表，此种情况即使在检索、查阅层面做到了较好实现，面对频繁聚合操作方式也可能将会再次出现 IO 或 CPU 瓶颈，即使是单纯查阅，效率也会下降。
且 Innodb 每个 B+ 树节点存储容量是 16 KB，理论上可存储 2kw 行左右，这时树高为 3 层。我们晓得，innodb_buffer_pool 用来缓存表及检索，假如检索数据较大，缓存命中率就堪忧，同时 innodb_buffer_pool 采用 LRU 算法进行页面淘汰，假如信息量过大，对老或非热点数据的查阅可能将就会把热点数据给挤出去。
所以对大表常用强化即是分库分表和读写分离了。
1.6.1 分库分表方案是分库还是分表呢？这要具体分析。
假如磁盘或网络有 IO 瓶颈，那就要分库和垂直分表。如果是 CPU 瓶颈，即查阅效率偏低，水平分表。水平即切分数据，分散原有数据到更多的库表中。
垂直即按照业务对库，按表头对表切分。工具方面有 sharding-sphere、TDDL、Mycat。动起手来需要先评估分库、表数，制定分片准则选 key，再开发和数据迁移，还要考虑扩容难题。
难题前述运行中，写难题不大，主要难题在于唯一 ID 生成、非 partition key 查阅、扩容。
唯一 ID 方法很多，DB 自增、Snowflake、号段、一大波 GUID 算法等。非 partition key 查阅常用映射法解决，映射表用到全面覆盖检索的话还是很快的。或者能和其他 DB 女团。扩容要根据分片时的策略确定，范围分片的话就很简单，而随机取模分片就要迁移数据了。也能用范围 + 取模的模式分片，先取模再范围，能避免一定程度的数据迁移。当然，假如分库还会面临事务一致性和跨库 join 等难题。
1.6.2 读写分离为何要读写分离分表针对大表解决 CPU 瓶颈，分库解决 IO 瓶颈，二者将存储压力解决了。但查阅还不一定。
假如落到 DB 的 QPS 还是很高，且读远大于写，就能考虑读写分离，基于主从模式将读的压力分摊，避免单机负载过高，同时也保证了高需用，实现了负载均衡。
难题主要难题有过期读和分配机制。
过期读，也是主从延时难题，那个对。分配机制，是走主还是从库。能直接代码中根据句子类型切换或者采用中间件。1.7 小结
以上列举了 MySQL 常用慢查阅其原因和处理方法，介绍了应对较大数据情景的常用方法。
分库分表和读写分离是针对大数据或并发情景的，同时也为了提升系统的稳定和拓展性。但也并非所有的难题都最适合这么解决。
2.如何评价 ElasticSearch
前文有提到对关键字查阅能采用 ES。那接着聊聊 ES 。
2.1 能干甚么
ES 是如前所述 Lucene 的近实时分布式搜检索擎。采用情景有全文搜索、NoSQL Json 文档数据库、监控日志、数据采集分析等。
对非数据开发来说，常用的应该是全文检索和日志了。ES 的采用中，常和 Logstash, Kibana 结合，也成为 ELK 。先来瞧瞧日志怎么用的。
下面是我司日志系统某检索操作方式：打开 Kibana 在 Discover 页面输入格式如 “xxx” 查阅。
该操作方式能在 Dev Tools 的控制台替换为：
甚么意思？Discover 中加上 “” 和 console 中的 match_phrase 都代表这是一个短语相匹配，意味着只保留那些包涵全部搜索词项，且位置与搜索词项相同的文档。
2.2 ES 的结构
在 ES 7.0 之前存储结构是 Index -> Type -> Document，按 MySQL 对比是 database – table – id(前述此种对比不那么合理)。7.0 之后 Type 被废弃了，就暂把 index 当做 table 吧。
在 Dev Tools 的 Console 能通过以下命令查看一些基本信息。也能替换为 crul 命令。
GET /_cat/health?v&pretty：查看集群健康状态GET /_cat/shards?v ：查看分片状态GET yourindex/_mapping :index mapping 结构GET yourindex/_settings :index setting 结构GET /_cat/indices?v : 查看当前节点所有检索信息重点是 mapping 和 setting ，mapping 能理解为 MySQL 中表的结构定义，setting 负责控制如分片数量、副本数量。
以下是截取了某日志 index 下的部分 mapping 结构，ES 对数组类型会默认定义成 text ，同时为它定义一个叫做 keyword 的子表头。这两的区别是：text 类型会进行分词， keyword 类型不会进行分词。
2.3 ES 查阅为何快？
分词是甚么意思？看完 ES 的检索原理你就 get 了。
ES 如前所述倒排检索。嘛意思？传统索引一般是以文档 ID 作检索，以内容作为历史记录。倒排检索相反，根据已有属性值，去找到相应的行所在的位置，也是将单词或内容作为检索，将文档 ID 作为历史记录。
下图是 ES 倒排检索的示意图，由 Term index，Team Dictionary 和 Posting List 组成。
图中的 Ada、Sara 被称作 term，其实是分词后的词了。假如把图中的 Term Index 去掉，是并非有点像 MySQL 了？Term Dictionary 就像二级检索，但 MySQL 是保存在磁盘上的，检索一个 term 需要若干次的 random access 磁盘操作方式。
而 ES 在 Term Dictionary 基础上多了层 Term Index ，它以 FST 形式保存在内存中，保存着 term 的后缀，借此能快速的定位到 Term dictionary 的本 term 的 offset 。而且 FST 形式和 Term dictionary 的 block 存储方式都很节省内存和磁盘空间。
到这就晓得为啥快了，是即使有了内存中的 Term Index , 它为 term 的检索 Term Dictionary 又做了一层检索。
不过，也并非说 ES 甚么查阅都比 MySQL 快。检索大致分为两类。
2.3.1 分词后检索ES 的检索存储的是分词排序后的结果。比如图中的 Ada，在 MySQL 中 %da% 就扫全表了，但对 ES 来说能快速定位
2.3.2 精确检索该情况其实相差是不大的，即使 Term Index 的优势没了，却还要借此找到在 term dictionary 中的位置。也许由于 MySQL 全面覆盖检索无须无法正常进行会更快一点。
2.4 甚么时候用 ES
如前所述，对业务中的查阅情景甚么时候适合采用 ES ？我觉得有两种。
2.4.1 全文检索在 MySQL 中数组类型根据关键字模糊查阅是一场灾难，对 ES 来说却是小菜一碟。具体情景，比如消息表对消息内容的模糊查阅，即聊天历史记录查阅。
但要注意，假如需要的是类似广大搜检索擎的关键字查阅而非日志的短语相匹配查阅，就需要对中文进行分词处理，最广泛采用的是 ik 。Ik 分词器的安装这里不再细说。
甚么意思呢？
分词结尾对日志的查阅，键入 “我可真是个机灵鬼” 时，只会得到完全相匹配的信息。
而倘若去掉 “”，又会得到按照 “我”、“可”，“真”…. 分词相匹配到的所有信息，这明显会返回很多信息，也是不符合中文语义的。前述期望的分词效果大概是 “我”、“可”、“真是”，“机灵鬼”，之后再按照此种分词结果去相匹配查阅。
这是 ES 默认的分词策略对中文的支持不友善引致的，按照英语单词字母来了，可英语单词间是带有空格的。这也是不少国外软件中文搜索效果不 nice 的其原因之一。
对该难题，你能在 console 采用下方命令，测试当前 index 的分词效果。
假如信息量够大，表表头又够多。把所有表头信息丢到 ES 里建立检索是片面的。采用 MySQL 的话那就只能按前文提到的分库分表、读写分离来了。何不女团下。
1. ES + MySQL将要参与查阅的表头信息加上 id，放入 ES，做好分词。将全量信息放入 MySQL，通过 id 快速检索。
2. ES + HBASE假如要省去分库分表甚么的，或许能抛弃 MySQL ，选择分布式数据库，比如 HBASE , 对此种 NOSQL 来说，存储能力海量，扩容 easy ，根据 rowkey 查阅也很快。
以上思路都是经典的检索与数据存储隔离的方案了。
当然，摊子越大越容易出事，也会面临更多的难题。采用 ES 作检索层，数据同步、时序性、mapping 设计、高需用等都需要考虑。
毕竟和单纯做日志系统对比，日志能等待，用户不能。
2.5 小结
本节简单介绍了 ES 为啥快，和那个快能用在哪。现在你能打开 Kibana 的控制台试一试了。
假如想在 Java 项目中接入的话，有 SpringBoot 加持，在 ES 环境 OK 的前提下，完全是开箱即用，就差一个依赖了。基本的 CRUD 支持都是完全 OK 的。
3.HBASE
前面有提到 HBASE , 甚么是 HBASE ，鉴于篇幅这里简单说说。
3.1 存储结构关系型数据库如 MySQL 是按行来的。
HBASE 是按列的（前述是列族）。列式存储上表就会变成：
下图是一个 HBASE 前述的表模型结构。
Row key 是主键，按照字典序排序。TimeStamp 是版本号。info 和 area 都是列簇（column Family），列簇将表进行横向切割。name、age 叫做列，属于某一个列簇，可进行动态添加。Cell 是具体的 Value 。
3.2 OLTP 和 OLAP数据处理大致可分成两大类：联机事务处理 OLTP（on-line transaction processing）、联机分析处理 OLAP（On-Line Analytical Processing）。
OLTP 是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理。OLAP 是数据仓库系统的主要应用，支持复杂分析，侧重决策支持，提供直观易懂的查阅结果。面向列的适合做 OLAP，面向行的适用于联机事务处理 (OLTP)。不过 HBASE 并并非 OLAP ，他没有 transaction，前述上也是面向 CF 的。一般也没多少人用 HBASE 做 OLAP 。
3.3 RowKeyHBASE 表设计的好不好，就看 RowKey 设计。这是即使 HBASE 只支持三种查阅方式
1、如前所述 Rowkey 的单行查阅 2、如前所述 Rowkey 的范围扫描 3、全表扫描
可见 HBASE 并不支持复杂查阅。
3.4 采用情景HBASE 并非适用于实时快速查阅。它更适合写密集型情景，它拥用快速写入能力，而查阅对单条或小面积查阅是 OK 的，当然也只能根据 rowkey。但它的操控性和可靠性非常高，不存在单点故障。
4.总结
个人觉得软件开发是循序渐进的，技术服务于项目，合适比新颖复杂更重要。
如何完成一次快速的查阅？最该做的还是先找找自己的 Bug，解决了当前难题再创造新难题。
本文列举到的部分方案对具体实现大多一笔带过，前述无论是 MySQL 的分表还是 ES 的业务融合都会面临很多细节和困难的难题，搞工程的总要绝知此事要躬行。
