小工匠

MySQL高扩展性实战：从垂直扩展到水平分片 本文系统探讨了MySQL应对高并发场景的扩展策略。核心扩展方法论包括Shared Everything、Shared Disk和Shared Nothing三种架构模式。垂直扩展通过增强单机硬件（CPU/内存/存储）和引入缓存/队列来提升性能，但存在物理极限。水平扩展方案更适用于海量数据场景，包括主从复制实现读写分离、数据分片（垂直按业务拆分、水平按规则拆分）以及数据库中间件简化分片管理。文章还分析了表分区与分片的本质区别，并指出分片带来的跨库查询和扩容挑战。最

本文系统性地探讨了构建稳固可靠的MySQL运维体系的关键要素。首先提出应从服务器和MySQL两个维度建立全面的监控系统，推荐自研架构结合推送与拉取模式。其次分析了传统SQL人肉审核的痛点，介绍了自动化审核工具及其规则体系，包括语法检查、开发规范审核等。然后重点阐述了备份恢复策略，建议采用物理与逻辑备份相结合的方式，并设计了多级存储架构。最后指出应整合监控、审核、备份等功能，构建统一的MySQL自动化管理平台，以提升运维效率与安全性。通过这四个维度的体系建设，可有效保障MySQL数据库的高可用性与业务连续性。

本文系统探讨了MySQL高可用架构的设计与实践，从概念指标到具体解决方案。首先介绍了高可用性的核心概念（可用性、MTBF、MTTR）及计算公式。随后提出了提升MTBF的策略，包括规范操作流程、加强监控、定期巡检和优化慢查询。在降低MTTR方面，强调了避免单点设计、故障演练、高可用守护系统和自动化运维平台的重要性。最后分析了MySQL高可用架构的演进历程，从早期的MMM到MHA、MHA+Arksentinel，再到去哪儿网的QMHA架构，展示了高可用方案的持续优化过程。这些内容为构建稳定可靠的MySQL服务提

本文系统介绍了突破单库性能瓶颈的解决方案。随着业务增长，单库面临CPU、内存、磁盘等瓶颈问题。文章从四个维度提出优化方案：硬件方面建议选择高主频CPU、大内存和SSD存储；参数调优重点配置日志刷新策略和缓存大小；解析MySQL主从复制原理；最后探讨分库分表等架构设计。通过综合优化，可有效提升数据库性能，满足高并发场景需求。

MySQL锁机制是保证高并发环境下数据一致性的关键。本文深入分析了InnoDB存储引擎的锁实现，包括共享锁、排他锁、意向锁等类型，以及记录锁、间隙锁和Next-key锁三种算法。通过三个典型案例展示了主键更新锁等待、非唯一索引间隙锁和死锁场景，并提供了Java代码示例，演示如何在应用中通过事务隔离、锁顺序控制和死锁检测来优化并发性能。理解MySQL锁机制有助于开发者编写更高效的SQL语句，避免死锁问题，提升系统整体性能。

作为开发者，我们不仅需要了解这些机制的理论基础，更需要掌握如何在应用中正确使用它们。本文将深入剖析MySQL事务与锁机制的核心原理，并结合开发实践，提供可直接应用的解决方案。

MySQL架构与InnoDB存储引擎深度解析 本文系统介绍了MySQL的三层体系结构（连接层、Server层、存储引擎层）及其SQL执行流程。重点剖析了InnoDB存储引擎的核心架构，包括内存结构（Buffer Pool、Redo Log Buffer）和磁盘结构（表空间、日志文件）。通过对比InnoDB与MyISAM的关键特性，揭示了InnoDB作为默认引擎的优势：完整的ACID事务支持、行级锁、MVCC机制以及优异的并发性能。文章还深入分析了InnoDB的线程系统设计和工作原理，为数据库性能优化提供了理

但它依然不能解决某一个业务的数据大量膨胀的问题，一旦系统中的某一个业务库的数据量剧增，比如商品系统接入了一个大客户的供应链，对于商品数据的存储需求量暴增，在这个时候，就要把数据拆分到多个数据库和数据表中，也就是对数据做水平拆分。单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是水平扩展，所以结合业务的特性，就需要在 Range 的基础上引入“分片元数据”的概念：分片的规则记录在一张表里面，每次执行查询的时候，先去表里查一下要找的数据在哪个分片中。垂直拆分是根据数据的业务相关性进行拆分。

如果客户端将要执行的命令发送给集群中的一台服务器，那么这台服务器就会以日志的方式记录这条命令，然后将命令发送给集群内其他的服务，并记录在其他服务器的日志文件中，注意，只要保证各个服务器上的日志是相同的，并且各服务器都能以相同的顺序执行相同的命令的话，那么集群中的每个节点的执行结果也都会是一样的。，介于两者之间，事务线程不用等待所有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端。所以这种方式不是 MySQL 特有的。

