京东科技开发者

物流的分拣业务在某些分拣场地只有一个数据源，因为数据量比较大，将所有数据存在一张表内查询速度慢，也为了做不同设备数据的分库管理，便在这个数据源内创建了多个不同库名但表完全相同的数据库，如下图所示：现在需要上线报表服务来查询所有数据库中的数据进行统计，那么现在的问题来了，该如何。

将以上的索引数据映射成常见的用户表user的索引为例,上面的聚簇索引就是以id字段为主键的索引,name字段为非聚簇索引，还有age等其他表字段是非索引字段，示例sql：select * from user where id = 1;这条 SQL 语句就不需要回表。原因是根据主键的查询方式，则只需要搜索 id聚簇索引这棵 B+ 树，就可以查到对应的数据。但当我们使用非聚簇索引 name 这个索引来查询 name = b 的记录时就要用到回表。

教员常说我们总是被经验主意和投机主义左右我们的思想，破局这一问题的根本解决方式是只有实事求是，实践是真理的标准。

作为开发人员，碰到了执行时间较长的sql时，基本上大家都会说”加个索引吧”。但是索引是什么东西，索引有哪些特性，下面和大家简单讨论一下。

’，是会使用索引的；默认新增SQL有事务控制，导致每条都需要事务开启和事务提交，而批量处理是一次事务开启和提交，效率提升明显，达到一定量级，效果显著，平时看不出来。应尽量避免在 WHERE 子句中对字段进行 NULL 值判断，创建表时 NULL 是默认值，但大多数时候应该使用 NOT NULL，或者使用一个特殊的值，如 0，-1 作为默认值。否则考虑单字段索引；查询缓冲并不自动处理空格，因此，在写 SQL 语句时，应尽量减少空格的使用，尤其是在 SQL 首和尾的空格（因为查询缓冲并不自动截取首尾空格）。

在我们应用中的使用场景来看，简单来说通常会看中了clickhouse在处理大批量数据的写入和读取分析方面的性能，MySQL会主要负责一些基于模型进行指标二次加工的高频查询及复杂join的查询。

熟悉代价模型之后，我们可以预先了解 MySQL 在执行查询时会如何选择索引，从而更有效地进行索引优化。在接下来的文章中，我将结合近期进行索引优化的具体案例，来详细解释如何运用代价模型来优化索引。

ReentrantLock（可重入锁），指的是一个线程再次对已持有的锁保护的临界资源时，重入请求将会成功。：如果被请求的共享资源空闲，那么就当前请求资源的线程设置为有效的工作线程，将共享资源通过CAS设置为锁定状态；如果共享资源被占用，就采用一定的阻塞等待唤醒机制（CLH变体的FIFO双端队列）来保证锁分配。：无论是公平锁还是非公平锁的情况，加锁过程会利用一个state值。

EXPLAIN 语句来能够查看某个查询语句的具体执行计划，要搞懂 EPLATN 的各个输出项都有什么作用，从而可以有针对性的提升查询语句的性能。

从上边的描述中可以看出来，所谓的 MVCC（Multi-Version Concurrency Control ，多版本并发控制）指的就是在使用 READ COMMITTD、REPEATABLE READ 这两种隔离级别的事务在执行普通的 SELECT 操作时访问记录的版本链的过程，这样子可以使不同事务的读写、写读操作并发执行，从而提升系统性能。

阅读 h2 数据库的源码是一项复杂的任务，需要对数据库原理、Java 语言和操作系统有深入的理解。可以从以下几方面入手来完成。

在讲述分布式事务的概念之前，我们先来回顾下事务相关的一些概念。

线上经常偶发死锁问题，当时处理一张表，也没有联表处理，但是有两个mq入口，并且消息体存在一样的情况，频率还不是很低，这么一个背景，我非常容易怀疑到，两个消息同时近到这一个事务里面导致的，但是是偶发的，又模拟不出来什么场景会导致死锁，只能进行代码分析，问题还原的方式去排查问题。业务代码简化成下面也就是说先update ，select ， insert 这么一个顺序表中存在dm_code ,erp 唯一索引。

