MySQL实战

一、历史数据库 MySQL 数据库可以很好地支撑海量的 OLTP（Online Transaction Processing）的系统，但是对于海量的互联网业务来说，数据量是非常巨大的。 假设一天 10

引起 MySQL 数据库性能抖动的原因有很多，比如大事务、定时批量查询等，而这些原因我们一般都会注意到。但是，有一个引起性能抖动的原因却经常被我们忽视，那就是在生产环境删除无用的大表，即 DROP T

前面介绍了很多关于分布式数据库的一些知识点，但是，分布式数据库还有一个很令人头疼的问题，那就是分布式事务。本篇文章，我们就来看一下，如何在海量的互联网业务中实现分布式事务。 一、分布式事务是什么？ 事

访问分布式数据库有两种模式： 业务直接根据分库分表访问 MySQL 数据库节点； 根据中间件访问。 一、分库分表直接访问 在设计分片时，我们已经明确了每张表的分片键信息，所以业务或服务可以直接根据分片

前面我们了解了分布式数据库的架构，知道各类分布式数据库都离不开计算层、存储层、元数据层这三层关系。另外，很重要的一点是，了解了分布式数据库是把数据打散存储在一个个分片中。在基于MySQL 的分布式数据

现在互联网应用已经普及，数据量不断增大。对淘宝、美团、百度等互联网业务来说，传统单实例数据库很难支撑其性能和存储的要求，所以分布式架构得到了很大发展。而开发人员、项目经理，一定要认识到数据库技术正在经

在高可用的三大架构设计（基于数据层的高可用、基于业务层的高可用，以及融合的高可用架构设计）中。仅仅解决了业务连续性的问题：也就是当服务器因为各种原因，发生宕机，导致MySQL 数据库不可用之后，快速恢

MySQL复制技术实现业务层读写分离方案，本质上就是为了打造数据库的高可用，因为复制是高可用的基础。但只用复制同步数据又远远不够，还要结合自己的业务进行高可用设计。 一、什么是高可用？ 高可用（Hig

大家可能会发现，自己的主从复制会存在主从数据延迟的问题，甚至会导致读写分离，架构设计在业务层出现较为严重的问题，比如迟迟无法读取到主库已经插入的数据。但这可能并不是 MySQL 复制的问题，而是业务没

业务需要上线，除了表和索引的结构设计之外，还要做好高可用的设计。因为在真实的生产环境下，如果发生物理硬件故障，没有搭建高可用架构，会导致业务完全不可用。 而这在海量并发访问的互联网业务中完全不敢想象。

一、分区表的使用 简单来说，分区表就是把物理表结构相同的几张表，通过一定算法，组成一张逻辑大表。这种算法叫“分区函数”，当前 MySQL 数据库支持的分区函数类型有 RANGE、LIST、HASH、K

除了多表连接之外，开发过程中还会大量用子查询语句（subquery）。但是因为之前版本的MySQL 数据库对子查询优化有限，所以很多 OLTP 业务场合下，我们都要求在线业务尽可能不用子查询。 然而，

前面我们了解了些单表SQL的索引设计及调优技巧。但在日常开发中，除了单表的SQL外，还有更为复杂的多表join查询和子查询语句。这就需要在多表中创建索引，难度也提升了不少。很多开发人员下意识地认为 J

在实际工作中，大家可能会遇到这个问题：MySQL并没有按照自己的预想来选择索引，比如创建了索引但是选择了全表扫描，这肯定是 MySQL 数据库的 Bug，或者是索引出错了。真相真的是MySQL出错了吗

通过前面几篇文章的介绍，大家应该都对MySQL中索引的创建和基本技巧有了大概的了解。在实际在实际业务中，我们会遇到很多复杂的场景，比如对多个列进行查询。这时，可能会要求用户创建多个列组成的索引，如列

InnoDB存储引擎是MySQL数据库中使用最为广泛的引擎。在海量大并发的 OLTP 业务中，InnoDB 必选。它在数据存储方面有一个非常大的特点：索引组织表（Index Organized Tab

表结构设计，只是我们业务的第一步，要想发挥MySQL的性能优势，索引设计也是必不可少的。正确的索引设计，业务才能达到上线的初步标准。 一、索引是什么？ 相信大家在面试时，通常会被问到“什么是索引？”而

在MySQL数据库的使用中，对于字段类型设计大家可能都有一些思路和方式，但是针对存储方面的设计，在表结构设计之初可能就没考虑过，只有当业务发展到一定规模才意识到它所带来的问题严重性。而物理存储主要是考

我们在对一张表进行设计时，还要遵守一些基本的原则，比如经常听见的“范式准则”。但范式准则过于理论，在真实业务中，不必严格遵守三范式的要求。而且有时为了性能考虑，还可以进行反范式的设计，比如在数据仓库领

在软件开发中，作为后端，无可避免的需要熟练使用 MySQL 数据库进行数据存储和读取。对于信息系统而言，数据库的的地位不言而喻。那作为软件开发工程师，在使用 MySQL 过程中，又有哪些需要注意的呢？