近日订单履约系统发生了一起故障，导致下发的订单积压。究其原因是慢查询导致的，现在痛定思痛看看为什么发生了慢查询。

介绍索引的数据结构、查找算法、常见的索引概念和索引失效场景。

腾讯机器学习平台太极后端数据库是自己运维的Mysql，历史原因没有用公司CDB、TDSQL等，之后还是要进行数据库迁移把db维护交给专业的人去运维，这块太极平台没有专门的dba运维出现了不少问题，如Mysql主节点硬盘故障，备机切主导致系统中断半小时；后端接口调用不合理导致循环调用数据库致使数据库cpu持续维持在高位以及前端接口数据返回缓慢等问题。这块Mysql优化就需要开发自己去多了解Mysql系统架构、性能调优相关问题，监控Mysql 机器运行状态，本文就简单介绍下Mysql系统分析思路和采用的工具。

Mysql 作为互联网中非常热门的数据库，其底层的存储引擎和数据检索引擎的设计非常重要，尤其是 Mysql 数据的存储形式以及索引的设计，决定了 Mysql 整体的数据检索性能。

我们知道，索引的作用是做数据的快速检索，而快速检索的实现的本质是数据结构。通过不同数据结构的选择，实现各种数据快速检索。在数据库中，高效的查找算法是非常重要的，因为数据库中存储了大量数据，一个高效的索引能节省巨大的时间。比如下面这个数据表，如果 Mysql 没有实现索引算法，那么查找 id=7 这个数据，那么只能采取暴力顺序遍历查找，找到 id=7 这个数据需要比较 7 次，如果这个表存储的是 1000W 个数据，查找 id=1000W 这个数据那就要比较 1000W 次，这种速度是不能接受的。

数据库与普通文件系统的一个重要的区别就是；数据库可以在多种故障下仍然可以正确运行，保证系统以及数据的正确性；这些故障包括但不限于数据库系统本身故障，操作系统故障，以及存储介质故障等。那么数据库是如何在这些故障下面还能保证系统和数据的正确性的呢？主要靠Redo Log和Undo Log日志与WAL(Write Ahead Log)机制的配合来支持，其理论支持在论文《ARIES: a transaction recovery method supporting fine-granularity locking and partial rollbacks using write-ahead logging》中介绍的非常详细。

金融企业在生产安全的前提下，如何确保MySQL的开发合规和性能管控？

通过本文这个案例你会发现整个数据库体系还有很多内容值得去学习，试想一下，如果平时对主从复制的原理比较熟的话，问题排查起来也会简单很多。

如何打造一个稳定、高效的Mysql Binlog实时接入服务。

客户发现一个非预期内的锁等待现象，用户贼郁闷，隔离级别用的是 RC，两个session又都只更新一条数据，并且更新的还是两条不一样的数据，按理来说没有冲突，不应该造成阻塞。

InnoDB 存储引擎中所有可变长度类型的字段（如 VARCHAR、VARBINARY、BLOB 和 TEXT）可以存储在主键记录内，也可以存储在主键记录之外的单独 BLOB 页中（在同一表空间内）。所有这些字段都可以归类为大对象。这些大对象要么是二进制大对象，要么是字符大对象。二进制大对象没有关联的字符集，而字符大对象有。在 InnoDB 存储引擎中，字符大对象和二进制大对象的处理方式没有区别，我们使用“BLOB”来指代上述的大对象字段。BLOB不同大小，不同场景，可以全部存储在主键，部分前缀存储在主键，或者全部存储在外部BLOB页中，本篇文章主要集中在BLOB全部存储在外部BLOB页中时，在innodb中是如何实现的，其他的在主键内部或者前缀在主键内部不再展开说明。只有主键可以在外部存储 BLOB 字段，二级索引不能有外部存储的字段，本文的讨论都是围绕着主键展开。

无论从使用、研发还是运维的角度，内存监控一直是MySQL的重点之一。完善的内存监控手段有很多作用。

用 go-mysql-elasticsearch 实现数据同步的本地化实践。

对于一个服务端开发来说 MYSQL 可能是他使用最熟悉的数据库工具，然而，大部分的Java工程师对MySQL的了解和掌握程度，大致就停留在这么一个阶段:它可以建库、建表、建索引，然后就是对里面的数据进行增删改查，语句性能有点差？没关系，在表里建几个索引或者调整一下查询逻辑就可以了，一条sql，MYSQL是如何处理的，为我们做了什么，完全是个黑盒。本文主要通过sql执行的过程打破这样一个黑盒的认知，来了解MYSQL的逻辑架构。

分享有关悬挂事物的相关知识及一例生产环境中的关于悬挂事务的案例。

MySQL等值查询，可能并不是你想的那么简单，还跟校对规则有对，具体细节且听本文娓娓道来。

Uber uses MySQL as the underlying database engine for Schemaless and Docstore, our distributed databases. By default, MySQL uses the most popular InnoDB engine, a B+Tree structure for data storage. MyRocks is a MySQL storage engine that integrates with RocksDB, an open source project. The RocksDB store is based on the log-structured merge-tree (or LSM tree) and is optimized for fast storage and combines outstanding space and write efficiency with acceptable read performance.

The Uber Storage Platform team has migrated all Schemaless instances and some Docstore instances to MyRocks since 2019. In this post, we are going to talk about the journey of our migration to MyRocks.