在预发环境中，由消息驱动最终触发执行事务来写库存，但是导致MySQL发生死锁，写库存失败。初步排查，在同一时刻有两条请求进行写库存的操作。时间前后相差1s，但最终执行结果是，这两个事务相互死锁，均失败。stock_idsku_idstore_id所使用的数据库引擎为Innodb，隔离级别为RR[Repeatable Read]可重复读。

为了标识一段数据，通常我们会为其指定一个唯一id，比如利用MySQL数据库中的自增主键。但是当数据量非常大时，仅靠数据库的自增主键是远远不够的，并且对于分布式数据库只依赖MySQL的自增id无法满足全局唯一的需求。因此，产生了多种解决方案，如UUID，SnowFlake等。下文将介绍Vitess是如何解决这个问题的。

M3E（Moka Massive Mixed Embedding）是一个开源的中文嵌入模型，具有以下优势：多模态支持：M3E模型能够同时处理多种模态的数据，如文本、图像、语音等。这种多模态的支持使得模型能够更好地处理复杂的现实场景，提供更全面的语义理解。多任务学习：M3E模型支持同时学习多个任务，而不需要针对每个任务单独训练一个模型。通过共享模型的参数和特征表示，M3E能够将不同任务之间的知识相互传递和共享，提高学习效率和泛化能力。

我们平常所说的ELK指的就是Elasticsearch、Logstash和Kibana，这三个技术的组合是大数据领域中一个很巧妙的设计，是一种很典型的MVC思想，模型持久层，视图层和控制层。Logstash担任控制层的角色，负责搜集和过滤数据。Elasticsearch担任数据持久层的角色，负责储存数据，是一个实时的分布式存储、搜索、分析的引擎，适用于所有类型的数据，包括文本、数字、地理空间、结构化和非结构化数据，相较于Mysql来说更善于百万数据量的检索。

为了保证系统稳定性，预防潜在慢SQL导致应急事故，发起慢SQL常态化备战专项，下文主要描述专项的实践及落地情况。

UUID现有的5种版本，是根据不同的使用场景划分的，而不是根据精度，所以Version5并不会比Version1精度高，在精度上。

在之前的文章中，我们介绍了弹性数据库连接失效的背景，并探讨了HikariCP、Druid连接池探活策略的相关内容。在本文中，我们将会继续探讨另一个线上常用的连接池——DBCP，并为您介绍如何在使用DBCP时实现最佳实践的弹性数据库连接池探活策略。

在上一篇文章中，我们介绍了弹性数据库连接失效的背景，并探讨了HikariCP连接池探活策略的相关内容。在本文中，我们将会继续探讨另一个线上常用的连接池——Druid，并为您介绍如何在使用Druid时实现最佳实践的弹性数据库连接池探活策略。

数据库连接建立是比较昂贵的操作（至少对于 OLTP），不仅要建立 TCP 连接外还需要进行连接鉴权操作，所以客户端通常会把数据库连接保存到连接池中进行复用。连接池维护到弹性数据库（JED）的长连接，弹性数据库默认不会主动关闭客户端连接（除非报错），但一般客户端到弹性数据库之间还会有负载均衡代理，它们通常为了节约连接资源会在连接空闲10分钟后主动清理连接，释放无用的连接资源。这就导致一些用户的连接池探活参数配置不当，进而拿到是已经失效的连接。

本文是基于redis缓存实现分布式锁，其中使用了setnx命令加锁，expire命令设置过期时间并lua脚本保证事务一致性。Java实现部分基于JIMDB提供的接口。

近接到了一个新需求，要求提供查询关注对象的粉丝列表接口功能。该功能的难点就是关注对象的粉丝数量过多，不少店铺的粉丝数量都是千万级别，并且有些大V粉丝数量能够达到上亿级别

本文从EXPLAIN分析SQL的执行计划开始，进行示例展示，并对输出结果进行解读，同时总结了EXPLAIN可产生额外的扩展信息以及EXPLAIN的估计查询性能，整篇文章基于MySQL 8.0编写，理论支持MySQL 5.0及更高版本。

