本文核心介绍，为何业界会有这样的说法？—— “MySQL单表存储数据量最好别超过千万级别” 当然这里是有前提条件的，也是我们最常使用到的： InnoDB存储引擎； 使用的是默认索引数据结构

背景 采购系统（BIP）在经历多年演进后，系统整体复杂度和数据量俨然已经极具规模，本文着重讨论海量数据的治理 存储现状：工程端实时订单库采用MySQL 5.5集群，其中主库配置为32C/48G/600

本文介绍了当前DTS应用中，MySQL数据同步使用到的数据一致性校验工具，并对它的实现思路进行分享。

我们在大部分开发场景下，对持久层的建设基于单库单表其实就可以实现当前的产品需求。但是随着业务发展越来越久，数据量、请求量也在不断的增加，本文简述转转回收系统的持久层架构演进历程

转转的改表平台系统拥有，用户交互、添加唯一索引、支持分库分表、丰富的监控、拥有止血能力及部分自愈能力，支持定时改表、快速改表等

InnoDB存储引擎最早由Innobase Oy公司开发（属第三方存储引擎）。从MySQL 5.5版本开始作为表的默认存储引擎。该存储引擎是第一个完整支持ACID事务的MySQL存储引擎，特点是行锁设

本文针对 MySQL 数据库的 InnoDB 存储引擎，介绍其中索引的实现以及索引在慢 SQL 优化中的作用。本文主要讨论不同场景下索引生效与失效的原因。

数据库为了取得更好的读写性能，InnoDB 会将数据缓存在内存中（InnoDB Buffer Pool），对磁盘数据的修改也会落后于内存，这时如果进程或机器崩溃，会导致内存数据丢失，为了保证

作者介绍 陈力，2020年加入去哪儿网，有十余年互联网应用与游戏开发经验，目前专注于业务后台组件研发及业务系统的性能优化。