本文精选了数据库开发领域的热门文章，主要围绕关系型数据库MySQL和非关系型数据库NoSQL的讨论、SQL优化、数据库开发中的常见问题以及基于Redis的分布式锁的安全性等问题展开。
文章提及了NoSQL的出现让人们认为关系型数据库已进入死亡倒计时，但MySQL依然保持着领先地位。Oracle和MySQL虽然在数据库排名中仍然位居前列，但得分有所下跌。
文章介绍了行转列、列转行的问题，并通过案例解释了如何通过SQL语句进行优化。同时，还分享了一次有意思的SQL优化经历。
文章提到了基于Redis的分布式锁的安全性问题，介绍了Redis作者提出的Redlock算法以及与之相关的争论。
（点击上方公众号，可快速关注）
本文精选了 数据库开发 2017 年 5 月的 8 篇热门文章。其中有技术分享、业界资讯。
注：以下文章，点击标题即可阅读
《NoSQL 没毛病，为什么 MySQL 还是“王”？》
NoSQL 出现时，许多人认为关系型数据库已进入死亡倒计时，MySQL 将退出舞台。然而，在目前的各种数据库榜单中，MySQL 依然保持着领先地位。更令人惊讶的是，虽然甲骨文的受欢迎程度在不断下降，但 MySQL 保持着稳定。 为什么？
《DB-Engines 5 月数据库排名 Oracle、MySQL 暴跌》
Oracle、MySQL 和 Microsoft SQL Server 也依然稳居前三名。不过位列第一、二名的 Oracle 和 MySQL 本月似乎不太受待见，得分分别暴跌 47.68 分和 24.59 分，包揽了跌幅榜的冠、亚军。由于 Oracle 跌幅更大，目前两者仅相差 14.28 分。
《重温 SQL ——行转列，列转行》
行转列，列转行是我们在开发过程中经常碰到的问题。行转列一般通过CASE WHEN 语句来实现，也可以通过 SQL SERVER 的运算符PIVOT来实现。用传统的方法，比较好理解。层次清晰，而且比较习惯。 但是PIVOT 、UNPIVOT提供的语法比一系列复杂的SELECT…CASE 语句中所指定的语法更简单、更具可读性。下面我们通过几个简单的例子来介绍一下列转行、行转列问题。
《一次非常有意思的 SQL 优化经历》
执行时间：30248.271s
晕,为什么这么慢，先来查看下查询计划...
《也许 MySQL 适合 Uber，但它不一定适合你》
2016 年 8 月，Uber 发表了一篇名为《为什么 Uber 工程从 PostgreSQL 迁移到了 MySQL》的文章。我并没有立即阅读原文，因为我的内心深处告诉我应该做一些本地的改进。在如此做的过程中，我的邮箱塞满了问题，比如“难道 PostgreSQL 真的有这么差劲吗？”我知道 PostgreSQL 并没有如此差劲，因此这些邮件使我想知道，原文到底写了些什么鬼玩意。这是一篇企图理解 Uber 的文章。
《MySQL 的 20+ 条最佳实践》
数据库操作是当今 Web 应用程序中的主要瓶颈。 不仅是 DBA（数据库管理员）需要为各种性能问题操心，程序员为做出准确的结构化表，优化查询性能和编写更优代码，也要费尽心思。 在本文中，我列出了一些针对程序员的 MySQL 优化技术。
《一张优惠券引发的血案》
消失好久好久的小灰终于回归了。为啥消失这么久？被优惠券折腾惨了！一张小小的优惠券，涉及到不少的高并发知识。
《基于 Redis 的分布式锁到底安全吗（上）？》
《基于 Redis 的分布式锁到底安全吗（下）？》
大概在一年以前，关于Redis分布式锁的安全性问题，在分布式系统专家Martin Kleppmann和Redis的作者antirez之间就发生过一场争论。由于对这个问题一直以来比较关注，所以我前些日子仔细阅读了与这场争论相关的资料。这场争论的大概过程是这样的：为了规范各家对基于Redis的分布式锁的实现，Redis的作者提出了一个更安全的实现，叫做Redlock。有一天，Martin Kleppmann写了一篇blog，分析了Redlock在安全性上存在的一些问题。然后Redis的作者立即写了一篇blog来反驳Martin的分析。但Martin表示仍然坚持原来的观点。随后，这个问题在Twitter和Hacker News上引发了激烈的讨论，很多分布式系统的专家都参与其中。
看完本文有收获？请转发分享给更多人
关注「数据库开发」，提升 DB 技能
