一、历史数据库 MySQL 数据库可以很好地支撑海量的 OLTP（Online Transaction Processing）的系统，但是对于海量的互联网业务来说，数据量是非常巨大的。 假设一天 10 亿笔交易，每笔交易至少需要有一条记录，用于记录该笔交易，这就是通常所谓的流水数据。再假设一笔流水占用 1K 存储空间，那么每日流水占用存储空间 1000G，365 天就需要占用 365T 的存储空间
引起 MySQL 数据库性能抖动的原因有很多，比如大事务、定时批量查询等，而这些原因我们一般都会注意到。但是，有一个引起性能抖动的原因却经常被我们忽视，那就是在生产环境删除无用的大表，即 DROP TABLE。 一、为什么要 DROP TABLE？ 生产环境中，为什么要 DROP TABLE？相信绝大部分原因是为了释放空间。 生产环境大多数是已经确定的库表，一般不会进行 DROP TABLE 这么
前面介绍了很多关于分布式数据库的一些知识点，但是，分布式数据库还有一个很令人头疼的问题，那就是分布式事务。本篇文章，我们就来看一下，如何在海量的互联网业务中实现分布式事务。 一、分布式事务是什么？ 事务的概念相信大家已经非常熟悉了，事务就是要满足 ACID 的特性，总结来说。 A（Atomicity） 原子性：事务内的操作，要么都做，要么都不做； C（Consistency） 一致性：事务
访问分布式数据库有两种模式： 业务直接根据分库分表访问 MySQL 数据库节点； 根据中间件访问。 一、分库分表直接访问 在设计分片时，我们已经明确了每张表的分片键信息，所以业务或服务可以直接根据分片键对应的数据库信息，直接访问底层的 MySQL 数据节点，比如在代码里可以做类似的处理： void InsertOrders(String orderKey, int userKey...
前面我们了解了分布式数据库的架构，知道各类分布式数据库都离不开计算层、存储层、元数据层这三层关系。另外，很重要的一点是，了解了分布式数据库是把数据打散存储在一个个分片中。在基于MySQL 的分布式数据库架构中，分片就存在于 MySQL 实例中。 本篇文章，我们就来了解一下，如何正确的把数据分片，充分发挥分布式数据库架构的优势。 一、如何确定分片键 在对表中的数据进行分片时，首先要选出一个分片键（S
现在互联网应用已经普及，数据量不断增大。对淘宝、美团、百度等互联网业务来说，传统单实例数据库很难支撑其性能和存储的要求，所以分布式架构得到了很大发展。而开发人员、项目经理，一定要认识到数据库技术正在经历一场较大的变革，及早掌握好分布式架构设计，帮助公司从古老的单实例架构迁移到分布式架构，对自己在职场的竞争力来说，大有益处。 一、什么是分布式数据库？ Wiki 官方对分布式数据库的定义为： A d
在高可用的三大架构设计（基于数据层的高可用、基于业务层的高可用，以及融合的高可用架构设计）中。仅仅解决了业务连续性的问题：也就是当服务器因为各种原因，发生宕机，导致MySQL 数据库不可用之后，快速恢复业务。但对有状态的数据库服务来说，在一些核心业务系统中，比如电商、金融等，还要保证数据一致性。 这里的“数据一致性”是指在任何灾难场景下，一条数据都不允许丢失（一般也把这种数据复制方式叫作“强同步”
MySQL复制技术实现业务层读写分离方案，本质上就是为了打造数据库的高可用，因为复制是高可用的基础。但只用复制同步数据又远远不够，还要结合自己的业务进行高可用设计。 一、什么是高可用？ 高可用（High Availability）是系统所能提供无故障服务的一种能力。 简单地说就是避免因服务器宕机而造成的服务不可用。 我们都知道，高可用是每个业务系统设计时，开发人员必须考虑的关键点。比如你的系统在发
大家可能会发现，自己的主从复制会存在主从数据延迟的问题，甚至会导致读写分离，架构设计在业务层出现较为严重的问题，比如迟迟无法读取到主库已经插入的数据。但这可能并不是 MySQL 复制的问题，而是业务没有根据 MySQL 复制的特点进行设计。 本篇文章，我们就来看一下主从复制延迟的原因，以及如何避免这个令人头疼的问题。 一、逻辑日志的优缺点 MySQL 复制基于的二进制日志是一种逻辑日志，其写入的是
业务需要上线，除了表和索引的结构设计之外，还要做好高可用的设计。因为在真实的生产环境下，如果发生物理硬件故障，没有搭建高可用架构，会导致业务完全不可用。 而这在海量并发访问的互联网业务中完全不敢想象。所以除了业务架构，还要做好可用性的架构设计。 本篇文章，我们一起来看一下MySQL 高可用架构中最基础、最为核心的内容：**MySQL 复制（Replication）**。 一、MySQL复制架构 数
3.分区表是将物理表结构相同的表通过分区函数组成逻辑大表，MySQL支持多种分区函数类型。分区表设计时，主键必须包含分区列，且唯一索引需考虑分区列以实现全局唯一。分区表主要用于数据管理，而非性能提升，查询条件应包含分区字段以避免扫描所有分区。以电商订单表为例，按年创建分区表可方便数据删除和管理。
2.MySQL8.0前版本对子查询优化有限，但新版本中优化大幅提升，推荐使用。子查询逻辑清晰，符合人类思维，但优化器需将其转换为最优JOIN连接。IN和EXISTS性能差异需关注执行计划。依赖子查询可能慢，需警惕并手动优化。
前面我们了解了些单表SQL的索引设计及调优技巧。但在日常开发中，除了单表的SQL外，还有更为复杂的多表join查询和子查询语句。这就需要在多表中创建索引，难度也提升了不少。很多开发人员下意识地认为 JOIN 会降低 SQL 的性能效率，所以就将一条多表 SQL 拆成单表的一条条查询，但这样反而会影响 SQL 执行的效率。究其原因，在于开发人员不了解 JOIN 的实现过程。 下面，我们就来一起看一下
在实际工作中，大家可能会遇到这个问题：MySQL并没有按照自己的预想来选择索引，比如创建了索引但是选择了全表扫描，这肯定是 MySQL 数据库的 Bug，或者是索引出错了。真相真的是MySQL出错了吗？当然不是。主要是因为索引中的数据出了错。 为什么这么说呢？要理解这个问题，要理解 MySQL 数据库中的优化器是怎么执行的，然后才能明白为什么最终优化器没有选择我们预想的索引。 一、MySQL是如何
3.本文介绍了组合索引的概念、设计实战及三大优势。通过案例展示了如何避免额外排序和回表，提升SQL查询性能。组合索引可覆盖多个查询条件，实现索引覆盖技术，提升查询效率。文章将持续更新，欢迎关注。
InnoDB存储引擎是MySQL数据库中使用最为广泛的引擎。在海量大并发的 OLTP 业务中，InnoDB 必选。它在数据存储方面有一个非常大的特点：索引组织表（Index Organized Table）。 一、什么是索引组织表？ 数据存储有堆表和索引组织表两种方式。 堆表中的数据无序存放， 数据的排序完全依赖于索引（Oracle、Microsoft SQL Server、PostgreSQL
表结构设计，只是我们业务的第一步，要想发挥MySQL的性能优势，索引设计也是必不可少的。正确的索引设计，业务才能达到上线的初步标准。 一、索引是什么？ 相信大家在面试时，通常会被问到“什么是索引？”而你一定要能脱口而出：索引是提升查询速度的一种数据结构。 索引之所以能提升查询速度，在于它在插入时对数据进行了排序（显而易见，它的缺点是影响插入或者更新的性能）。 所以，索引是一门排序的艺术，有效地设计
MySQL支持多种访问方式，包括SQL和NoSQL。通过Memcached协议和XProtocol，可将MySQL打造成KV数据库或文档数据库，提升性能并满足复杂查询需求。MySQL在JSON支持、数据持久化、事务处理等方面优于原生Memcached，同时与MongoDB相比也具优势。
在MySQL数据库的使用中，对于字段类型设计大家可能都有一些思路和方式，但是针对存储方面的设计，在表结构设计之初可能就没考虑过，只有当业务发展到一定规模才意识到它所带来的问题严重性。而物理存储主要是考虑是否要启用表的压缩功能。默认情况下，所有表都是非压缩的。 一听到压缩，可能会下意识地认为压缩会导致 MySQL 数据库的性能下降。这个观点说对也不对，需要根据不同场景进行区分。 本篇文章，我们就来看
我们在对一张表进行设计时，还要遵守一些基本的原则，比如经常听见的“范式准则”。但范式准则过于理论，在真实业务中，不必严格遵守三范式的要求。而且有时为了性能考虑，还可以进行反范式的设计，比如在数据仓库领域。这篇文章我们来分享些表设计的一些经验。 一、忘记范式准则 相信在大学学习《数据库系统概论》时，肯定学习过关系数据库的设计规范，比如第一范式、第二范式、第三范式，BC 范式等，它们是《数据库系统概论
在MySQL数据类型中，还有一个我们常用的数据类型：字符串类型。在MySQL中，字符串类型有CHAR、VARCHAR、BINARY、BLOB、TEXT、ENUM、SET。不同的类型，在业务设计、数据库性能方面有完全不同的表现，其中我们使用最多的应该是CHAR、VARCHAR。本篇文章，我们就来一起看看CHAR和VARCHAR的应用。 一、CHAR和VARCHAR的定义 CHAR(N) 用来保存固定
MySQL数据库中的浮点类型和高精度类型有什么区别？为什么不推荐使用浮点类型？
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
