你是不是也遇到过这样的场景想学数据库打开教程满屏都是“数据库是数据的仓库”、“SQL是结构化查询语言”这样的概念解释跟着操作几步就卡在环境配置上好不容易装好了写个简单查询都报错最后只能放弃或者你已经工作一两年日常CRUD没问题但一遇到复杂查询、性能优化、事务隔离这些稍微深入的问题就心里没底只能靠搜索引擎和“祖传代码”勉强应付如果你有这些困扰那么这篇文章就是为你准备的。这不是一篇泛泛而谈的“概念大全”而是一份从零环境搭建到核心原理实战的完整路径图。我将以MySQL为例但其中关于数据库设计、SQL编写、性能优化的思路适用于绝大多数关系型数据库。本文的核心判断是掌握数据库的关键不在于背诵命令而在于建立“存储-操作-优化”三位一体的系统性认知。很多人学了很久依然只会增删改查就是因为缺少这根主线。本文将围绕这条主线带你从安装一个纯净的MySQL环境开始一步步深入到索引、事务、锁、优化等核心领域并提供大量可立即上手的代码示例和排错指南。无论你是零基础的小白还是希望夯实基础的开发者读完本文你将能独立完成MySQL的安装配置、基础与高级SQL编写、数据库设计、并能对常见的性能问题有清晰的排查思路。我们开始吧。1. 这篇文章真正要解决的问题为什么你学数据库总是半途而废很多初学者甚至一些工作几年的开发者对数据库的认知停留在“一个存数据的地方”和“会写SELECT、INSERT就行”。这种认知导致了一系列典型问题环境劝退在Windows上安装MySQL被各种安装包、配置项、服务启动失败搞得晕头转向第一步就卡住。操作黑盒通过Navicat等图形化工具点点点完全不知道背后执行的SQL是什么一旦工具出问题就束手无策。性能玄学数据量稍大查询就变慢只知道“加索引”但为什么加、怎么加、加了为什么没效果一概不知。事务懵懂知道要用事务但隔离级别、脏读、幻读这些概念如同天书线上偶尔出现的数据不一致问题无从排查。设计随意建表凭感觉字段类型随便选缺乏范式理解和实际业务之间的权衡。本文将系统性地解决这些问题。我们不空谈理论而是通过“环境实操 - SQL核心 - 设计原理 - 高级特性 - 性能调优”这条路径让你在动手的过程中建立理解。你会知道每一步为什么这么做做错了怎么排查以及在生产环境中有哪些最佳实践。2. MySQL核心概念与定位它不仅仅是“一个数据库”在动手之前我们需要厘清几个基本但至关重要的概念这能帮你理解MySQL在整个技术栈中的位置。数据库 vs. 数据库管理系统 vs. SQL数据库简单理解就是一个按照特定结构组织、存储和管理数据的“仓库”或“集合”。数据库管理系统管理这个仓库的软件负责定义结构、存储数据、提供操作接口、保证安全与一致性。MySQL、PostgreSQL、Oracle都是DBMS。SQL用来与DBMS沟通的语言告诉它“存什么”、“取什么”、“怎么改”。MySQL的独特优势为什么是MySQL从网络热词中频繁出现的“mysql安装教程”、“navicat连接mysql”就能看出其普及度。它的核心优势在于开源与免费社区版功能强大无需付费拥有极其活跃的社区和丰富的资源。简单易用相比Oracle、DB2它的学习曲线相对平缓文档齐全。生态成熟与PHP、Java、Python等主流语言结合紧密有大量的ORM框架如MyBatis, Hibernate, SQLAlchemy和中间件如MyCat, ShardingSphere。性能可靠经过多年互联网大厂海量数据的锤炼在OLTP联机事务处理场景下非常稳定。与其他数据库的简单对比从热词“postgresql和mysql区别”、“sql server”、“oracle数据库”可以看出大家常做比较。vs PostgreSQL PostgreSQL更强调SQL标准的严格性和功能的先进性如对JSON、GIS的支持更原生更像“学院派”。MySQL在互联网领域应用更广复制、分片等方案更成熟。vs SQL Server SQL Server是微软全家桶的一部分与.NET体系深度集成在Windows生态下是首选。MySQL跨平台性更好。vs Oracle Oracle是功能最强大的商业数据库但极其昂贵和复杂常用于大型企业核心系统。MySQL是轻量、高效的开源选择。对于绝大多数Web应用、企业应用和初学者MySQL是平衡功能、性能、成本和易用性的最佳起点。3. 环境准备手把手搭建无坑的MySQL学习环境我们拒绝“下一步、下一步”的安装。这里以Windows平台为例Linux/macOS原理相通使用官方ZIP归档安装让你清楚每一个文件的作用。3.1 下载与版本选择不要去第三方网站下载直接访问MySQL官方社区版下载页面。版本选择上对于学习推荐使用MySQL 8.0的最新小版本如8.0.36。8.0是当前长期支持版本包含了窗口函数、通用表表达式等现代SQL特性性能和安全也有大幅提升。避免使用已停止维护的版本如5.55.6。3.2 安装与初始化手动模式假设你将MySQL解压到D:\mysql-8.0.36-winx64。步骤1创建配置文件在解压目录下创建my.ini文件。这是MySQL的配置文件决定了它的行为。[mysqld] # 设置3306端口 port3306 # 设置mysql的安装目录 basedirD:/mysql-8.0.36-winx64 # 设置mysql数据库的数据的存放目录 datadirD:/mysql-8.0.36-winx64/data # 允许最大连接数 max_connections200 # 允许连接失败的次数。这是为了防止有人从该主机试图攻击数据库系统 max_connect_errors10 # 服务端使用的字符集默认为UTF8 character-set-serverutf8mb4 # 创建新表时将使用的默认存储引擎 default-storage-engineINNODB # 默认使用“mysql_native_password”插件认证 default_authentication_pluginmysql_native_password [mysql] # 设置mysql客户端默认字符集 default-character-setutf8mb4 [client] # 设置mysql客户端连接服务端时默认使用的端口和字符集 port3306 default-character-setutf8mb4关键点utf8mb4才是真正的UTF-8支持存储所有emoji表情utf8在MySQL中是一个别名最大只支持3字节字符。datadir指定的data文件夹初始不存在下一步初始化时会自动创建。步骤2初始化数据目录以管理员身份打开命令行进入MySQL的bin目录。cd D:\mysql-8.0.36-winx64\bin执行初始化命令并记住输出的临时root密码在最后一行rootlocalhost:后面。mysqld --initialize --console这个命令会创建data目录并生成系统数据库如mysql, sys。步骤3安装MySQL服务mysqld --install MySQL如果显示“Service successfully installed.”表示服务安装成功。你可以在Windows服务列表里找到名为“MySQL”的服务。步骤4启动服务并修改密码net start MySQL服务启动后使用初始密码登录mysql -u root -p输入刚才记下的临时密码。登录成功后立即修改密码ALTER USER rootlocalhost IDENTIFIED BY 你的新密码; -- 例如ALTER USER rootlocalhost IDENTIFIED BY MyNewPass123!;安全提醒生产环境密码必须复杂且不要使用‘root’远程登录。3.3 验证安装修改密码后退出重新登录执行一些基本命令验证SHOW DATABASES; -- 显示所有数据库 SELECT VERSION(); -- 显示MySQL版本 STATUS; -- 显示状态信息如果都能正常执行恭喜你一个完全由你掌控的MySQL环境已经就绪。这种方式比安装包更透明出了问题也更容易排查。4. SQL核心从增删改查到理解集合操作很多教程把SQL命令孤立地讲。我将它们分为四个层次帮你建立结构化认知。4.1 第一层数据定义与操作DDL DML这是基础中的基础。DDL定义结构-- 1. 创建数据库并指定字符集 CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 2. 使用数据库 USE mydb; -- 3. 创建表用户表 CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT 用户ID主键自增, username VARCHAR(50) NOT NULL UNIQUE COMMENT 用户名唯一, email VARCHAR(100) NOT NULL COMMENT 邮箱, age TINYINT UNSIGNED COMMENT 年龄无符号小整数, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间 ) ENGINEInnoDB COMMENT用户表; -- 4. 修改表增加一个字段 ALTER TABLE user ADD COLUMN phone VARCHAR(20) COMMENT 手机号 AFTER email; -- 5. 创建索引非主键 CREATE INDEX idx_user_email ON user(email);设计思考为什么用INT做主键VARCHAR长度怎么定TIMESTAMP的两个默认值是什么意思InnoDB引擎是什么这些选择背后都有讲究我们会在设计章节详谈。DML操作数据-- 1. 插入数据 INSERT INTO user (username, email, age, phone) VALUES (张三, zhangsanexample.com, 25, 13800138000), (李四, lisiexample.com, 30, NULL); -- phone可以为NULL -- 2. 查询数据基础 SELECT id, username, email FROM user WHERE age 25; -- 3. 更新数据 UPDATE user SET age 26, updated_at NOW() WHERE username 张三; -- 重要UPDATE一定要带WHERE条件否则更新全表 -- 4. 删除数据 DELETE FROM user WHERE username 李四; -- 重要DELETE一定要带WHERE条件生产环境建议先用SELECT确认。4.2 第二层复杂查询与函数DQL进阶这是体现SQL能力的分水岭。多表连接假设我们还有一张订单表order。CREATE TABLE order ( order_id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL COMMENT 关联user.id, amount DECIMAL(10, 2) NOT NULL COMMENT 订单金额, status ENUM(pending, paid, shipped, completed) DEFAULT pending, order_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES user(id) ON DELETE CASCADE ); -- 插入一些订单数据 INSERT INTO order (user_id, amount, status) VALUES (1, 99.99, paid), (1, 199.99, completed), (2, 50.00, pending);连接查询-- INNER JOIN只返回两个表都匹配的行 SELECT u.username, o.order_id, o.amount, o.status FROM user u INNER JOIN order o ON u.id o.user_id; -- LEFT JOIN返回左表所有行即使右表没有匹配 SELECT u.username, o.order_id, o.amount FROM user u LEFT JOIN order o ON u.id o.user_id; -- 此查询会列出所有用户即使他没有订单订单信息为NULL聚合与分组-- 统计每个用户的订单总数和总金额 SELECT u.id, u.username, COUNT(o.order_id) AS order_count, SUM(o.amount) AS total_amount, AVG(o.amount) AS avg_amount FROM user u LEFT JOIN order o ON u.id o.user_id GROUP BY u.id, u.username HAVING total_amount 100; -- HAVING对分组后的结果进行过滤关键区别WHERE在分组前过滤行HAVING在分组后过滤组。4.3 第三层子查询与集合操作-- 子查询找出金额高于平均订单金额的订单 SELECT * FROM order WHERE amount (SELECT AVG(amount) FROM order); -- EXISTS查找有过订单的用户 SELECT * FROM user u WHERE EXISTS (SELECT 1 FROM order o WHERE o.user_id u.id); -- 集合操作UNION自动去重 SELECT username FROM user WHERE age 30 UNION SELECT username FROM user WHERE email LIKE %example.com;4.4 第四层窗口函数MySQL 8.0这是现代SQL的利器用于进行复杂的排名、累计计算而无需自连接或子查询。-- 为每个用户的订单按金额排名 SELECT order_id, user_id, amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY amount DESC) AS order_rank, SUM(amount) OVER (PARTITION BY user_id ORDER BY order_time) AS running_total FROM order;这个查询能一次性算出每个用户内部订单的金额排名以及按时间累计的消费总额非常强大。5. 数据库设计核心在范式与性能间找到平衡建表不是字段的堆砌。好的设计是高性能和易维护的基础。5.1 数据库三范式3NF精要第一范式原子性。每个字段都是不可再分的最小数据单元。例如“地址”字段不能存“北京市海淀区中关村”应该拆分成“省”、“市”、“区”、“详细地址”。第二范式消除部分依赖。针对联合主键所有非主键字段必须完全依赖于整个主键而不是部分主键。这通常意味着要把部分依赖的字段拆分到另一张表。第三范式消除传递依赖。任何非主键字段之间不能有依赖关系。例如在员工表里有了部门ID就不应该再有部门名称部门名称应该存在部门表里。反例分析-- 不符合范式的设计 CREATE TABLE bad_design ( order_id INT, product_id INT, product_name VARCHAR(100), -- 依赖于product_id而非order_idproduct_id这个整体违反2NF customer_name VARCHAR(50), customer_phone VARCHAR(20), -- 和customer_name一起只依赖于一个隐含的“客户”但未独立成表违反3NF PRIMARY KEY (order_id, product_id) );问题product_name重复存储更新困难客户信息冗余一致性难保证。5.2 实际项目中的权衡有时需要反范式化完全遵循范式可能导致大量多表关联影响查询性能。因此适度反范式化是常用技巧。冗余字段在order表中除了user_id再冗余一个username。这样查订单列表时就不需要关联user表。代价是更新用户名的成本变高需要同步更新所有相关订单。宽表在数据仓库或报表场景将多个维度信息冗余到一张大表里用空间换时间避免复杂连接。原则根据读写比例和一致性要求来决定。读多写少、对实时一致性要求不高的场景如用户画像、报表可以大胆冗余。写多读少、要求强一致性的核心交易表应尽量遵循范式。5.3 字段类型选择性能与空间的博弈整型TINYINT,SMALLINT,MEDIUMINT,INT,BIGINT。根据数据范围选择最小的节省空间。INT(11)中的11只是显示宽度不影响存储。字符型CHAR定长VARCHAR变长。存储短且长度固定的代码如国家代码CHAR(2)用CHAR效率更高。存储长度变化大的如用户名、地址用VARCHAR。VARCHAR长度不要过度放大如用VARCHAR(500)存用户名。时间类型DATE,TIME,DATETIME,TIMESTAMP。DATETIME范围大1000-9999年不带时区。TIMESTAMP范围小1970-2038年带时区转换存储的是UTC时间戳占用4字节DATETIME是8字节。推荐用TIMESTAMP记录行创建/更新时间如created_at用DATETIME记录业务时间如预约时间。JSON类型MySQL 5.7支持。适合存储结构灵活、无需复杂查询的附加属性。不要用它来替代核心的关系型设计。6. 索引深度解析为什么你的SQL还是慢理解了索引就理解了数据库性能的一半。6.1 索引的本质与数据结构索引就像书的目录。MySQL InnoDB引擎默认使用B树索引。它的特点叶子节点存储完整数据聚簇索引或主键值二级索引。所有叶子节点形成有序链表适合范围查询。树的高度低通常3-4层就能存储海量数据查询效率O(log n)。6.2 聚簇索引与二级索引聚簇索引叶子节点直接存储行数据。一张表只有一个聚簇索引。如果你定义了主键主键就是聚簇索引如果没有InnoDB会找一个唯一非空列还没有则隐式创建一个。二级索引叶子节点存储主键值。查询时先通过二级索引找到主键再通过主键回表到聚簇索引取数据。这就是“回表”。6.3 最左前缀原则联合索引的命门创建索引INDEX idx_name (a, b, c)。这个索引可以用于以下查询WHERE a 1 WHERE a 1 AND b 2 WHERE a 1 AND b 2 AND c 3 WHERE a 1 AND c 3 -- 只能用上ac用不上因为b断了但不能用于WHERE b 2 -- 跳过了a WHERE c 3 -- 跳过了a,b WHERE a 1 AND b 2 AND c 3 -- 范围查询b 2之后的列c无法使用索引设计技巧将区分度高不同值多且最常用的列放在联合索引最左边。6.4 索引失效的常见场景对索引列进行计算或函数操作WHERE YEAR(create_time) 2023失效应改为WHERE create_time 2023-01-01 AND create_time 2024-01-01。类型转换WHERE phone 13800138000phone是VARCHAR数据库会将所有行转换为数字比较索引失效。应确保类型一致。使用OR连接非索引列WHERE a 1 OR b 2如果b没索引可能导致全表扫描。LIKE以通配符开头WHERE name LIKE %张%索引失效。WHERE name LIKE 张%可以使用前缀索引。索引列上使用NOT、!、。6.5 使用EXPLAIN分析查询这是排查慢SQL的神器。在SQL前加上EXPLAIN。EXPLAIN SELECT * FROM user WHERE age 25 AND username LIKE 张%;关注几个关键列type访问类型。从好到坏systemconsteq_refrefrangeindexALL。至少要到range级别。key实际使用的索引。rows预估扫描的行数。越小越好。Extra额外信息。出现Using filesort文件排序或Using temporary使用临时表通常需要优化。7. 事务与锁保证数据一致性的基石这是数据库最核心也最复杂的部分之一。7.1 事务的ACID特性原子性事务内的操作要么全做要么全不做。靠Undo Log实现。一致性事务执行前后数据库从一个一致状态变为另一个一致状态。这是业务逻辑的目标。隔离性并发事务之间互不干扰。靠锁和MVCC实现。持久性事务提交后修改永久保存。靠Redo Log实现。7.2 事务隔离级别与并发问题SQL标准定义了四个级别MySQL InnoDB默认是可重复读。隔离级别脏读不可重复读幻读实现方式读未提交可能可能可能无锁读已提交不可能可能可能语句级快照可重复读不可能不可能可能但InnoDB通过MVCC避免了大部分事务级快照串行化不可能不可能不可能加锁脏读读到其他事务未提交的数据。不可重复读同一事务内两次读同一行数据结果不同被其他事务修改了。幻读同一事务内两次相同的范围查询返回的记录数不同有其他事务插入或删除了数据。InnoDB在“可重复读”级别下通过MVCC解决了快照读的幻读但当前读如SELECT ... FOR UPDATE仍可能幻读需要用间隙锁解决。7.3 锁的类型行锁锁住一行。InnoDB实现。间隙锁锁住一个索引区间防止其他事务在这个区间插入新行解决幻读。临键锁行锁间隙锁的组合。表锁MyISAM引擎主要使用锁住整张表并发性能差。意向锁表级锁表示“有事务即将或正在对表中的某些行加锁”用于快速判断表级冲突。7.4 死锁与排查当两个或以上事务互相等待对方释放锁时就发生死锁。InnoDB会自动检测并回滚其中一个事务。-- 事务A START TRANSACTION; UPDATE user SET age 20 WHERE id 1; -- 持有id1的行锁 UPDATE user SET age 30 WHERE id 2; -- 尝试获取id2的行锁等待... -- 事务B同时发生 START TRANSACTION; UPDATE user SET age 40 WHERE id 2; -- 持有id2的行锁 UPDATE user SET age 50 WHERE id 1; -- 尝试获取id1的行锁等待... -- 死锁发生如何排查查看SHOW ENGINE INNODB STATUS;命令输出中的LATEST DETECTED DEADLOCK部分。最佳实践事务尽量短小尽快提交。访问多张表时保持一致的顺序例如总是先更新user表再更新order表。在事务中如果更新操作后条件可能变化使用SELECT ... FOR UPDATE提前锁定相关行。使用较低的隔离级别如读已提交可以减少锁冲突。8. 备份、恢复与日常运维数据库运维是保证数据安全的生命线。8.1 逻辑备份与恢复使用mysqldump工具导出的是SQL语句。# 备份整个数据库 mysqldump -u root -p --databases mydb mydb_backup.sql # 备份单张表 mysqldump -u root -p mydb user user_backup.sql # 恢复 mysql -u root -p mydb mydb_backup.sql优点可读性好兼容性强可选择性恢复。缺点大数据量时慢锁表可用--single-transaction参数避免仅限InnoDB。8.2 物理备份直接复制数据文件datadir。必须在MySQL服务停止时进行或使用专业工具如Percona XtraBackup进行热备份。优点速度快。缺点不跨平台/版本恢复时要求环境一致。8.3 二进制日志与时间点恢复这是实现“前滚恢复”的关键。MySQL的binlog记录了所有数据更改操作。-- 查看binlog配置 SHOW VARIABLES LIKE %log_bin%;恢复流程用最近的全量备份恢复数据库。找到备份后的binlog文件使用mysqlbinlog工具重放从备份时间点到故障时间点之间的所有操作。mysqlbinlog --start-datetime2023-10-27 00:00:00 --stop-datetime2023-10-27 12:00:00 mysql-bin.000001 | mysql -u root -p8.4 监控与日志慢查询日志记录执行时间超过long_query_time的SQL。是性能优化的主要依据。SHOW VARIABLES LIKE slow_query_log%; SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 2; -- 单位秒错误日志记录启动、运行、停止过程中的错误信息。通用查询日志记录所有客户端连接和语句性能开销大调试时开启。9. 常见问题与排查思路这里汇总了从网络热词和实际经验中提炼的高频问题。问题现象可能原因排查方式解决方案连接失败ERROR 1045 (28000)用户名/密码错误主机权限限制。检查连接命令用mysql -u root -p本地登录查看mysql.user表。重置密码授权远程主机GRANT ALL ON *.* TO user% IDENTIFIED BY pass; FLUSH PRIVILEGES;生产环境慎用%服务无法启动端口被占用my.ini配置错误data目录权限问题文件损坏。查看错误日志通常在data目录下.err文件检查端口netstat -ano | findstr :3306。修改端口修复配置文件检查datadir路径和权限尝试重新初始化。导入数据报外键错误导入顺序不对先导入了依赖子表的数据。查看具体的错误信息定位是哪张表的外键约束失败。禁用外键检查导入SET FOREIGN_KEY_CHECKS0;导入SQLSET FOREIGN_KEY_CHECKS1;。或按依赖顺序导入先主表后子表。DELETE或UPDATE失败Could not execute statement常见于外键约束导致如ON DELETE RESTRICT。查看错误详情确定是哪个外键约束阻止了操作。先删除或更新子表中的相关记录或者修改外键约束为ON DELETE CASCADE级联删除需谨慎。查询突然变慢数据量增长未加索引索引失效锁等待服务器资源瓶颈。1. 用EXPLAIN分析慢SQL。2. 用SHOW PROCESSLIST;查看当前连接和状态。3. 监控服务器CPU、内存、IO。1. 优化SQL添加或调整索引。2. 杀掉长时间运行的查询KILL [id]。3. 考虑分库分表或读写分离。Incorrect string value插入UTF8报错字符集不匹配尝试插入4字节的emoji字符到utf83字节字段。查看表、字段的字符集SHOW CREATE TABLE user;。将字段字符集改为utf8mb4排序规则改为utf8mb4_unicode_ci。确保连接字符集也是utf8mb4。10. 最佳实践与工程建议命名规范表名、字段名使用小写蛇形命名法user_profile避免使用MySQL保留字。主键设计使用与业务无关的自增整数BIGINT AUTO_INCREMENT或全局唯一的UUID如雪花算法ID。自增整数性能更好。字段设计每个字段必须有注释COMMENT。选择最精确的数据类型。除非必要字段尽量定义为NOT NULL并设置默认值。索引策略为主键和外键列建立索引。为WHERE、ORDER BY、GROUP BY、JOIN ON子句中的列考虑索引。单表索引不宜过多一般不超过5个。SQL编写避免使用SELECT *只取需要的列。批量插入使用INSERT INTO ... VALUES (), (), ...。更新/删除操作前务必先用SELECT验证WHERE条件。在事务中先执行SELECT ... FOR UPDATE锁定资源再执行更新避免竞态条件。连接管理使用连接池如HikariCP, Druid。应用程序中操作完成后及时关闭连接。版本控制数据库Schema变更DDL必须通过版本化的迁移脚本如Flyway, Liquibase管理禁止直接在生产环境手动修改。安全规范禁止明文存储密码使用强哈希如bcrypt。最小权限原则为应用创建专属数据库用户只授予必要权限。防范SQL注入永远不要拼接SQL使用参数化查询PreparedStatement。定期审计和更新密码。从下载安装、编写第一行SQL到理解索引数据结构、事务隔离级别和死锁排查我们完成了一次MySQL核心知识的系统性穿越。记住数据库学习是一个“实践-理论-再实践”的循环。不要停留在知道概念一定要动手实验尝试不同的索引用EXPLAIN查看执行计划模拟事务并发场景。接下来你可以沿着这几个方向深入性能优化学习如何分析slow log使用pt-query-digest等工具深入了解InnoDB缓冲池、日志系统。高可用架构研究主从复制Replication的原理与搭建了解MHA、MGR等高可用方案。分库分表当单表数据超过千万级学习如何使用ShardingSphere、MyCat等中间件进行水平拆分。把本文当作一个随时可查的参考手册。当你遇到具体问题时再回来翻阅对应的章节结合实践理解会愈发深刻。数据库是后端工程师的立身之本扎实的功底会让你在复杂系统面前游刃有余。