假设有 A 和 B 两个事务，在并发情况下，事务 A 先开始读取商品数据表中的数据，然后再执行更新操作，如果此时事务 A 还没有提交更新操作，但恰好事务 B 开始，然后也需要读取商品数据，此时事务 B 查询得到的是刚才事务 A 更新后的数据。换句话说，事务 A 操作数据库时，事务 B 只能排队等待，因此性能也最低。循环等待：可以靠按序申请资源来预防，也就是所谓的资源有序分配原则，让资源的申请和使用有线性顺序，申请的时候可以先申请资源序号小的，再申请资源序号大的，这样的线性化操作就自然就不存在循环了。

优秀的索引设计需要平衡查询效率与写入性能。优先考虑最常用查询模式单表索引不超过5个联合索引字段数不超过3个定期审查索引使用情况通过理解B+Tree的底层原理，结合执行计划分析与实际业务场景，开发者可以构建出高效的数据访问方案。记住：没有最好的索引，只有最适合业务场景的索引设计。

文章目录PreCasePreMySQL - order by和 group by 优化初探CaseCREATE TABLE `user` ( `id` int(10) AUTO_INCREMENT, `user_id` int(10), `gf_phone` varchar(1000), `gf_name` varchar(100), PRIMARY KEY (`id`), KEY `user_id` (`user_id`)) ENGINE=InnoDB;

文章目录PreTIMESTAMPIP总结PreMySQL - 高效的设计MySQL库表设计指导思想和注意事项都梳理了一下，那来个小练习把TIMESTAMP我们使用 MySQL 内置的函数(FROM_UNIXTIME()，UNIX_TIMESTAMP())，可以将日期转化为数字，用 INT UNSIGNED 存储日期和时间示例时间 2020-08-17 22:22:22 与整数之间的转换，转化后数字是连续的，占用空间更小，并且可以使用索引提升查询性能。mysql> select U

文章目录范式与反范式范式第一范式第二范式第三范式第二范式 VS 第三范式设计符合 2NF 的表范式优缺点反范式范式与反范式范式范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。数据库的设计范式是数据库设计所需要满足的规范。目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式（4NF）和第五范式（5NF，又称完美范式）。满足最低要求的叫第一范式，简称 1NF。在第一范式基础上进一步满足一些要求

文章目录Pre锁的分类InnoDB 中的锁行锁InnoDB 行锁的三种算法实现表锁InnoDB 自增锁InnoDB 锁关系矩阵InnoDB 锁问题排查思路PreMySQL - 解读MySQL事务与锁机制MySQL - 共享锁和排它锁初探MySQL - 无索引行锁升级为表锁MySQL - 锁等待及死锁初探锁的分类在 MySQL 中有三种级别的锁：页级锁、表级锁、行级锁表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 会发生在：MyISAM、memor

文章目录Pre脏读不可重复读幻读SolutionsPreMySQL - 多版本控制 MVCC 机制初探中我们初步了解了 MVCC 的原理及其实现。 随着数据库并发事务处理能力的增强，数据库资源的利用率也会大大提高，从而提高了数据库系统的事务吞吐量，可以支持更多的用户并发访问。但并发事务处理也会带来一些问题，如：脏读、不可重复读、幻读等等脏读一个事务正在对一条记录做修改，在这个事务完成并提交前，这条记录的数据就处于不一致状态；这时，另一个事务也来读取同一条记录，如果不加控制，第二个事务读取了

文章目录MVCC原理快照读与当前读MVCC 多版本实现MVCC原理MySQL InnoDB 存储引擎，实现的是基于多版本的并发控制协议——MVCC，而不是基于锁的并发控制。MVCC 最大的好处是读不加锁，读写不冲突。在读多写少的 OLTP（On-Line Transaction Processing）应用中，读写不冲突是非常重要的，极大的提高了系统的并发性能。快照读与当前读在 MVCC 并发控制中，读操作可以分为两类: 快照读（Snapshot Read）与当前读 （Current Read）。

文章目录事务及其特性一致性原子性隔离性持久性并发事务控制单版本控制-锁多版本控制-MVCC原子性背后的技术持久性背后的技术隔离性背后的技术一致性背后的技术MVCC原理快照读与当前读MVCC 多版本实现事务及其特性大家都知道 ACID (原子性、一致性、隔离性和持久性)一个逻辑工作单元要成为事务，在关系型数据库管理系统中，必须满足 4 个特性原子性 : 事务的所有操作，要么全部完成，要么全部不完成，不会结束在某个中间环节一致性 : 事务开始之前和事务结束之后，数据库的完整性限制

