这几天有个准备考三级数据库技术的朋友问我数据库入门到底先学什么。我翻了翻他的练习记录发现他买了厚厚的教材整天在背SQL语法但打开终端连个建表都磕磕绊绊。这其实是很多初学者的通病——把数据库技术当成一门“背知识点”的科目而不是一门“动手操作”的技能。今天我就从数据库技术里最核心、最日常、也最容易被低估的“基本操作”说起把这些操作背后真正值得关注的设计逻辑、坑点和经验一条条掰开讲清楚。这篇内容不是教科书式的知识点堆砌更像是我在项目里、考试前、带新人时反复用到的那套基本功汇总。不管你是正在备战三级数据库技术真题的考生还是刚进公司要被分到数据相关任务的开发新手或者只是想在简历里把“熟悉SQL”这四个字写得底气足一点这篇都应该能帮到你。我会尽量用大白话讲原理用真实场景讲操作把数据库基本操作里那些看起来简单、实际却处处是细节的地方一次说透。1. 数据库基本操作到底在学什么先给“基本操作”正个名。很多人一听“基本”两个字就觉得是增删改查那四板斧没啥技术含量。但实际工作中你会发现真正能把CRUD写好、写稳、写出性能的人并不比做架构设计的人少拿工资。原因很简单所有上层业务、中间件、缓存、报表系统最终都要落到数据库这一层而落到数据库这一层的第一道关口就是你这几条SQL和表结构写得对不对、稳不稳。三级数据库技术考试里基本操作部分其实考得相当有深度。它不光是问你怎样写一条SELECT而是会考察你对数据完整性、约束、事务隔离级别、索引设计、备份恢复策略这些“操作背后的原理”是否理解。换句话说考试和实际工作在这一点的取向上高度一致操作要会写原理更要懂。我见过不少新人在入门时陷入两个极端。一种是把基本操作看得太简单上来就写业务SQL表结构随手建字段类型瞎选结果后面数据一多查询慢成蜗牛才发现当初建表时连索引都没规划。另一种是把基本操作看得太玄非要先去啃B树原理、两阶段锁协议、MVCC实现结果连INSERT都没写利索就被底层机制劝退了。正确的姿势是把基本操作当成一套“肌肉记忆原理理解”的组合。肌肉记忆让你写得快、写得对原理理解让你知道为什么这样写、什么时候不能这样写。这两种能力是交替提升的不是先背完所有原理再动手也不是先写一千条SQL再补理论。下面我按实际操作的顺序从建库建表讲起一直到事务和备份把这些基本操作里最关键的点逐个过一遍。2. 动手前的准备工作选型、建模与字符集2.1 需求分析到数据模型别在表结构上省时间数据库操作的第一步永远不是打开客户端敲CREATE TABLE而是搞清楚你到底要存什么、怎么存、谁会来读这些数据。这就像一个仓库管理员进货之前先得知道货架上要摆什么商品、每种商品有多少规格、拣货的人是从前面拿还是从侧面拿。如果这一步省了后面所有操作都是在给错误的结构打补丁。实际工作中最典型的反面教材就是开发人员直接参考旧系统的表结构或者凭直觉随手建表。比如用户表常见的问题是字段类型选错手机号用数值型用户名用TEXT状态位用VARCHAR(10)存“启用/禁用”。这些选择在数据量小的时候看不出问题等到了几百万行、需要做条件过滤和排序时全部变成性能雷区。手机号用数值型一旦有人用0开头的数据或者未来扩容数值型还会丢精度、丢格式状态位用字符串索引长度大、比较慢而且容易拼写不统一——“启用”“启用 ”“已启用”全都能混进去。正确的做法是先做简单建模即用实体-关系图的方式把核心实体、属性和实体间关系画出来。哪怕只是在纸上画三个框、几条线也比直接建表强。画的过程中你会自然想清楚用户和订单是一对多还是多对多订单里的金额字段该用DECIMAL还是FLOAT商品分类需不需要单独一张表。这些问题的回答直接决定后面所有操作的正确性。2.2 范式设计该遵守就遵守该打破就打破提到数据库建模范式是个绕不开的话题。三级数据库技术考试对第一范式、第二范式、第三范式的考察几乎是固定题型经常以真题的形式让你分析某个表设计违反了第几范式。这里我结合实操把范式讲得直白一点。第一范式要求字段不可再分。这个最容易被违反典型例子就是一个人把“收货地址”拆成“省份”“城市”“区县”“详细地址”四个字段这是合理的但如果是把多个手机号塞进一个字段用逗号分隔那就是典型的第一范式违规。第二范式要求非主键字段完全依赖主键不能只依赖主键的一部分这条主要针对联合主键的情况。第三范式要求非主键字段不能传递依赖主键比如订单表里同时存“客户ID”和“客户姓名”“客户姓名”实际上是通过客户ID才能确定的这就是传递依赖应该拆到客户表里。我在实际项目里对范式的态度是八个字先守三范式再用反范式。也就是一开始设计时尽量按第三范式来拆表保证数据一致性等到查询确实出现大量多表关联、性能扛不住时再考虑冗余个别字段比如在订单表里冗余“客户姓名”用空间换时间。反范式不是错错的是从一开始就乱设计等数据乱了再来“优化”。2.3 存储引擎与字符集一分钟决定一年后后悔以MySQL为例建表之前你还要做两个重要选择存储引擎和字符集。存储引擎选错的影响通常要等数据量上来才显现。InnoDB支持事务、行级锁、崩溃恢复MyISAM不支持事务、只支持表锁但非事务场景下某些查询更快。现在主流选择基本无脑InnoDB除非你在做的是日志型、只读型、完全不需要事务的应用否则别在存储引擎上玩花活。字符集更是新手重灾区。很多人在Windows上用默认字符集建库INSERT中文进去再查出来变成“???”一脸茫然。解决办法不是等到乱码了再去改而是在建库建表时就把字符集定成utf8mb4。utf8mb4是UTF-8的超集能存emoji、生僻字兼容性好。排序规则一般用utf8mb4_general_ci或者utf8mb4_0900_ai_ci前者兼容性好后者排序更符合现代语言习惯。三级的教材里这部分不会讲太深但考试真题里偶尔会考字符集导致的乱码问题实际项目里更是必然遇到所以建议一开始就养成习惯数据库连接串、建库语句、建表语句三处字符集保持一致乱码概率直接下降九成。3. 库表操作从CREATE到DROP的完整规范3.1 建库建表把基础DDL一次写对做好了前置设计就可以开始写DDL了。DDL是数据库基本操作里最枯燥也最考验基本功的部分因为它一旦上线后面改动成本就高了。一个规范的建库语句至少要包含字符集和排序规则这两项。不要只写CREATE DATABASE test;然后指望数据库默认设置是合理的。生产环境里默认字符集往往不是utf8mb4你后知后觉想改改动成本比一开始多写几个字符高得多。建库示例CREATE DATABASE shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;建表语句更值得逐行推敲。我写CREATE TABLE时字段顺序、类型选择、约束声明、索引设计这几件事是同时考虑的。一个典型的用户表示例CREATE TABLE user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键ID, username VARCHAR(50) NOT NULL COMMENT 用户名, password_hash CHAR(64) NOT NULL COMMENT 密码哈希值, mobile VARCHAR(20) DEFAULT NULL COMMENT 手机号, email VARCHAR(100) DEFAULT NULL COMMENT 邮箱, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1正常0禁用, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;这里有几个容易被忽视的细节。主键用BIGINT UNSIGNED自增这是常规做法方便索引维护和性能优化密码字段存哈希值的固定长度用CHAR(64)而不是VARCHAR(64)省空间而且语义更清晰时间字段用DATETIME而不是VARCHAR或者时间戳因为DATETIME可读性好范围也够用。状态字段用TINYINT而不是字符串查询快且规范。唯一约束和普通索引要分清用户名这种业务上不能重复的用唯一键状态这种大量重复、选择性低的字段建普通索引更多是为了部分场景的群体查询。3.2 改表与删表在线操作要清醒ALTER TABLE是后期改表结构的主要手段。但如果一张表已经上线运行且数据量巨大ALTER操作就需要特别小心。拿新增列来说虽然很多数据库支持了在线DDL但大表上执行DDL依然可能带来主从延迟、锁等待或者磁盘空间吃紧。我所在团队就有过一次生产事故一张几千万行的表需要加字段直接执行ALTER TABLE结果导致主库负载飙升业务接口大面积超时。事后我们总结大表变更必须走工具比如用gh-ost或者pt-online-schema-change这类在线变更工具分批次异步执行。改表的另一个常见问题是盲目删字段、改类型。有些新手为了省事直接DROP TABLE重新建这在开发环境无所谓生产环境就是灾难。删除字段之前先确认是否有视图、存储过程、应用代码还在引用这个字段。修改字段类型时注意是否会导致精度丢失比如把DECIMAL改成FLOAT或者把INT改成BIGINT还好反过来就可能溢出。基本操作里DROP和TRUNCATE都属于不可逆操作执行之前强制养成交代习惯先备份再操作最后验证。4. 数据操作INSERT、UPDATE、DELETE、SELECT的进阶细节4.1 插入数据几种写法与脏数据防线INSERT语句是基本操作里使用频率最高的但写法上也有讲究。常见的有三种形态。第一种是单行VALUES写法适合一次性插入少量测试数据。第二种是多行VALUES写法一条语句插多行比循环单条插入快得多适合批量初始化。第三种是INSERT INTO...SELECT写法可以从一张表查出数据直接插入另一张表做数据迁移、报表临时表时非常好用。-- 多行插入 INSERT INTO user (username, password_hash, status) VALUES (alice, hash1, 1), (bob, hash2, 1), (carol, hash3, 0);插入时最容易忽视的是脏数据防线。我见过不少新人从应用层接收参数后直接拼SQL字符串插入结果被特殊符号、转义字符整出数据混乱严重的时候甚至能造成安全问题。正确做法是至少使用参数化查询让数据库驱动替你做转义和类型校验。另外插入之前要想清楚哪些字段允许为空哪些必须有默认值。NULL和空字符串是两个完全不同的概念NULL表示“没填”空字符串表示“填了空内容”。你存手机号时用户不填就是NULL而不是空字符串。这个差别会直接影响后续所有WHERE条件判断和聚合统计。4.2 更新数据WHERE条件永远是第一优先UPDATE操作是所有DML里最需要敬畏的。究其原因是它一旦出错影响的往往不是一行而是一批数据而且没有简单办法恢复。新手最经典的事故就是把UPDATE语句的WHERE条件漏掉或者写错导致全表数据被覆盖。我给自己定了一条工作铁律任何UPDATE或者DELETE先写完整WHERE条件再写SET部分。执行之前用SELECT确认一遍影响的行数。比如要更新id为1001的用户状态SELECT id, status FROM user WHERE id 1001; -- 确认只有1行 UPDATE user SET status 0 WHERE id 1001;这条纪律听起来简单但真能坚持的人不多。我还见过有人用UPDATE做批量修正时WHERE条件里用到子查询结果子查询本身有问题导致更新范围扩大。特别提醒一下MySQL里UPDATE子查询不能直接作用于目标表需要套一层派生表这是很多新手在三级数据库技术真题里遇到的考点也是实际开发中常踩的坑。4.3 删除数据DELETE、DROP、TRUNCATE三兄弟删除操作是基本操作里最需要分清概念的地方。DELETE是DML按行删可以通过事务回滚删除数据不释放表空间在InnoDB里是标记删除TRUNCATE是DDL直接清空整张表的数据并重置自增计数器速度极快但不可按条件删、通常不可回滚DROP则是DDL连表结构一起删除。拿洗照片来类比DELETE像用橡皮擦擦掉照片上某个人物TRUNCATE像把整张照片撕掉重印DROP像把底片也一起销毁。实际项目里大表删除数据是个性能问题。几千万行的大表一次性DELETE几百万行事务日志和锁竞争会拖垮数据库。更稳妥的做法是分批删除每次限制几百几千行加上SLEEP间隔分多次完成减轻主库压力。DELETE FROM user_log WHERE created_at DATE_SUB(NOW(), INTERVAL 30 DAY) LIMIT 1000;注意MySQL的DELETE支持LIMIT但LIMIT本身不能防止全表误删它只是限制单次删除行数。真正防止误删还是要靠WHERE条件严谨和操作前备份。4.4 查询数据万物皆可SELECT但未必高效SELECT是数据库基本操作里最能体现水平的部分。刚入门时你可能只会SELECT * FROM table WHERE id1但实际工作中你会发现查询优化是一个没有上限的领域。先说SELECT *的问题。生产环境里显式列出需要的字段比SELECT *更合适。原因有几个减少网络传输、避免覆盖索引失效、也让别人看代码时能知道你真正关心哪些数据。有时候表结构加了个大字段SELECT *会把原本很快的查询拖成慢查询这种坑我踩过不止一次。再说WHERE条件的写法。一个常见误区是对索引列做函数运算比如WHERE YEAR(created_at)2024这会让索引失效正确写法是WHERE created_at 2024-01-01 AND created_at 2025-01-01。还有一个误区是模糊匹配时的前置通配符WHERE name LIKE %张%这种写法索引基本用不上如果你确实需要这种搜索能力应该考虑全文索引或者专门的搜索引擎而不是硬扛在关系型数据库里。多表查询方面搞懂INNER JOIN、LEFT JOIN、RIGHT JOIN的区别是基本要求。更实际的经验是能不用关联查询就不用确实需要时关联字段必须有索引。我在做查询优化时遇到最多的问题就是关联查询没走索引驱动表选错导致十几张表关联后跑出几十秒的查询。解决思路通常是先缩小中间结果集再关联而不是上来就让大表跟大表做笛卡尔积。5. 索引与视图让基本操作脱胎换骨5.1 索引到底怎么设计不是越多越好索引是数据库基本操作里最值得钻研的部分。没有索引的表全表扫描是唯一路径数据量一大什么花哨SQL都白搭。但索引也不是越多越好每个索引都要占用额外磁盘空间还要在每次INSERT和UPDATE时维护代价不小。我曾经接手过一个“为了提高查询性能”而建了二十多个索引的表结果写入性能反而严重下降最后精简掉大半才恢复正常。索引设计的基本原则是给选择性高、查询频繁、区分度大的列建索引。区分度可以用基数估算比如性别列只有两个值基数很低建索引意义不大而用户ID、订单号这种几乎不重复的列区分度极高建索引收益最大。联合索引要遵循最左前缀原则比如创建一个(a, b)联合索引查询条件里只有b而没有a索引帮不上忙这个原则在三级数据库技术考试里几乎是必考内容。5.2 索引失效的常见场景背下来能省很多事以下场景是我在实战中反复碰到、也是考试真题里喜欢考的索引失效情况这里整理成表方便对照场景示例后果对索引列使用函数WHERE YEAR(created_at)2024索引失效全表扫描隐式类型转换WHERE mobile13712345678mobile是VARCHAR索引失效前导模糊查询WHERE name LIKE %张索引失效OR连接非索引列WHERE id1 OR status0可能全表扫描违反最左前缀联合索引(a,b)但WHERE只用了b索引失效隐式类型转换这个坑尤其隐蔽。手机号字段是VARCHAR类型条件里却用了数值型常量MySQL会把字段转成数值再比较索引直接失效。平时写SQL时养成好习惯字段是什么类型条件参数就用什么类型。这个细节不只在数据库操作里有意义对应用层传参也很有参考价值。5.3 视图的本质不是性能工具是逻辑封装工具视图在基本操作里经常被忽略但它其实是个很实用的工具。视图本质是一条命名的SQL查询每次查询视图时数据库会执行这段查询。它不存数据只是一个“虚拟表”。视图最大的价值是逻辑封装把复杂的多表关联查询定义成视图业务层只需要查询视图而不用关心底层表结构同时还可以做权限控制只暴露部分字段给特定角色。不过把视图当性能工具是常见误解。你创建了一个视图不等于查询快了数据库照样要执行视图背后的SQL。真正要提速还得靠底层表的索引和SQL写得高效。视图还有一个限制是更新条件苛刻包含聚合函数、DISTINCT、GROUP BY等操作的视图通常不能做UPDATE或DELETE。三级数据库技术考试对视图的考察点也集中在这两方面视图的作用、可更新视图的条件。6. 事务、备份与权限基本操作里的生存技能6.1 事务ACID和隔离级别考试必考、实战必用如果说增删改查让你能开始用数据库那么事务就是让你敢放心用数据库的底气。事务保证一组操作要么全部成功、要么全部回滚不会出现“扣了钱但没生成订单”这种一半成功一半失败的中间状态。理解事务要从ACID四个特性入手原子性、一致性、隔离性、持久性。这里我用一个转账例子来说明A给B转100元操作包括A账户减100、B账户加100两步。没有原子性可能出现A减了B却没加没有一致性可能出现减了100但加的是200没有隔离性可能出现两个转账操作互相看到对方的中间状态没有持久性可能出现转账完成但重启后数据丢了。实际使用中最需要关注的是隔离性。SQL标准定义了四种隔离级别读未提交、读已提交、可重复读、串行化。级别从低到高隔离性越来越强并发能力越来越弱。MySQL默认是可重复读PostgreSQL和Oracle默认是读已提交。不同隔离级别对应不同的并发问题脏读、不可重复读、幻读。我对这部分的理解是别死记概念去看具体的执行现象。隔离级别脏读不可重复读幻读读未提交可能可能可能读已提交不会可能可能可重复读不会不会可能InnoDB通过间隙锁解决串行化不会不会不会关于幻读这里补一句MySQL的InnoDB在可重复读级别下通过间隙锁在很大程度上解决了幻读问题但这不是标准的SQL行为。标准SQL里可重复读仍可能出现幻读考试时如果用标准SQL概念来答幻读可能发生如果结合MySQL答案就变了。这也是三级数据库技术真题里容易出辨析题的地方实际面试里也经常被追问。6.2 备份与恢复不备份的操作都是耍流氓数据库基本操作不只是写在生产库上的操作备份和恢复也是一个数据库工程师的看家本领。很多人平时不关注备份一旦误删数据、磁盘损坏、机房故障才发现没有后手那种感觉比考试挂科难受一百倍。备份有很多种策略但基础的核心工具你一定要掌握。MySQL里最常用的是mysqldump逻辑备份mysqldump -u root -p --single-transaction --routines --triggers --databases shop shop_backup_20250101.sql--single-transaction参数的意思是在备份时开启一个一致性的读事务InnoDB表可以在不锁表的情况下拿到一致性快照。恢复时就很简单mysql -u root -p shop_backup_20250101.sql但逻辑备份也有短板数据量大时恢复速度慢。生产环境通常还会用物理备份工具比如Percona XtraBackup直接拷贝数据文件恢复速度快得多。我的习惯是两条路并行定期全量备份加二进制日志增量备份全量备份保证有完整的底子增量备份保证只丢最近几分钟的数据。备份文件还要定期做恢复演练光有备份没恢复过严格等于没有备份真到灾难时刻才发现备份文件损坏那才叫欲哭无泪。6.3 权限管理最小权限原则是底线数据库的权限管理也是基本操作里容易被忽视但极为关键的一环。比如用root账号跑所有业务操作这是我在很多团队里见过的通病。一旦应用层被攻击数据库直接全线失守后果就是灾难性的。正确的做法是遵循最小权限原则给每个应用、每个角色分配刚好够用的权限。日常操作里这样创建用户是基础中的基础CREATE USER app_user% IDENTIFIED BY strong_password; GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO app_user%; REVOKE DELETE ON shop.user FROM app_user%; FLUSH PRIVILEGES;这里的细节是先用GRANT授予基本权限再用REVOKE把高风险操作比如DELETE大表、DROP表收回。权限粒度可以细化到库、表、甚至字段级别。如果要回收权限一定要记得FLUSH PRIVILEGES让权限变更立即生效。还有一点不要给应用账号开通FILE权限、SUPER权限这些高级权限平时业务完全用不到一旦泄露就是额外的安全风险。权限这块三级数据库技术考试更多是考基本概念比如GRANT和REVOKE的语法结构但实际工作中的安全价值要远大于考试价值。7. 常见问题与排查技巧实录7.1 连不上数据库别慌按顺序排查连接数据库失败是新手遇到最多的报错之一但它往往不是数据库本身的问题。我的排查顺序是这样的先确认网络层ping数据库服务器地址、telnet服务端口再确认服务层查看数据库进程是否存活、监听端口是否正确接着确认认证层检查用户名、密码、授权主机范围是不是权限没授权给对应IP最后检查防火墙和安全组。很多时候你换了一个网段就连不上不是密码错了而是数据库用户授权的主机范围只允许localhost连接需要改授权。另外连接串里指定字符集也是我每次都会检查的防止连上之后中文乱码。一整套排查下来大部分连接问题都能解决。记住数据库报错信息里MySQL Error 1130和MySQL Error 1045含义完全不同前者是Host不允许连接后者是用户名密码或权限问题看准错误码能少走很多弯路。7.2 中文乱码字符集不一致是元凶中文乱码问题几乎每个数据库使用者都遇到过。它通常不是数据存坏了而是写入和读取时的字符集不一致。比如数据库表是utf8mb4连接串里却用了latin1数据写入时就已经被错误编码存储。我的排查方法是先查数据库、表、连接三者的字符集设置再把乱码前的字符集情况和乱码后的表现横向对比。防止乱码的最好方案就是三统一建库指定utf8mb4、表指定utf8mb4、连接串指定utf8mb4。如果是SQL客户端操作Windows下还需要注意命令行自身的代码页。万一已经乱码了处理起来比较麻烦通常要做字符集转换修复这比预防成本高得多。所以这个东西一定要在源头抓好。7.3 锁等待和死锁事务操作的高级挑战当数据库出现并发操作时锁等待和死锁就是必然要面对的问题。简单说锁等待是某个事务需要锁但被别的事务占着查询一直卡住死锁是事务之间互相持有对方需要的锁形成循环等待谁也执行不下去。MySQL检测到死锁时会自动回滚其中一个事务让另一个继续执行你会在错误日志里看到Deadlock found when trying to get lock的经典报错。排查锁问题我的经验是用性能模式下的锁查询或者SHOW ENGINE INNODB STATUS看最近一次死锁日志重点查看事务里执行了哪些SQL、涉及哪些表和索引。避免锁等待和死锁的常规手段包括短事务原则事务范围越小越好、一致的加锁顺序避免循环等待、合理使用索引减少锁范围、降低隔离级别减少锁冲突。实际项目里我们通过统一保证多条UPDATE操作按相同字段顺序执行就解决过好几个死锁问题。7.4 备考三级数据库技术真题策略与实操结合既然不少读者关心三级数据库技术真题这里我从备考角度多聊几句。三级数据库技术考试有个特点题目覆盖面宽但单题难度并不特别深。选择题和填空题考大量基础概念比如数据模型、关系代数、范式、并发控制、数据库设计设计题和应用题往往围绕ER图转关系模式、SQL写法、索引选择、事务隔离级别展开。基本操作这部分恰恰是性价比最高的得分点因为它是理论够得着、实操也练得出的模块。刷题之外我建议你花时间把那些“纸上答案”落到数据库里实际跑一遍。比如真题里问用SQL查询某个条件的分组结果你就真的建两张表、插入实验数据、把SQL写出来验证一遍。这样做的好处是题感会强很多因为你真正见过运行结果知道为什么这样写是对的、那样写是错的。三级考试不是一个纯记忆考试很多知识通过动手操作形成的记忆比背教材里的结论牢固得多。还有一个很实用的备考技巧把真题里反复出现的SQL语句和操作点整理成自己的速查表。比如日期条件怎么用BETWEEN和DATE_SUB分页怎么写LIMIT多表关联怎么写JOIN表结构修改怎么写ALTER。这些基本操作整理成速查表之后用来做考前冲刺比翻整本教材高效得多。我现在带新人也会让他们做这个动作效果普遍不错。8. 最后一些私房经验和小结写到这里数据库技术里的基本操作算是比较系统过了一遍。可能你会觉得这些内容好像每个都听说过但把它们串起来就会发现基本操作从来不是独立的知识点建表、查询、索引、事务、备份、权限每一样彼此咬合任何一环出问题其他环节都会跟着遭殃。我个人在实际操作中的体会是学数据库基本操作最快的捷径就是“遇到问题别绕开”。连接不上就去查授权和网络乱码了就去查字符集查询慢了就去EXPLAIN看执行计划死锁了就去看InnoDB状态日志。每解决一次问题你对基本操作的理解就会加深一层。那些看起来最基础的操作恰恰是未来排查复杂问题时的直觉来源。最后再分享一个小技巧如果你在学基本操作尽量选一套真实的业务数据来练手比如自己模拟一个小型订单系统从建库建表到写查询报表全流程走一遍练完后你对数据库的基本操作理解和操盘能力绝对比干刷题库要扎实得多。