在mysql未支持json数据类型时，我们通常使用varchar、blob或text的数据类型存储json字符串，对mysql来说，用户插入的数据只是序列化后的一个普通的字符串，不会对JSON文档本身的语法合法性做检查，文档的合法性需要用户自己保证。在使用时需要先将整个json对象从数据库读取出来，在内存中完成解析及相应的计算处理，这种方式增加了数据库的网络开销并降低处理效率。

有很多的服务器选项会影响这MySQL服务器的性能，比如内存中临时表的大小、排序缓冲区等。有些针对特定存储引擎（如InnoDB）的选项，也会对查询优化很有用。

工作中，常常需要将线上doris同步至集市。读取doris数据同读取常规mysql基本相同。如果数据行小于千万，比较简单的方式直接单节点连接、读取和存储。

ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。我们内部很多的报表、数据看板都基于它进行开发。今天为大家带来remote方式的ClickHouse数据表迁移的完整过程介绍，如有错误，还请各位大佬指正。

本文对 Clickhouse 架构原理、语法、性能特点做一定研究，同时将其与 mysql、elasticsearch、tidb 做横向对比，并重点分析与 mysql 的语法差异，为有 mysql 迁移 clickhouse 场景需求的技术预研及参考。

今天想聊一下分库分表，因为对于快速增长的业务来说，这个是无法回避的一环。之前我在做商城相关的SAAS系统，商品池是一个存储瓶颈，商品池数量会基于租户增长和运营变得指数级增长，短短几个月就能涨到几千万的数据，而运营半年后就可能过亿。而对于订单这种数据，也会跟着业务的成长，也会变得愈发巨大。

在Elasticsearch这样的分布式系统中执行类似SQL的join连接是代价是比较大的，然而，Elasticsearch却给我们提供了基于水平扩展的两种连接形式 。

今天我们官宣一件大事：京东云开启中国云市场的首次公开比价活动，承诺“买贵就赔”！

用最通俗易懂的话来说,数据倾斜无非就是大量的相同key被partition分配到一个分区里,造成了'一个人累死,其他人闲死'的情况,这种情况是我们不能接受的,这也违背了并行计算的初衷,首先一个节点要承受着巨大的压力,而其他节点计算完毕后要一直等待这个忙碌的节点,也拖累了整体的计算时间,可以说效率是十分低下的

测试环境这个话题对于开发和测试同学一定不陌生，大家几乎每天都会接触。但是说到对测试环境的印象，却鲜有好评，下面就主要给大家分享一次实际工作中的Mysql性能优化实践，与大家共勉~

最近在阅读《认知觉醒》这本书，里面有句话非常打动我：通过自己的语言，用最简单的话把一件事情讲清楚，最好让外行人也能听懂。希望借助今天这篇文章，能用大白话说清楚这个相对比较底层和复杂的MVCC机制

这篇主要描述了B端令牌系统应用数据分表解决业务数据量增大，且存在的数据倾斜问题，主要面向的场景是一对多数据倾斜问题

跳表可以达到和红黑树一样的时间复杂度 O(logN)，且实现简单，Redis 中的有序集合对象的底层数据结构就使用了跳表。本篇文章从调表的基础概念、节点、初始化、添加方法、搜索方法以及删除方法出发，介绍了调表的完整代码以及调表在redis中的应用。

传统的将数据集中存储至单一数据节点的解决方案，在性能和可用性方面已经难于满足海量数据的场景，系统最大的瓶颈在于单个节点读写性能，许多的资源受到单机的限制，例如连接数、网络IO、磁盘IO等，从而导致它的并发能力不高，对于高并发的要求不满足。

Redis 是当前最流行的 NoSQL数据库。Redis主要用来做缓存使用，在提高数据查询效率、保护数据库等方面起到了关键性的作用，很大程度上提高系统的性能。当然在使用过程中，也会出现一些异常情景，导致Redis失去缓存作用。