带新人的时候我经常被问到同一个问题MySQL到底怎么入手这个话题已经被说烂了但拦住的初学者依然一拨接一拨。有人装上MySQL之后不知道怎么连有人用Navicat点鼠标很溜一敲命令行就懵还有人卡在权限、SSL、字符集这些看似不起眼的小坑里出不来。这篇内容我打算把MySQL数据库操作基础完整过一遍从连接方式、库表结构、增删改查到事务、索引、存储过程、权限管控和常见报错排查一步步拆开讲适合刚接触数据库、准备面试、或者正在做JavaWeb/运维项目的朋友直接参考。我尽量用实际操作为主线尽量把每个命令背后的“为什么”也交代清楚。1. 内容整体设计与思路拆解1.1 从“点鼠标”到“敲命令”的关键转变我发现很多新人的通病是Navicat用得很溜增删改查全在图形界面里点一让他上服务器看问题就露馅。生产环境里排查慢查询、做数据修复、写自动化脚本几乎所有场合都要面对命令行。MySQL的操作基础说到底是两件套SQL语法和数据库管理概念。前者是对数据的操作后者是对库、表、用户、权限这些对象的管理。两个都要会缺一个都会在实战里卡壳。图形工具的作用更像是辅助驾驶命令行才是真正的手动挡能力。我建议新人在熟悉基础命令之后再依赖图形界面否则很容易出现“换了台电脑就不会用数据库”的情况。等你熟悉了命令行再用Navicat或者DBeaver效率确实高很多这一点我也不否认。1.2 学习路径环境 → 连接 → 建表 → 实战 → 进阶如果你完全不熟悉MySQL我的建议是不要一上来就背命令先按下面这条路线走一遍安装MySQL到你的本机Windows或者Linux都行确保能启动服务。用命令行客户端连上去执行最简单的SELECT 1;创建数据库和表把常用字段类型过一遍。做完整的增删改查练习配合排序、条件过滤、分页这些高频操作。再学索引、事务、权限、存储过程这些进阶能力。这条路径的好处是每一层都建立在前一层的基础上不容易出现“学了事务但连不上库”的尴尬。很多教程上来就讲B树和隔离级别对初学者来说是巨大的打击。我的经验是先能熟练操作再谈原理原理可以在动手过程中逐步理解。1.3 为什么权限、SSL、连接方式这些“边角料”反而最常用我特意翻了最近大家搜索的高频词发现一个很有意思的现象除了基础的增删改查大家搜得最多的是“Navicat操作数据库给只读权限”“mysql ssl连接错误”“error 2002 through socket”“mysql设置默认值为0”“mysql创建索引”“mysql主从复制”。这些其实都属于“数据库操作基础”的外延。原因很简单实际工作中真正的CRUD增删改查早被封装到业务代码里了你亲手敲的SQL反而是权限变更、改表结构、调索引、排查连接问题这类“脏活累活”。所以这篇内容我不会只讲CRUD那几句话而是把这些高频的、看起来零碎但其实每星期都会遇到的操作一起拆开。它们才是让你从“会用MySQL”升级到“能处理MySQL问题”的分水岭。2. 核心细节解析与实操要点2.1 连接数据库的几个参数到底怎么填不管用什么客户端连接MySQL本质上都是确认四个身份信息加一堆连接参数参数示例说明主机地址127.0.0.1 或 localhost本地连接还是远程连接端口号3306MySQL默认端口可改用户名root数据库账号密码你的密码认证凭证数据库名test_db可不填连接后USE命令行连接的标准写法是mysql -h 127.0.0.1 -P 3306 -u root -p如果不加-h默认走localhost这里有一个很多人踩过的坑localhost在Linux下默认走Unix套接字socket文件而不是TCP/IP。所以当你看到ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock时大概率是下面三种情况之一MySQL服务根本没启动。socket文件路径不对客户端按默认路径找但服务端把socket文件放在别处。你用localhost但服务只监听了TCP端口没开socket监听。排查思路也很简单先确认服务状态然后mysql -h 127.0.0.1 -P 3306 -u root -p强制走TCP试一试。如果走TCP能通说明问题就是socket路径不一致去MySQL配置文件里找socket参数调整即可。远程连接时还要注意用户权限里是否允许对应主机访问。MySQL的权限是“用户 来源主机”双重维度rootlocalhost和root%是两个不同的用户。这也是为什么很多人从本机可以连、用局域网IP就报Access denied的原因。2.2 库、表、字段、记录先把概念对齐MySQL的逻辑结构是三级层次数据库database→ 表table→ 记录row字段column是表格的列是定义结构的最小单位。新建一个数据库CREATE DATABASE IF NOT EXISTS shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;这里强烈建议字符集统一用 utf8mb4而不是 utf8。utf8mb4 是真正的四字节UTF-8能存emoji和生僻字也是MySQL 8.0的默认值。排序规则 utf8mb4_unicode_ci 对绝大多数中文场景都友好。我接手过的老项目里很多奇怪的中文乱码问题追根到底都是当年用了 latin1 或者 utf8 字符集。创建表时要重点关注几个细节主键一般用自增的整型BIGINT UNSIGNED AUTO_INCREMENT能避免很多并发插入时的锁问题。默认值热搜词里有个“mysql设置默认值为0”写法就是DEFAULT 0。给非业务字段设置默认值能极大降低数据录入时的心智负担。NOT NULL能设成NOT NULL就尽量设NULL在索引、聚合、排序里都会变成特殊逻辑很多查询结果对不上最后查出来都是NULL在捣鬼。注释字段注释一定写几个月之后再回来看表结构没有注释的表就是天书。CREATE TABLE user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键ID, username VARCHAR(50) NOT NULL DEFAULT COMMENT 用户名, age INT NOT NULL DEFAULT 0 COMMENT 年龄, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;2.3 增删改查是引擎不是全部增删改查四类操作语法听起来很简单但细节很多。插入可以用INSERT INTO user (username, age) VALUES (张三, 20);批量插入就变成了一行多组括号。更新要特别注意加WHEREUPDATE user SET age 21 WHERE username 张三;不带WHERE的UPDATE是全表更新这不是功能问题是事故问题。生产环境锁表、误更新大多数都是这个原因。删除同理DELETE FROM user WHERE id 1;和TRUNCATE TABLE user;完全不是一回事。DELETE是一行行删会记录日志、触发约束能加WHERETRUNCATE是直接重建表结构速度快但不可按条件回退。排序和分页也是高频操作SELECT * FROM user ORDER BY created_at DESC LIMIT 10; SELECT * FROM user ORDER BY created_at DESC LIMIT 20, 10;第二个语句里的LIMIT 20, 10表示跳过20行取10行等价于LIMIT 10 OFFSET 20。分页越往后翻越慢原因在于它要跳过前面所有行优化方式会在后面的索引和性能部分说明。3. 实操过程与核心环节实现3.1 完整案例从零搭建一个用户订单库与其零散地记命令不如跟着一个完整的小项目走一遍。我在这里用最经典的“用户 订单”场景把建库、建表、加索引、插数据、查询、改结构所有操作串起来。第一步建库建表CREATE DATABASE IF NOT EXISTS shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE shop; CREATE TABLE user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 用户ID, username VARCHAR(50) NOT NULL DEFAULT COMMENT 用户名, phone VARCHAR(20) NOT NULL DEFAULT COMMENT 手机号, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1启用 0禁用, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), UNIQUE KEY uk_phone (phone) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表; CREATE TABLE orders ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 订单ID, user_id BIGINT UNSIGNED NOT NULL COMMENT 用户ID, amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 订单金额, order_no VARCHAR(32) NOT NULL DEFAULT COMMENT 订单号, pay_time DATETIME DEFAULT NULL COMMENT 支付时间, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 下单时间, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;第二步插入测试数据INSERT INTO user (username, phone, status) VALUES (张三, 13800001111, 1), (李四, 13800002222, 1), (王五, 13800003333, 0); INSERT INTO orders (user_id, amount, order_no, pay_time) VALUES (1, 199.00, 20240101001, 2024-01-01 10:00:00), (1, 299.00, 20240101002, NULL), (2, 99.00, 20240101003, 2024-01-01 11:30:00);第三步核心查询。需求是找出所有用户名含“张”的用户按创建时间倒序同时带出每个用户的订单总金额SELECT u.id, u.username, IFNULL(SUM(o.amount), 0) AS total_amount FROM user u LEFT JOIN orders o ON o.user_id u.id WHERE u.username LIKE %张% GROUP BY u.id, u.username ORDER BY u.created_at DESC;这里有一个面试常考点为什么要IFNULL(SUM(o.amount), 0)因为LEFT JOIN之后没有订单的用户在SUM聚合之后结果是NULL不是0。NULL和0在逻辑判断里完全不同这一点特别容易踩坑。3.2 修改表结构的正确姿势另一个高频搜索词是“mysql数据库修改结构”。ALTER TABLE的常用写法整理如下-- 增加字段 ALTER TABLE user ADD COLUMN email VARCHAR(100) NOT NULL DEFAULT COMMENT 邮箱 AFTER phone; -- 修改字段类型和默认值 ALTER TABLE user MODIFY COLUMN email VARCHAR(128) NOT NULL DEFAULT COMMENT 邮箱; -- 重命名字段 ALTER TABLE user CHANGE COLUMN email email_addr VARCHAR(128) NOT NULL DEFAULT COMMENT 邮箱地址; -- 删除字段 ALTER TABLE user DROP COLUMN email_addr; -- 增加索引 ALTER TABLE user ADD INDEX idx_username (username);修改大表结构时一定要留个心眼MySQL 8.0里多数ALTER操作底层是瞬时完成的但有些操作比如增加字段、修改数据类型会触发表的重建。数据量大时会导致锁表时间很长业务侧感知就是“卡死”。生产环境建议用pt-osc或gh-ost这类在线变更工具或者在低峰期操作。我早期直接对线上几百万行的表加字段结果现场表演了一出锁表事故从那以后每次都规规矩矩先评估影响。字符串转日期也是一个高频需求特别常见于导入数据时日期列是文本的情况SELECT STR_TO_DATE(2024-01-15 10:30:00, %Y-%m-%d %H:%i:%s); SELECT DATE_FORMAT(created_at, %Y-%m-%d) FROM user;STR_TO_DATE是把字符串解析成日期DATE_FORMAT是把日期格式化成字符串。注意格式化串里的%H是24小时制%h是12小时制写错一个字母结果差半天别问我怎么知道的。3.3 事务与锁数据安全的闸门事务是MySQL面试里绕不开的题目也是日常开发里最容易理解错的概念。事务的核心是ACID也就是原子性、一致性、隔离性、持久性。MySQL中的InnoDB存储引擎才支持事务MyISAM不支持这一点必须记住。事务的基本用法START TRANSACTION; UPDATE orders SET amount amount 10 WHERE id 1; SAVEPOINT sp1; UPDATE orders SET amount amount 10 WHERE id 2; ROLLBACK TO SAVEPOINT sp1; COMMIT;如果中间某一步出错可以直接ROLLBACK回滚到事务开始的状态保证数据不会改一半。注意DDL语句CREATE、ALTER、DROP会隐式提交事务不能回滚这也是为什么线上改表结构前要格外谨慎。锁的话题面试常问的是“行锁、表锁、间隙锁、乐观锁、悲观锁”。InnoDB默认支持行锁但不代表所有操作都只锁一行。如果你的WHERE条件没有走到索引InnoDB可能会升级成锁很多行甚至全表——这就是很多“莫名其妙锁表”问题的根源。乐观锁是通过版本号或时间戳实现适合并发冲突少的场景UPDATE orders SET amount 200, version version 1 WHERE id 1 AND version 3;受影响行数是0就说明版本号不对需要重试这就是乐观锁的核心思路。悲观锁直接用SELECT ... FOR UPDATE把行锁住适合冲突频繁的业务代价是并发能力下降。3.4 索引用空间换时间的核心手段索引这个东西你可以理解为书的目录。没有索引就是全表扫描几百上千万行的时候一条查询跑十几秒很正常。索引创建的方式CREATE INDEX idx_username ON user (username); CREATE UNIQUE INDEX uk_phone ON user (phone); DROP INDEX idx_username ON user;索引不是越多越好。每个索引都会占用存储空间每次INSERT和UPDATE都要同步维护所有索引索引太多写入会变慢。我见过一个表挂了十几个索引查询倒是快了写入性能被拖垮。核心经验是索引建立在查询高频且区分度高的字段上状态字段这种取值只有0和1的建索引意义不大。经常被问到“为什么我建了索引但查询还是很慢”大概率是索引失效。常见失效场景包括对索引列使用函数、隐式类型转换、LIKE以通配符开头、OR条件之一没索引。比如SELECT * FROM orders WHERE DATE(created_at) 2024-01-01;如果created_at有索引这个写法会失效因为DATE函数破坏了索引顺序。正确写法是用范围查询SELECT * FROM orders WHERE created_at 2024-01-01 AND created_at 2024-01-02;判断SQL是否走了索引可以直接用EXPLAIN看执行计划。我写慢查询分析时几乎离不开它用法非常简单EXPLAIN SELECT * FROM orders WHERE order_no 20240101001;看type和key两列就够了。type为all就是全表扫描至少要达到ref或者range才算效率合格eq_ref和const是最好情况。3.5 存储过程把SQL逻辑封装起来存储过程也是热搜词里出现频率很高的内容Java后端同学使用不多但做数据报表、定时任务、ETL数据同步时经常用到。它本质就是把一组SQL语句封装成可复用的过程支持入参、出参和局部变量。一个带错误处理的存储过程示例DELIMITER $$ CREATE PROCEDURE sp_create_order( IN p_user_id BIGINT, IN p_amount DECIMAL(10,2), OUT p_order_id BIGINT ) BEGIN DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN ROLLBACK; SELECT 事务失败已回滚 AS error_msg; END; START TRANSACTION; INSERT INTO orders (user_id, amount, order_no) VALUES (p_user_id, p_amount, CONCAT(NO, UNIX_TIMESTAMP())); SET p_order_id LAST_INSERT_ID(); COMMIT; END$$ DELIMITER ;调用方式CALL sp_create_order(2, 158.00, order_id); SELECT order_id;先说几个关键点。DELIMITER的作用是临时把SQL语句分隔符从分号改成 $$避免存储过程体内的分号被客户端当成语句结束。DECLARE EXIT HANDLER FOR SQLEXCEPTION是异常捕获事务出错自动回滚并返回提示。这类写法在数据导入自动化和批量业务处理中非常实用比应用程序里一次一次拼SQL要安全得多。4. 用Navicat完成日常管理与只读授权4.1 Navicat连接MySQL的常见坑Navicat是我们日常管理中特别常用的图形客户端。连接配置和生产环境排查一样主机、端口、用户名、密码四项只要有一个不对都会连接失败。很多人在“连接测试”这一步反复报错尤其是MySQL 8.0环境最常见的就是SSL连接错误。MySQL 8.0默认启用了SSL认证Navicat连接时如果服务器的SSL配置和客户端不完全兼容会直接报类似SSL connection error: unknown error number。解决方法是在连接配置的高级选项里把SSL/使用SSL改成“不使用”或者“如果可用”对绝大多数内网环境来说不加密也能满足安全要求。如果是公网连接还是建议保留SSL同时检查本机时间是否准确——证书验证对系统时钟非常敏感时间偏差过大也会导致SSL握手失败。另外千万别忽略MySQL 8.0的认证插件变化。8.0默认使用caching_sha2_password老版本客户端驱动不认识这个插件就会报认证失败。遇到Navicat连接成功但JDBC连接失败的诡异情况十有八九是这个原因。升级JDBC驱动到8.0版本轻松解决或者建用户时指定IDENTIFIED WITH mysql_native_password BY 密码兼容老驱动。如果连服务器都登录不上先检查MySQL服务是否启动Windows下到服务管理器看MySQL服务状态Linux下执行systemctl status mysqldCentOS系或service mysql statusDebian系。这里的顺序应该是“服务 → 端口 → 账号 → 配置”一层层排查效率最高。4.2 只读权限用户创建与授权全流程热搜词里有个非常具体的需求“用Navicat操作数据库给只读权限”。这种需求在实际工作中很常见比如给数据分析实习生开账号查数据、给外包团队开视图查询权限总之就是不允许对方改数据。先从命令行方式讲原理明白了图形界面自然能看懂。MySQL 8.0之后创建用户和授权要分两步CREATE USER readonly_user% IDENTIFIED BY ReadOnly2024; GRANT SELECT ON shop.* TO readonly_user%; FLUSH PRIVILEGES;这里SELECT就是只读权限的核心。如果想要限制得更死可以只给部分表的查询权限GRANT SELECT ON shop.user TO readonly_user%; GRANT SELECT ON shop.orders TO readonly_user%;%表示这个用户可以从任意主机连接如果只允许某个IP使用改成192.168.1.100就行。用Navicat操作同样很直观。打开连接之后选择“用户”点“新建用户”填写用户名、主机和密码然后在“授予权限”的选项卡里勾选数据库shop的SELECT权限其他增删改权限全部不勾。有些老版本Navicat界面叫“服务器权限”和“库权限”注意在对应数据库的权限列表里操作不要误给了全局权限。“Shell”类权限也不要勾以免对方用命令行工具连上去执行特殊操作。给完权限之后最好从苛刻的视角测试一遍用这个只读账号连接执行一次SELECT验证没问题再尝试一次INSERT或者UPDATE确认被拒绝。我在实际项目中多次发现有时权限看起来给对了但用户实际连接时因为主机匹配原因依然被拒所以一定要实测。4.3 主从复制与远程表同步的入门思路热搜词里还有“主从复制”“把远程库的这张表同步到本地”这些都属于数据库操作进阶。主从复制的原理不复杂主库把所有变更写进binlog二进制日志从库的I/O线程把binlog拉过来写到自己的relay logSQL线程再重放relay log完成数据同步。搭建主从复制的大致步骤是主库开启binlog配置server-id1和log-binmysql-bin。主库创建复制账号并授权REPLICATION SLAVE。从库配置server-id2执行CHANGE MASTER TO指定主库地址、日志文件名和位置。从库执行START SLAVE然后查看SHOW SLAVE STATUS看到Slave_IO_Running: Yes和Slave_SQL_Running: Yes就表示成功。只同步某一张表可以在从库配置里设置REPLICATE_DO_TABLE (db_name.table_name)。这个方案的好处是利用MySQL自带的binlog机制不用额外写代码非常稳定缺点是需要一定的运维基础而且跨网络环境时要确保主从之间的网络通畅。5. 常见问题与排查技巧实录5.1 安装部署环境的坑热搜词里“mysql安装”“linux安装mysql”“rpm安装mysql”“docker安装mysql”“windows 安装 mysql 8”扎堆出现说明很多人在第一步就被拦住了。Linux用RPM安装MySQL 8的核心命令wget https://dev.mysql.com/get/mysql80-community-release-el7-7.noarch.rpm rpm -ivh mysql80-community-release-el7-7.noarch.rpm yum install -y mysql-server安装之后CentOS查看初始密码的命令是grep temporary password /var/log/mysqld.log然后用这个临时密码登录第一次使用必须改密码ALTER USER rootlocalhost IDENTIFIED BY 新密码;密码策略默认要求强度较高包含大小写、数字、特殊字符位数不少于8位。如果只是本地开发想简化密码可以先降低策略SET GLOBAL validate_password.policy LOW;MySQL 8.0里这个参数名和5.7不一样5.7是validate_password_policy8.0在参数名中加了点很多人栽在这个细节上。Docker方式安装MySQL是我个人最推荐的学习环境因为干净、可随时销毁重建docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD123456 \ -v /data/mysql:/var/lib/mysql \ mysql:8.0注意挂载数据目录-v否则容器一删数据就没了。如果Docker安装后无法登录先看容器启动日志docker logs mysql8Docker里MySQL 8同样有SSL和认证插件兼容问题解决方案上面已经提过。我还遇到过一种情况端口已经被占用启动时-p 3306:3306会直接失败换成-p 3307:3306就能规避。5.2 连接与SSL错误排查清单把连接相关的经典错误整理成表格方便你直接对号入座报错信息常见原因解决办法ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sockMySQL未启动 / socket路径不对启动服务查配置里的socket路径用-h 127.0.0.1强制走TCPAccess denied for user rootlocalhost密码错误 / 认证插件不兼容确认密码重置密码升级客户端驱动SSL connection error: unknown error numberSSL握手失败 / 系统时间偏差Navicat关闭SSLNTp同步时间更新驱动Communications link failure网络不通 / 服务挂了ping测试telnet测试3306端口查服务状态Cant connect to MySQL server on ip (10060)防火墙拦截开放3306端口确认用户授权包含该来源IP排错顺序我建议固定下来第一步看服务第二步看端口第三步看账号权限最后再看配置文件。很多新手一上来就怀疑密码错了其实先systemctl status mysqld就能省掉很多时间。端口测试用telnet 192.168.1.10 3306能通就说明网络层没问题这时问题基本锁定在账号或SSL配置上。5.3 性能调优与锁表应对性能调优这个话题很大但日常使用最基础的三板斧就是索引、SQL改写、连接池参数。遇到慢查询先用EXPLAIN看执行计划绝大多数问题都是全表扫描或者没用上合适索引。锁表问题在企业里特别容易引发事故。状态表现为某个更新操作执行特别慢或者页面一直转圈。排查方法SHOW PROCESSLIST;看Info列是不是有一条长期处于Updating或Locked状态的SQLTime列会显示执行时间。直接KILL 进程ID;可以把锁释放掉但根本方案是优化SQL减少持锁时间或者把长事务拆成多个短事务。连接池是另一个高频热搜词。Java开发里常用的HikariCP连接池配置可以参考maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000连接池的核心思路是复用连接避免频繁创建销毁连接带来的开销。maximum-pool-size不是越大越好MySQL默认最大连接数是151如果应用连接池设到200很快数据库就会报 “Too many connections”。这个数字需要配合数据库端的max_connections统一规划。6. 写在后面面试视角与下一步方向从热搜词里能看到大量“mysql面试题”“锁原理及面试题”“mysql事务处理”之类的关键词说明不少朋友是在准备后端开发面试。从面试角度来说数据库四件套是必考题事务ACID、隔离级别、索引结构、锁机制。建议你把这三条主线吃透事务的四种隔离级别分别解决什么问题InnoDB索引为什么用B树MVCC和锁是怎么配合实现隔离级别的。这些概念停留在“听说过”层面是远远不够的面试官问深一层就露馅。如果你的方向是运维或者数据工程下一步可以往这些方向发展主从复制与高可用架构、TDengine这类时序数据库的表结构转换、Zabbix监控平台的MySQL部署、Kubernetes环境里的MySQL容器化部署。这些场景的核心还是在基础操作之上叠加了一些生态知识先把SQL基础打牢后面的路会顺畅得多。我个人在实际带人的过程中还有一个很深的体会与其背命令不如亲手把一套小系统从建库做到查询优化哪怕数据量就几万条过程中踩过的坑都会变成最牢固的记忆。数据库这个东西错误犯得越早、代价越小。你真正经历过一次误删数据、一次锁表、一次慢查询把接口拖垮比看十篇教程都有用。把这些基础操作反复练到肌肉记忆级别后面再接触中间件、分库分表、大数据组件你会发现根基特别稳。