在这篇博文里，我们准备来看一下 ProxySQL 是如何提高 MySQL 的 SSL 连接性能的。

本文会介绍 数据库索引设计与优化 中设计索引的一些方法，让各位读者能够快速的在现有的工程中设计出合适的索引。

分库分表中有一个最为常见的场景，为了提升数据库的查询能力，我们都会对数据库做分库分表操作。比如订单库，开始的时候我们是按照订单ID维度去分库分表，那么后来的业务需求想按照商家维度去查询，比如我想查询某一个商家下的所有订单，就非常麻烦。这个时候通过数据异构就能很好的解决此问题。

MySQL 8.0.3 即将发布，一起看看有什么新变化吧 MySQL 8.0.3 即将发布 RC 版本，这预示着 8.0 版本离 GA 越来越近了。

限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务。

公司开发人员在更新数据时使用了 replace into 语句，由于使用不当导致了数据的大量丢失，到底是如何导致的数据丢失？

近因业务需要，研究了一下树数据结果的存储及查询解决方案。 最初的想法是使用neo4j，可是在网上看了一下开源的不支持集群，感觉用的人不多。网上也查了一些树形结构数据存储方案但每种实现方案都有它的一定局限性。想了一短时间后，想出了下面的方案。

前面的一篇文章介绍了左右值编码，不知道大家注意到了没有，如果数据庞大，每次更新都需要更新差不多全表，效率较低没有更好的方式？今天我们就来研究下区间嵌套法。

在基于数据库的一般应用中，查询的需求总要大于删除和修改。为了避免对于树形结构查询时的“递归”过程，基于Tree的前序遍历设计一种全新的无递归查询、无限分组的左右值编码方案，来保存该树的数据。

将 Closure Table 翻译成闭包表不知道是否合适，闭包表的思路和物化路径差不多，都是空间换时间，Closure Table，一种更为彻底的全路径结构，分别记录路径上相关结点的全展开形式。

前一篇文章介绍了比较简单的邻接列表模式，物化路径其实更加容易理解，其实就是在创建节点时，将节点的完整路径进行记录。

在程序开发中，我们常遇到用树型结构来表示某些数据间的关系，如企业的组织架构、商品的分类、操作栏目等，目前的关系型数据库都是以二维表的形式记录存储数据，而树型结构的数据如需存入二维表就必须进行Schema设计。最近对此方面比较感兴趣，专门做下梳理。其中最简单的方法是：Adjacency List（邻接列表模式）。

本文主要讲述了在Nginx环境中跨域请求使用时发现的问题和注意的事项。

对于海量的各种非结构化信息来说，图数据库已经成为帮助收集、管理和搜索大量数据的技术。在本文中，我将向你展示图数据库的基础知识，帮助你快速了解概念模型。

最近线上 MySQL 接连发生了几起数据异常，都是在凌晨爆发，由于业务场景属于典型的数据仓库型应用，白天压力较小无法复现。甚至有些异常还比较诡异，最后 root cause 分析颇费周折。那实际业务当中咱们如何能快速的定位线上 MySQL 问题，修复异常呢？下文我会根据两个实际 case，分享下相关的经验与方法。

良好的逻辑设计和物理设计是高性能的基石， 应该根据系统将要执行的查询语句来设计schema, 这往往需要权衡各种因素。

Redis有着更为复杂的数据结构并且提供对他们的原子性操作，这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明，无需进行额外的抽象。

MySQL EXPLAIN命令是查询性能优化不可缺少的一部分，该文主要讲解explain命令的使用及相关参数说明。 EXPLAIN Output Columns id id是用来顺序标识整个查询中SELELCT 语句的，在嵌套查询中id越大的语句越先执行。该值可能为NULL，如果这一行用来说明的是其他行的联合结果。 select_type 表示查询的类型 table 对应行正在访问哪一个表，…

对于普通的以数据块/文件为单位的压缩，传统的（流式）数据压缩算法工作得不错，时间长了，大家也都习惯了这种数据压缩的模式。

作为一种数据存储层面上的水平伸缩解决方案，数据库Sharding技术由来已久，很多海量数据系统在其发展演进的历程中都曾经历过分库分表的Sharding改造阶段。