文章目录数据库MySQL 数据库的体系结构数据库根据数据库的类型或者功能或者数据库的发展方向，可以把数据库大致分成两类关系型数据库非关系性数据库，或者叫 SQL 和 NoSQL当然了关系型数据库又可以分为传统的关系型数据库和 NewSQLMySQL 数据库的体系结构...

文章目录存储引擎概述存储引擎概述存储引擎是 MySQL 中具体与文件打交道的子系统，它是根据 MySQL AB 公司提供的文件访问层抽象接口定制的一种文件访问机制，这种机制就叫作存储引擎 。常用的存储引擎：有古老的 MyISAM、支持事务的 InnoDB、内存类型的 Memory、归档类型的 Archive、列式存储的 Infobright，以及一些新兴的存储引擎，以 RocksDB 为底层基础的 MyRocks 和 RocksDB，和以分形树索引组织存储的 TokuDB， 以及国产的分布式存储引

文章目录Demo Tablein的逻辑优化原则exists的逻辑Demo TableCREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_a` (`a`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;create table

mysql的表关联常见有两种算法Nested-Loop Join 算法Block Nested-Loop Join 算法

文章目录Table日常场景Table还是我们那个老表CREATE TABLE `employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名', `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄', `position` varchar(20) NOT NULL DEFAULT '' COMMENT

文章目录DB VersionTable案例一DB Versionmysql> select version();+-----------+| version() |+-----------+| 5.7.28 |+-----------+1 row in setmysql> TableCREATE TABLE `employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(24) N

文章目录Pre演示Demotrace工具使用Trace结论分析Pre有的时候，明明某个字段有索引，那我们一般认为走索引好一些，结果mysql走了全表扫描 ， 那怎么看mysql是怎么选择的呢？ 来 今天来看一看MySQL是如何循着合适的执行计划的？演示Demo还是那个老表 employeesCREATE TABLE `employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(24) NOT NULL DE

文章目录PreICP索引下推的含义范围查找为啥不行？PreMySQL - 索引优化案例实操 中 关于 【Case 3 : like KK% 一般情况都会走索引】 ，我们来详细聊一聊ICP我们说like KK% 一般情况下会走索引，这是为何呢？ 结合B+索引树， like KK% 能保证有序吗？其实MySQL对like KK% 这种情况使用到了索引下推优化 Index Condition Pushdown，ICP索引下推的含义CREATE TABLE `employe

文章目录DB VersionTableDB Versionmysql> select version();+------------+| version() |+------------+| 5.7.29-log |+------------+1 row in set默认隔离级别 RR 可重复读TableCREATE TABLE `employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar

文章目录共享锁 vs 排他锁SELECT ... FOR UPDATE 排它锁SELECT ... LOCK IN SHARE MODE 共享锁共享锁 vs 排他锁锁定某一行还可以用lock in share mode(共享锁) 和for update(排它锁)SELECT … FOR UPDATE 排它锁对所在行加上了一把排它锁 x锁【实验步骤】session1session2begin 模拟开启事务select * from countr

文章目录示例SELECT ... LOCK IN SHARE MODE & SELECT ... FOR UPDATE示例mysql> desc country;+-------------+--------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+-------------+---

版本信息mysql> select version();+-----------+| version() |+-----------+| 5.7.28 |+-----------+1 row in setmysql> MySQL 行锁分析mysql> show status like'innodb_row_lock%';+-------------------------------+--------+| Variable_name .

文章目录PreTable DemoPreMySQL - Explain深度剖析Table DemoCREATE TABLE `employees` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(24) NOT NULL DEFAULT '' COMMENT '姓名', `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄', `position` varchar(20) NOT

文章目录官方文档Explain介绍测试数据官方文档https://dev.mysql.com/doc/refman/5.7/en/explain-output.htmlExplain介绍使用EXPLAIN关键字可以模拟优化器执行SQL语句，分查询语句或是结构的性能瓶颈在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询会返回执行计划的信息，而不是执行这条SQL。如果 from 中包含子查询，仍会执行该子查询，将结果放入临时表中 。测试数据

文章目录PreMyISAM索引实现非聚簇（非聚集）索引索引原理图InnoDB索引实现聚簇（聚集）索引索引原理图为什么非主键索引结构叶子节点存储的是主键值？(一致性和节省存储空间)PreMySQL中，索引属于存储引擎级别的概念，不同存储引擎对索引的实现方式是不同的，我们这里主要讨论MyISAM和InnoDB两个存储引擎的索引实现方式。MyISAM索引实现非聚簇（非聚集）索引我们建立一个myIsam存储引擎的表，看磁盘上的文件存储如下我这个是8.0的MYSQL， 5.7版本 不是sdi结尾的文

文章目录PrePre什么是索引？通俗的说就是为了提高效率专门设计的一种 排好序的数据结构。怎么理解呢？举个例子哈如上数据 ，假设有个SQLselect * from t where col2 = 22 ;