优化 SQL 查询：如何写出高性能SQL语句——15 篇值得回顾的技术热文
（点击上方公众号，可快速关注）
本文精选了「数据库开发」在 2017 年 7 月的 15 篇热门文章。其中有技术分享、业界资讯。
注：以下文章，点击标题即可阅读
执行计划是数据库根据SQL语句和相关表的统计信息作出的一个查询方案，这个方案是由查询优化器自动分析产生的，比如一条SQL语句如果用来从一个 10万条记录的表中查1条记录，那查询优化器会选择“索引查找”方式，如果该表进行了归档，当前只剩下5000条记录了，那查询优化器就会改变方案，采用 “全表扫描”方式。
《Redis 核心概念（上）》+ 《Redis 核心概念（下）》
Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上，从而缓解单一数据库的性能问题。不太严格的讲，对于海量数据的数据库，如果是因为表多而数据多，这时候适合使用垂直切分，即把关系紧密（比如同一模块）的表切分出来放在一个server上。
对数据库进行分库分表(Sharding化)前，需要开发人员充分了解系统业务逻辑和数据库schema.一个好的建议是绘制一张数据库ER图或领域模型图，以这类图为基础划分shard,直观易行，可以确保开发人员始终保持清醒思路。
本文将主要介绍一些常见的全局主键生成策略，然后重点介绍flickr使用的一种非常优秀的全局主键生成方案。
《DB 分库分表（3）：关于使用框架还是自主开发以及 sharding 实现层面的考量》
当团队对系统业务和数据库进行了细致的梳理，确定了切分方案后，接下来的问题就是如何去实现切分方案了，目前在sharding方面有不少的开源框架和产品可供参考，同时很多团队也会选择自主开发实现，而不管是选择框架还是自主开发，都会面临一个在哪一层上实现sharding逻辑的问题，本文会对这一系列的问题逐一进行分析和考量。
系统经sharding改造之后，原来单一的数据库会演变成多个数据库，如何确保多数据源同时操作的原子性和一致性是不得不考虑的一个问题。总体上看，目前对于一个分布式系统的事务处理有三种方式：分布式事务、基于Best Efforts 1PC模式的事务以及事务补偿机制。我们下面对这三种处理方式一一进行分析。
《DB 分库分表（5）：一种支持自由规划无须数据迁移和修改路由代码的 Sharding 扩容方案》
本文将重点围绕“数据库扩容”进行深入讨论，并提出一种允许自由规划并能避免数据迁移和修改路由代码的Sharding扩容方案。
《Facebook 这类网站如何处理数十亿请求并保持高可用性的？》
Facebook 这类网站如何处理数十亿请求并保持高可用性呢，答案是负载均衡，本文将对其一探究竟。
我们公司有个面向服务的架构。其中一个服务是字体服务，字体体系和 unicode 编码范围（unicode range）提供字体数据，为用户上传的字体验证权限。我们没想到这个字体服务会有很高的负载1（负载是指线程消耗和 CPU 等待的平均值）。但是去年我们注意到字体服务出人意料地出现高负载，尤其是晚上我们没什么流量的时候。幸运的是，我们发现了这一问题的根本原因，并大幅提升了字体服务的性能和系统整体的稳定性。
索引是存储引擎用于快速查找记录的一种数据结构，通过合理的使用数据库索引可以大大提高系统的访问性能，接下来主要介绍在MySql数据库中索引类型，以及如何创建出更加合理且高效的索引技巧。
《7 月全球数据库排名发布：Oracle 扳回一局，MySQL 最受欢迎》
本月排名前 20 名中原本排在第 11 位的 Elasticsearch 取代 SQLite 成为第 10，其他数据库的排名均没有变化。SQLite 去年同月本位于排行榜第 9 名，截止现在已下降了两个名次。
《性能优化知多少》
最近一段时间，系统新版本要发布，在beta客户测试期间，暴露了很多问题，除了一些业务和异常问题外，其他都集中在性能上。有幸接触到这些性能调优的机会，当然要总结了。
MySQL EXPLAIN命令是查询性能优化不可缺少的一部分，本文主要讲解explain命令的使用及相关参数说明。
分布式要解决什么问题呢？解决持久化数据太大，单个节点的硬盘无法存储的问题；解决运算量太大，单个节点的内存、CPU无法处理的问题。解决这些问题，有两种思路：scale up，scale out。
看完本文有收获？请转发分享给更多人
关注「数据库开发」，提升 DB 技能
相关内容
微信扫码咨询专知VIP会员