最近有个需求，要修改现有存储结构，涉及查询条件和查询效率的考量，看了几篇索引和HBase相关的文章，回忆了相关知识，结合项目需求，说说自己的理解和总结。
前2篇介绍了索引的优点、索引结构的演化过程以及SQL的执行过程，重点分析了SQL的执行顺序和数据的定位过程，错过的朋友可以先回顾下：
这篇进入正题，介绍如何查看和分析SQL执行情况、排查SQL的性能问题，通过本篇介绍，你会了解到：
部分内容摘录了几个博友的文章，最后会给出文章链接，感谢他们的精彩分析。
工作中，MySQL会记录执行时间比较久的SQL语句，找出这些SQL语句是第一步，重要的是查看SQL语句的执行计划，对于MySQL执行计划的获取，可以通过explain方式来查看，这条命令的输出结果能够让我们了解MySQL优化器是如何执行SQL语句的。
MySQL优化器是基于开销来工作的，是在每条SQL语句执行的时候动态地计算出来的，命令用法十分简单, 在 SELECT 语句前加上 Explain 就可以了。
上一篇 提到，最近有个需求，要修改现有存储结构，涉及查询条件和查询效率的考量，看了几篇索引和HBase相关的文章，回忆了相关知识，结合项目需求，说说自己的理解和总结。
总体目录如下，上篇介绍了前3小节，分析了索引为什么快，总结了它的优点和分类，以及索引的演化过程，中篇会重点介绍索引分析方法和常见索引优化。
部分内容摘录了几个博友的文章，最后会给出文章链接，感谢他们的精彩分析。
通过中篇的介绍，你会了解到：
想要更好的优化查询，首先要了解其整体查询过程，从客户端发送查询请求，到接收到查询结果，MySQL服务器做了很多工作。
最近有个需求，要修改现有存储结构，涉及查询条件和查询效率的考量，看了几篇索引和HBase相关的文章，回忆了相关知识，结合项目需求，说说自己的理解和总结。
部分内容摘录了几个博友的文章，最后会给出文章链接，感谢他们的精彩分析。
会从以下几个方面介绍：
准备分3篇文章介绍，这篇主要介绍前3小节，理解我们常常说的MySQL索引，第2篇重点介绍索引分析方法和常见索引优化，第3篇介绍下业务中使用的HBase。
总体来说，索引是为了提高查询速度的，当数据量比较大时，从头到尾依次检索是无法接受的。另外，存储的数据会包含多个属性来描述业务实体，属性可以连续或分开存储，分别对应到MySQL和HBase。
以MySQL为例，学生这个实体有学号、姓名、性别、所属班级等属性，一般还有个主键ID，现在有个需求：查询学号为002的学生姓名。
数据是存储在磁盘上的，操作系统读取磁盘的最小单位是块，如果没有索引，会加载所有的数据到内存，依次进行检索，加载的总数据会很多，磁盘IO多。
如果有了索引，会以学号为key创建索引，MySQL采用B+树结构存储，一方面加载的数据只有学号和主键ID，另一方便采用了多叉平衡树，定位到指定学号会很快，根据关联的ID可以快速定位到对应行的数据，所以检索的速度会很快，因为加载的总数据很少，磁盘IO少。
可见，索引可以大大减少检索数据的范围、减少磁盘IO，使查询速度很快，因为磁盘IO是很慢的，是由它的硬件结构决定的。
下面，再详细介绍下磁盘存储结构和数据定位过程，加深对索引的理解。
程序员都很崇拜技术大神，很大一部分是因为他们发现和解决问题的能力，特别是线上出现紧急问题时，总是能够快速定位和解决。
一方面，他们有深厚的技术基础，对应用的技术知其所以然，另一方面，在采坑的过程中不断总结，积累了很多经验。
相信大家都使用过Spring，有些人了解它的核心：IOC和AOP，但只是了解它们的基本概念、使用了反射和动态代理，关于如何管理对象、代理的具体实现了解的比较浅。
有些人使用Spring MVC，使用Spring集成数据库、事务、消息队列以简化操作，但对集成的具体设计思路和实现了解的也比较浅。
我也这一块也比较菜，所以，后面的一段时间会梳理和总结Spring相关的技术原理，以「Spring技术内幕：深入解析Spring架构与设计原理」书籍为核心，结合自己的使用经验和疑问，以及网络上大牛的文章，来补足自己这方面的缺失。
这本书作者是计文柯，以Spring源代码为依托，从宏观上揭示了Spring的设计思路和架构思想，从微观上剖析了Spring各功能模块的实现原理和运行机制。一方面希望读者能通过深入了解Spring的底层机制来更好地解决实际开发中遇到的各种难题，另一方面是希望读者能吸收Spring设计和实现中的优秀方法和思想。
全书共三部分，分别阐述了Spring的核心、组件和应用。第一部分详细分析了IOC容器和AOP实现，第二部分阐述了基于Spring IOC容器和AOP的Java EE组件在Spring中的实现，第三部分讲述了一些基于Spring的典型应用的实现。
本篇先对设计理念和整体架构做个概述，从整体上看看Spring的设计目标和架构，通过本篇，你会了解到：
好几天没更新了，最近比较忙，也比较懒点，大家见谅。
接下来开始总结Spring系列，会以「深入解析Spring架构与设计原理」书籍为中心，结合自己的使用总结和经验，重点解惑Spring的设计目标和生态、Spring如何管理对象、如何实现与其他框架集成等。
昨天看了「码农翻身」公众号的2篇文章，主要介绍负载均衡原理的，一篇介绍负载均衡的2种实现方式：NAT、DR，一篇介绍负载均衡器的可用性，使用互为主备的方式既可以提高处理效率和机器利用率，又可以避免一台负载均衡器挂掉的影响。
本篇分享第一篇，说说负载均衡的原理，重点介绍其两种实现方式。
5.1假期第二天，依然窝在家里，不过今天来客了，我的好朋友「晓哥」来看小宝，中午喝了点，各自「吹嘘」了一阵，聊聊各自职业的发展，工作中遇到的问题，以及对未来的规划。
他现在发展的特别好，在一家近千人开发的公司，主管北京地区的业务，包括需求洽谈、研发、项目推进和验收等，公司业务是为多家银行做app端，和我分享了他在管理上的一些经验，真心为他高兴，祝越来越好。
话题一转，说说今天的主角：2个工具，一个是抓包工具Charles，一个是API调试工具Postman。前几天，尝试使用Charles抓取Websocket的消息，折腾了好久才成功，Postman也一样，安装了app版本，也遇到了一些问题，想把过程分享给需要的朋友。
本系列是「RabbitMQ实战：高效部署分布式消息队列」书籍的总结笔记。
本篇是「RabbitMQ实战」系列的最后一篇，主要介绍RabbitMQ插件，了解如何安装和启用它，列举一些常用的插件，以及如何自定义。
在介绍之前，先总结下本系列的主要内容，把它们串起来。
开篇时，这样定义过RabbitMQ：它是一个开源的消息代理和队列服务器，可以通过基本协议在完全不同的应用之间共享数据，可以将作业排队以便让分布式服务进行处理。
这句话有几个关键词：消息代理、队列服务器、共享数据、分布式处理，分别来说明下，以加深理解。
消息代理：可以把RabbitMQ看成一个代理服务器，一方面把消息生产者和消费者进行了解耦，更灵活；一方面，消息如何分发不用生产者考虑了，RabbitMQ提供多种分发策略。
队列服务器：消息最终是缓存在队列中的，消费者从指定的队列中消费消息，所以需要管理队列和队列中的消息。
共享数据：主要是说消息可以在不同应用间传输数据，通过AMQP协议进行规范，达到共享数据的目的。
分布式处理：多个消费者可以订阅同一个队列，这样，多台机器就可以同时处理同一批数据，达到分布式处理的效果。
4月25号，部门召开了一季度的总结会，部门老大最后的总结发言，有很多值得学习的地方，在此做个记录。
另外，上级领导也开始慢慢放权，让我负责更多系统的管理工作，感激的同时多了不少压力，于是想引以为鉴，时常警惕自己。
部门老大，大家都叫他「海大人」，小米刚成立时，就跟着雷总干，他是开发出身，一股工程师的气息，很敬业，思路清晰、敏捷。
最后总结发言用了30多分钟，尽力领会他想表达的，映射到自己。
总结的这些，都是我要为之努力的，我还只是一个小兵。
海大人很关注细节：会场两边的显示屏亮了（上一次不亮），每个项目组之间的PPT衔接更顺畅了，演讲的超时时间也少了，他对这次会议的准备提出了表扬。
工作上，细节也很重要，如果项目的分析、规划和执行不够细致，很容易延期，团队的协作也会很乱，上线后，项目的可用性和稳定性也不敢保证。
所以，做任何事情，都要细心，不放过任何一个细节，有些问题可以不解决，但也要了解，前期的细心分析和规划，会让执行更有章法和自信。
企业最终是要赚钱的，需求要不要做，系统是自研还是外采，都要考虑其产出比。
我们部门，很多项目都是服务于各个业务部门的，比如订单、仓库、物流、销售、客服等，海大人提出了要进行内部核算，和每个业务口核算成本，项目成本占他们营收的成本有多少。
所以，做项目、接需求时，要把价值说清楚，做好体验，让业务方满意，才能让对方认可你的成本。
本系列是「RabbitMQ实战：高效部署分布式消息队列」书籍的总结笔记。
前两篇介绍了RabbitMQ在可用性、监控方面的考虑，这是基础保障，因为在某些场景下是不容许丢失消息的，但它和性能往往是对立的，需要根据业务场景做取舍。
当处理一些敏感数据时，比如银行卡信息，需要考虑安全性问题，上一篇总结了数据传输安全方面的知识点，这里就比较好理解了。
通过介绍，你会了解到：
